1. 为什么要在 Ubuntu 22.04 上折腾 Redroid 云手机Redroid 这个项目全称是 Remote Android本质上是把 Android 系统跑在 Linux 容器里通过容器化方案让 Android 实例共享宿主机的内核。它跟传统模拟器最大的区别在于模拟器是跑一个完整的虚拟机资源开销大、启动慢而 Redroid 是容器级别的隔离启动一个 Android 实例通常只需要几秒钟内存占用也低得多。这个特性让它在云手机、自动化测试、群控、应用多开等场景里非常受欢迎。那为什么偏偏选 Ubuntu 22.04 作为编译和运行环境我自己的体会是22.04 这个 LTS 版本在内核版本、Docker 支持、驱动兼容性上达到了一个比较舒服的平衡点。它的默认内核是 5.15这个版本对 binderfs、ashmem 这些 Android 容器依赖的内核模块支持已经相当成熟同时 NVIDIA 的 GPU 驱动在这个版本上的安装也相对省心。如果你用 20.04内核偏老某些新特性支持不够用 24.04虽然更新但部分第三方驱动的适配还没完全跟上踩坑概率反而更高。这篇文章要解决的问题很具体从零开始在 Ubuntu 22.04 上完成 Redroid 镜像的编译并且把 GPU 加速配置跑通。适合谁看如果你手上有带独立显卡的服务器或者工作站想搭建云手机环境又不想用那些商业方案那这篇内容基本可以照着抄。如果你只是想先跑起来看看效果也可以先跳过编译部分直接用现成镜像但 GPU 加速那部分还是得看。我踩过的坑主要集中在三个地方一是内核模块的加载binderfs 和 ashmem 这两个东西不搞定容器根本起不来二是 GPU 加速的配置NVIDIA 驱动、CUDA 库、容器运行时的版本匹配很容易出问题三是镜像编译过程中的依赖缺失Redroid 的编译脚本对环境的假设比较强缺一个包就可能报一堆看不懂的错。下面我会把这些环节一个个拆开讲。2. 编译前的环境准备与依赖梳理2.1 系统基础环境确认动手之前先把系统信息确认一遍。打开终端执行lsb_release -a uname -r你应该看到 Ubuntu 22.04 的版本信息内核版本在 5.15 以上。如果内核低于 5.15建议先升级内核否则后面加载 binderfs 的时候可能会遇到模块不存在的问题。我实测下来5.15.0-91 这个版本是比较稳的再新的版本也没问题但别用太老的。接下来确认 CPU 架构dpkg --print-architecture输出应该是amd64。Redroid 目前对 arm64 的支持也有但编译流程和 GPU 加速的配置差别比较大这篇文章主要针对 amd64 平台。如果你用的是 RK3588 这类开发板思路类似但细节需要调整后面我会提一下差异点。磁盘空间方面编译 Redroid 镜像加上 Docker 的层缓存至少需要 50GB 的可用空间。用df -h看一下根分区不够的话提前清理或者挂载新盘。内存建议 16GB 起步8GB 也能编译但会比较慢而且容易在链接阶段爆内存。2.2 内核模块的加载与验证Redroid 依赖两个关键的内核模块binderfs和ashmem。这两个东西是 Android 容器运行的基础binder 负责进程间通信ashmem 负责共享内存。Ubuntu 22.04 的默认内核已经编译了这两个模块但默认可能没有加载。先检查lsmod | grep binder lsmod | grep ashmem如果没有任何输出说明模块没加载。手动加载sudo modprobe binder_linux sudo modprobe ashmem_linux这里有个细节要注意模块名是binder_linux而不是binderashmem_linux而不是ashmem。我第一次搞的时候直接modprobe binder报错说模块找不到折腾了半天才发现名字不对。加载完之后再lsmod确认一下应该能看到类似这样的输出binder_linux 114688 0 ashmem_linux 20480 0为了让模块开机自动加载把它们写进配置文件echo binder_linux | sudo tee -a /etc/modules echo ashmem_linux | sudo tee -a /etc/modules注意如果你用的是自定义编译的内核需要确认编译时开启了CONFIG_ANDROID_BINDERFS和CONFIG_ASHMEM这两个选项。默认的 Ubuntu 内核是开着的但自己编译内核的话很容易漏掉。2.3 Docker 与容器运行时的安装Redroid 官方推荐用 Docker 来跑容器所以 Docker 是必须的。Ubuntu 22.04 自带的 Docker 版本可能偏老建议用官方源安装最新稳定版sudo apt update sudo apt install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin装完之后把当前用户加入 docker 组免得每次都要 sudosudo usermod -aG docker $USER newgrp docker然后验证一下docker run hello-world能正常输出就说明 Docker 没问题了。2.4 编译工具链的安装Redroid 的镜像编译需要一堆工具我整理了一个完整的安装命令直接复制执行sudo apt install -y git build-essential cmake ninja-build python3 python3-pip \ repo flex bison gperf zip unzip curl wget libssl-dev libelf-dev \ libncurses5-dev libncursesw5-dev libx11-dev libgl1-mesa-dev \ libxml2-utils xsltproc zlib1g-dev liblz4-tool这里面有几个包特别容易漏libncurses5-dev和libncursesw5-dev是编译内核菜单配置用的libx11-dev和libgl1-mesa-dev是编译图形相关组件用的liblz4-tool是打包镜像时压缩用的。我试过只装build-essential就开始编译结果在编译到一半的时候报了一堆头文件找不到的错误回头补装又得重新跑很浪费时间。Python 方面Redroid 的编译脚本依赖 Python 3.8 以上Ubuntu 22.04 自带的 Python 3.10 完全够用。但 pip 的版本可能偏老建议升级一下python3 -m pip install --upgrade pip另外repo这个工具是 Google 用来管理多仓库项目的Redroid 的源码就是用 repo 来同步的。Ubuntu 源里的 repo 版本可能比较老建议用官方脚本安装mkdir -p ~/bin curl https://storage.googleapis.com/git-repo-downloads/repo ~/bin/repo chmod ax ~/bin/repo echo export PATH$PATH:~/bin ~/.bashrc source ~/.bashrc提示如果你在国内网络环境下repo 同步源码可能会很慢甚至失败。可以考虑配置 git 的代理或者用国内的镜像源来同步。具体方法这里不展开但这是编译前必须解决的一个实际问题。3. Redroid 镜像编译的完整实操流程3.1 源码同步与分支选择Redroid 的源码托管在 GitHub 上用 repo 来管理。先创建一个工作目录mkdir -p ~/redroid cd ~/redroid然后初始化 reporepo init -u https://github.com/remote-android/redroid-manifest.git -b main这里-b main指定的是分支。Redroid 目前主要有几个分支main是最新的开发分支android-11、android-12、android-13对应不同的 Android 版本。如果你追求稳定性建议用android-13分支这个版本我实测下来兼容性最好GPU 加速的支持也比较完善。repo init -u https://github.com/remote-android/redroid-manifest.git -b android-13 repo sync -j$(nproc)repo sync这一步会下载大量源码具体时间取决于网络状况。我这边千兆带宽大概跑了 40 分钟左右如果网络不好可能要几个小时。建议在晚上挂着跑或者用-j参数控制并发数别把带宽占满。同步完成后检查一下目录结构ls -la应该能看到build、device、vendor这些目录。如果缺目录说明 sync 没完成重新跑一次repo sync就行。3.2 编译配置与参数调整进入源码目录后先执行环境初始化source build/envsetup.sh然后选择编译目标lunch redroid_x86_64-userdebug这里redroid_x86_64是目标设备userdebug是编译类型。userdebug 版本带 root 权限和调试功能适合开发和测试用。如果你要用于生产环境可以选user类型但那样就没有 root 了很多调试功能也用不了。接下来是编译。Redroid 的编译脚本封装得比较好直接跑make -j$(nproc)但这里有几个参数需要根据你的机器情况调整。-j$(nproc)是用所有 CPU 核心并行编译如果你的内存不够大比如只有 8GB建议把并发数降下来比如-j4否则很容易在链接阶段被 OOM killer 杀掉。我自己的机器是 32 核 64GB 内存用-j32编译大概 25 分钟能跑完。如果是 16 核 32GB大概 45 分钟到 1 小时。第一次编译会比较慢因为要编译整个 Android 系统后面增量编译就快多了。编译过程中如果报错最常见的原因是依赖缺失。比如error: command flex not found这说明 flex 没装回头sudo apt install flex就行。还有一类错误是 Java 版本不对Redroid 的某些组件需要 JDK 11Ubuntu 22.04 默认可能是 JDK 17需要手动切换sudo apt install -y openjdk-11-jdk sudo update-alternatives --config java选择 JDK 11 对应的选项。3.3 镜像打包与导出编译完成后产物在out/target/product/redroid_x86_64/目录下。你会看到一堆.img文件比如system.img、vendor.img、userdata.img等。Redroid 的 Docker 镜像需要把这些 img 文件打包进去。Redroid 官方提供了一个打包脚本在device/redroid目录下cd device/redroid ./build_docker.sh这个脚本会生成一个 Docker 镜像名字类似redroid/redroid:13.0.0_amd64。你可以用docker images查看。如果脚本跑不通也可以手动打包。核心思路是写一个 Dockerfile基于一个精简的 Ubuntu 基础镜像把编译好的 img 文件复制进去然后设置好启动命令。Redroid 的容器启动命令通常是docker run -itd --privileged \ --name redroid \ -p 5555:5555 \ redroid/redroid:13.0.0_amd64 \ androidboot.redroid_width1080 \ androidboot.redroid_height1920 \ androidboot.redroid_dpi320这里的androidboot.redroid_*参数是传给 Android 内核的启动参数用来控制分辨率、DPI 等。--privileged是必须的因为容器需要访问宿主机的内核模块。注意--privileged模式会赋予容器几乎所有的宿主机权限安全性上需要自己权衡。如果是在生产环境用建议配合 SELinux 或者 AppArmor 做额外的隔离。3.4 首次启动与验证启动容器后用docker logs看一下日志docker logs -f redroid如果看到类似init: Starting service surfaceflinger...这样的输出说明 Android 系统正在启动。等个十几秒然后用 adb 连接adb connect localhost:5555 adb devices如果能看到设备列表里有localhost:5555说明启动成功了。你可以用adb shell进去看看或者用 scrcpy 这类工具投屏到本地。我第一次启动的时候卡在了surfaceflinger起不来日志里报Failed to open /dev/binder。回头检查发现是 binderfs 模块没加载modprobe binder_linux之后重新启动容器就好了。所以前面环境准备那一步千万别跳过。4. GPU 加速配置的详细拆解4.1 为什么需要 GPU 加速默认情况下Redroid 用的是软件渲染也就是 CPU 来跑图形计算。这在低分辨率下勉强能用但一旦上到 1080p 或者更高帧率就会掉得很厉害滑动界面都能感觉到明显的卡顿。GPU 加速就是把图形渲染的活交给显卡来做帧率能提升好几倍而且 CPU 占用也会大幅下降。我实测过同一台机器上软件渲染跑 1080p 的 Redroid滑动帧率大概 15-20fpsCPU 占用 40% 左右开启 GPU 加速后帧率稳定在 60fpsCPU 占用降到 10% 以下。这个差距在云手机场景里是决定性的尤其是你要跑多个实例的时候。4.2 NVIDIA 驱动的安装与验证GPU 加速的前提是宿主机装好了显卡驱动。这里以 NVIDIA 显卡为例AMD 显卡的流程类似但驱动包不同。先检查显卡型号lspci | grep -i nvidia然后安装驱动。Ubuntu 22.04 推荐用ubuntu-drivers工具自动安装sudo apt update sudo ubuntu-drivers autoinstall这个命令会自动选择适合你显卡的驱动版本。装完之后重启sudo reboot重启后验证nvidia-smi如果能看到显卡信息、驱动版本、CUDA 版本说明驱动装好了。我这边用的是 RTX 3060驱动版本 535CUDA 12.2跑 Redroid 的 GPU 加速没问题。提示如果你用的是 2080Ti 魔改卡驱动安装可能会遇到签名问题。需要在 BIOS 里关闭 Secure Boot或者手动给驱动模块签名。这个坑我踩过折腾了一下午才搞定。4.3 容器运行时的 GPU 支持配置Docker 默认是不支持 GPU 的需要安装nvidia-container-toolkitcurl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit然后配置 Docker 使用 NVIDIA 运行时sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker验证一下docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi如果能看到显卡信息说明 Docker 的 GPU 支持配好了。4.4 Redroid 的 GPU 加速参数配置Redroid 的 GPU 加速是通过androidboot.redroid_gpu_mode这个参数来控制的。启动容器的时候加上docker run -itd --privileged \ --name redroid_gpu \ --gpus all \ -p 5555:5555 \ redroid/redroid:13.0.0_amd64 \ androidboot.redroid_gpu_modehost \ androidboot.redroid_width1080 \ androidboot.redroid_height1920 \ androidboot.redroid_dpi320关键参数是androidboot.redroid_gpu_modehost意思是使用宿主机的 GPU。还有一个值是guest表示用容器内的软件渲染那个就是我们前面说的默认模式。另外--gpus all是必须的它让容器能访问宿主机的 GPU 设备。启动后用adb shell进去执行adb shell dumpsys SurfaceFlinger | grep GLES如果输出里有GLES: NVIDIA或者类似的字样说明 GPU 加速生效了。如果显示的是GLES: Google SwiftShader那就是软件渲染说明配置没生效。我遇到过一次配置没生效的情况排查发现是nvidia-container-toolkit装好了但 Docker 的默认运行时没改。nvidia-ctk runtime configure这个命令会自动改/etc/docker/daemon.json但如果你之前手动改过这个文件可能会冲突。检查一下cat /etc/docker/daemon.json确保里面有default-runtime: nvidia这一行。5. 常见问题排查与避坑经验5.1 容器启动失败类问题这类问题最常见表现是docker run之后容器立刻退出docker ps -a看到状态是Exited。排查思路是看日志docker logs redroid如果日志里报Failed to mount binderfs说明 binderfs 没挂载。除了加载模块还需要确保/dev/binderfs目录存在sudo mkdir -p /dev/binderfs sudo mount -t binder binder /dev/binderfs如果报Permission denied或者Operation not permitted检查一下是不是没加--privileged参数。Redroid 容器必须用特权模式这个没得商量。还有一种情况是端口冲突5555端口被占用了。换个端口就行-p 5556:5555然后 adb 连接的时候用adb connect localhost:5556。5.2 GPU 加速不生效的排查GPU 加速不生效的表现是帧率低、CPU 占用高dumpsys SurfaceFlinger显示的是软件渲染器。排查步骤我整理了一个表格检查项命令预期结果宿主机驱动nvidia-smi显示显卡信息Docker GPU 支持docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi显示显卡信息容器 GPU 参数docker inspect redroid_gpu | grep -i gpu看到--gpus allAndroid GPU 模式adb shell getprop | grep gpu_mode显示host渲染器确认adb shell dumpsys SurfaceFlinger | grep GLES显示 NVIDIA 相关字样如果宿主机驱动没问题但容器里nvidia-smi跑不了大概率是nvidia-container-toolkit没配好。重新跑一遍nvidia-ctk runtime configure --runtimedocker然后重启 Docker。如果容器里nvidia-smi能跑但 Android 还是软件渲染检查androidboot.redroid_gpu_mode参数是不是写对了。这个参数是区分大小写的host不能写成Host。5.3 编译过程中的典型报错编译 Redroid 镜像时我遇到过几个典型的报错这里列出来供参考报错一error: unrecognized command-line option -m64这个通常是因为用了不兼容的编译器版本。Redroid 的编译脚本假设你用 GCC 11 或 12如果你系统里默认是 GCC 13可能会出问题。检查一下gcc --version如果是 13装一个 GCC 12 然后切换sudo apt install -y gcc-12 g-12 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-12 100报错二ninja: build stopped: subcommand failed这个报错太笼统了需要往上翻日志找具体的错误。常见原因是内存不足编译到一半被 OOM killer 杀了。解决办法是降低并发数或者加 swapsudo fallocate -l 16G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile报错三FAILED: out/target/product/redroid_x86_64/system.img这个通常是打包阶段的问题可能是某个 img 文件生成失败。检查out/target/product/redroid_x86_64/目录下缺哪个文件然后单独编译那个模块。比如缺vendor.img就make vendorimage -j$(nproc)5.4 性能调优的实操心得Redroid 跑起来之后性能调优有几个方向可以挖CPU 亲和性绑定。如果你跑多个 Redroid 实例可以把每个实例绑定到不同的 CPU 核心上减少上下文切换。用taskset命令taskset -c 0-3 docker run ...这样容器就只会用 0 到 3 号核心。内存限制。Redroid 默认会尽可能多地占用内存如果不限制跑多个实例容易把宿主机内存吃光。用--memory参数限制--memory4g --memory-swap4g存储优化。Redroid 的 userdata 分区默认是放在容器可写层里的I/O 性能一般。可以把 userdata 挂载到宿主机的 SSD 上-v /data/redroid/userdata:/data这样读写性能会好很多而且容器重建的时候数据也不会丢。网络模式。默认的 bridge 模式会有 NAT 开销如果对网络延迟敏感可以用 host 模式--networkhost但这样端口就直接暴露在宿主机上了多个实例需要改端口。注意--networkhost模式下-p参数是无效的端口直接由 Android 系统控制。默认 adb 端口是 5555多个实例需要改androidboot.redroid_adb_port参数。6. 多实例部署与扩展思路6.1 多实例的资源规划单实例跑通之后下一步自然是多开。多实例部署的核心问题是资源分配。我以一台 32 核 64GB 内存、RTX 3060 12GB 显存的机器为例规划大概是这样的实例数每实例 CPU每实例内存每实例显存总 CPU总内存总显存48 核8GB2GB32 核32GB8GB64 核6GB1.5GB24 核36GB9GB84 核4GB1GB32 核32GB8GB显存是瓶颈。1080p 的 Redroid 实例GPU 加速下大概占用 1GB 到 1.5GB 显存。12GB 显存的卡跑 8 个实例基本就到顶了。如果你要跑更多要么降低分辨率要么加卡。CPU 方面每个实例至少给 4 个核心否则滑动会卡。内存 4GB 是底线再低 Android 系统本身就跑不顺畅了。6.2 批量管理脚本的编写手动一个个docker run太麻烦写个脚本批量启动#!/bin/bash BASE_PORT5555 INSTANCE_COUNT4 IMAGEredroid/redroid:13.0.0_amd64 for i in $(seq 0 $((INSTANCE_COUNT - 1))); do PORT$((BASE_PORT i)) NAMEredroid_$i docker run -itd --privileged \ --name $NAME \ --gpus all \ --memory8g \ --cpuset-cpus$((i * 8))-$((i * 8 7)) \ -p $PORT:5555 \ -v /data/redroid/$NAME:/data \ $IMAGE \ androidboot.redroid_gpu_modehost \ androidboot.redroid_width1080 \ androidboot.redroid_height1920 \ androidboot.redroid_dpi320 echo Started $NAME on port $PORT done这个脚本会启动 4 个实例每个实例绑定 8 个 CPU 核心分配 8GB 内存端口从 5555 开始递增。-v参数把每个实例的 userdata 挂载到宿主机上方便管理和备份。停止所有实例docker ps -a --filter nameredroid_ -q | xargs docker stop docker ps -a --filter nameredroid_ -q | xargs docker rm6.3 远程访问与管理云手机的核心价值在于远程访问。Redroid 默认开启了 adb 端口你可以通过 adb 从任何能访问到宿主机的机器上连接。但如果要图形化操作还需要额外的工具。我常用的是 scrcpy它能把 Android 屏幕投到本地而且支持鼠标键盘操作scrcpy -s localhost:5555scrcpy 的延迟很低局域网内基本感觉不到。如果要在公网访问建议套一层 WebSocket 代理或者用 VNC 方案。不过公网访问涉及到安全问题需要做好认证和加密这里不展开。还有一种方案是用adb connect之后通过adb shell执行命令来做自动化。比如批量安装 APKfor port in 5555 5556 5557 5558; do adb connect localhost:$port adb -s localhost:$port install app.apk done这种方案适合自动化测试场景不需要图形界面。6.4 数据持久化与备份Redroid 的数据默认存在容器的可写层里容器一删数据就没了。生产环境必须做持久化。前面提到的-v /data/redroid/$NAME:/data就是把 userdata 挂载出来。备份的时候直接打包宿主机的数据目录tar -czf redroid_backup_$(date %Y%m%d).tar.gz /data/redroid/恢复的时候解压回去重新启动容器就行。注意容器启动时 Android 系统会检查 userdata 的完整性如果数据损坏可能会触发恢复模式。所以备份前最好先停容器确保数据一致。提示如果你用的是 SSD建议开启 TRIM 支持否则长期读写性能会下降。在/etc/fstab里给数据盘加上discard选项就行。7. 我个人的一些实操体会Redroid 这个方案我从去年开始用前后搭了三四套环境踩的坑不算少。最大的感受是环境准备阶段千万别图省事。binderfs 和 ashmem 这两个模块看着简单但不加载就是跑不起来而且报错信息不直观新手很容易卡在这里。我的建议是写个开机脚本把模块加载、目录挂载这些操作自动化省得每次重启都要手动搞一遍。GPU 加速那块NVIDIA 的驱动和容器工具链版本匹配是个玄学。我遇到过驱动 535 配 CUDA 12.2 没问题但换成驱动 525 配 CUDA 12.0 就死活跑不起来的情况。后来学乖了装驱动之前先查一下nvidia-container-toolkit的兼容性列表按推荐版本装能省很多事。编译镜像这块第一次编译一定要留足时间别指望半小时能搞定。我建议找个周末挂着编译中间该干嘛干嘛。编译过程中如果报错先看日志最后几行通常那里有具体的错误信息。如果日志太长用grep -i error过滤一下。多实例部署的时候CPU 亲和性绑定和内存限制这两个参数一定要加。不加的话多个实例会互相抢资源表现就是所有实例都卡。我试过 8 个实例不加限制结果宿主机负载直接飙到 100 多SSH 都连不上只能硬重启。最后说一个容易被忽略的点磁盘 I/O。Redroid 的 userdata 读写很频繁如果放在机械盘上多实例场景下 I/O 会成为瓶颈。我后来把 userdata 全部迁到 NVMe SSD 上帧率稳定性提升很明显。如果你手头有 SSD强烈建议把数据目录放上去。这个方案后续还可以往几个方向扩展一是结合 Kubernetes 做集群化管理把 Redroid 实例当成 Pod 来调度二是接入自动化测试框架比如 Appium做大规模的兼容性测试三是做云手机平台的二次开发加上用户管理、计费这些功能。不过这些就超出单机部署的范畴了有需要的话可以再单独聊。
