Docker 实现云端 Android 编译的核心是将构建环境容器化并部署至云平台，所有依赖（JDK、SDK、Build Tools 等）固化于镜像中，确保一次构建、随处运行。
用 Docker 实现云端 Android 编译，核心是把本地构建逻辑“搬进容器”，再把容器部署到云服务器或 CI/CD 平台（比如 Jenkins、GitLab CI、GitHub Actions）。它不依赖开发者本机环境，也不需要在云主机上手动装 JDK、SDK、Gradle——所有依赖都固化在镜像里，一次构建，随处运行。
选对基础镜像和工具链版本
Android 编译对 JDK、SDK Platform、Build Tools 版本敏感，不能随便凑合。推荐组合：
- JDK：openjdk:11-jdk（Android 12+ 官方要求 JDK 11；JDK 8 仅适用于老项目如 targetSdk 28 及以下）
- 系统镜像：ubuntu:20.04（LTS 稳定，兼容 Android SDK cmdline-tools 和 NDK）
- SDK 组件：明确指定平台版本，例如 "platforms;android-33"、"build-tools;33.0.2"、"ndk;25.1.8937393"（NDK 若项目用到 C/C++）
- 注意跳过模拟器和 GUI 工具——云端打包不需要 adb server、emulator 或 Android Studio，只留命令行必需项，减小镜像体积和启动开销
写一个轻量可靠的 Dockerfile
关键不是功能全，而是可复现、易调试、少冗余。下面是一段精简实用的结构：
Android Adb Skill
下载
Android 开发调试技能，通过系统 ADB 工具操作 Android 设备。以下场景必须触发此技能：(1) 直接 ADB 操作——安装 APK、查看设备列表、抓取 logcat 日志、查看已安装应用、清除应用数据、截图、重启设备、拉取/推送文件、查看 CPU/内存/电池信息、adb shell 操作；(2)...
- 用 ARG 声明变量（如 ANDROID_SDK_VERSION=33），便于多版本维护
- 下载 cmdline-tools 后，必须重命名为 latest 目录（sdkmanager 才能识别路径）
- 许可必须自动接受：yes | sdkmanager --licenses，否则构建卡住
- 安装 SDK 时加 --no-opengl-libs（避免云端无 GPU 环境报错）
- Gradle 不预装，改用项目自带的 gradlew（保证与本地一致）
- COPY 项目代码进容器前，先 RUN mkdir -p /workspace && WORKDIR /workspace，避免权限或路径混乱
接入云端 CI/CD 流水线
以 GitHub Actions 为例，无需自建服务器，直接在仓库中定义 workflow：
- 触发时机：push 到 main 分支 或 PR 提交时
- 使用 ubuntu-latest runner 启动临时构建机
- 步骤顺序：检出代码 → 构建镜像（docker build -t android-builder .）→ 运行容器并执行 gradlew assembleRelease
- 关键参数要加：-v ${{ github.workspace }}:/workspace 把代码挂载进去，--rm 用完即删，安全又省资源
- 生成的 APK 用 actions/upload-artifact 自动存为构建产物，可下载验证
进阶：复用镜像提升效率
每次从零拉取 SDK 太慢。建议分层构建：
- 第一层：基础镜像（含 JDK + cmdline-tools + 许可），打标签如 android-sdk-base:33，推送到私有 registry 或 GitHub Container Registry
- 第二层：项目专属镜像（只 COPY build.gradle、gradle/wrapper 等配置），基于上一层构建，秒级完成
- CI 中用 docker pull your-registry/android-sdk-base:33，跳过重复下载，节省 3–5 分钟
- 配合 .dockerignore 排除 .git、.gradle、build/ 等无关目录，加快上下文传输
整个过程不复杂但容易忽略细节——比如没设非交互式环境变量导致 apt 卡住，或者没处理 SDK 路径大小写问题（Linux 区分大小写，cmdline-tools 必须是小写）。只要镜像能本地 docker run 成功，上云基本就稳了。
