What is the best CI/CD platform for Android apps?

For most teams the CI they already use is enough, because Android builds run on Linux. GitHub Actions, GitLab CI, CircleCI, and Azure DevOps handle Gradle well. Bitrise, Codemagic, and Appcircle add managed keystores and Play publishing. Capacitor teams can call Capgo Build to sign and upload without maintaining an Android toolchain.

Do I need a Mac for Android CI?

No. Android builds run on Linux runners, which are the cheapest runners on every platform. A Mac is only needed for the iOS half of a cross-platform app.

Should CI upload an APK or an AAB to Google Play?

An AAB. Google Play requires Android App Bundles for new apps and signs the final APKs itself with Play App Signing. Build APKs only for direct installs, MDM distribution, or other stores.

Where should I keep the Android keystore for CI?

Base64-encode it into a secret or a secure file on your CI, or use a platform that stores keystores for you. With Play App Signing your keystore is the upload key, so Google can reset it if it leaks, but keep an offline backup anyway.

How do I upload to Google Play from CI?

Create a Google Cloud service account, grant it access in Play Console, and use its JSON key with fastlane supply, the Gradle Play Publisher plugin, a CI integration such as Bitrise or Codemagic publishing, or Capgo Build's Play upload.

2026 年 Android 应用最佳 CI/CD 平台对比

对 Android 应用来说，最好的 CI/CD 平台往往就是你已经在用的那个，因为 Android 构建只需要 Linux、Java、Android SDK 和 Gradle。平台之间的差异主要体现在构建周边：如何存储 keystore、如何上传到 Google Play 发布轨道、Gradle 缓存能让重复构建快多少，以及同一平台是否也能兼顾 iOS。本次对比涵盖 GitHub Actions、GitLab CI、Bitrise、Codemagic、Appcircle、CircleCI、Azure DevOps 和 Capgo Build。

2026 年 Android 发布流程

每个 Android pipeline 做的事都差不多：

安装 JDK 和 Android SDK（或使用已装好它们的镜像）。
运行 ./gradlew bundleRelease.
用你的密钥给 AAB 签名， 上传密钥.
通过 Google Play Developer API 将其上传到 Play Console 的发布轨道（内部测试、封闭测试、开放测试或正式版）。
可选择按一定比例向用户逐步发布。

每个平台都必须遵守的规则：

Google Play 要求新应用必须使用 AAB， 且 Google 会用其持有的应用签名密钥对分发的 APK 重新签名（Play App Signing）。
目标 API 级别每年都会提高。 Google 会提高最低 targetSdkVersion 每年 8 月更新。Capacitor 8 已以 API 36 为目标。
16 KB 页面大小。 较新的设备使用 16 KB 内存页，Play 要求更新后的应用中的原生库支持 16 KB 页面。详见适用于 Capacitor 插件的 Android 16 KB 页面大小.
JDK 21 是 Capacitor 7 和 8 项目以及近期 Android Gradle Plugin 版本的基线。

功能矩阵

平台	运行器	Keystore 存储	Play 上传	Gradle 缓存	iOS 同样支持	计费模式
GitHub 操作	托管 Linux、自托管	加密 Secrets	fastlane、Gradle Play Publisher 或社区 Action	`gradle/actions/setup-gradle`	支持，提供 macOS Runner	按分钟计费，Linux 最便宜；公开仓库免费
GitLab CI	托管 Linux、自管理	CI/CD 变量、安全文件	fastlane、Google Play 集成	`cache:` 密钥	是，macOS 测试版	各层级计算分钟数
Bitrise	托管 Linux 构建栈	托管 code 签名文件	Google Play 部署步骤	内置缓存步骤	是	每构建分钟消耗的 Credits
Codemagic	托管 Linux 和 Mac	命名 keystore 引用	内置，支持轨道与灰度发布比例	内置	是	按分钟计费或年度套餐
Appcircle	托管或自托管服务器	签名身份存储	发布模块	内置	是	套餐层级，企业自托管
CircleCI	托管 Linux (`cimg/android`)，自托管	上下文与环境变量	fastlane 或脚本	`save_cache`/`restore_cache`	是	每分钟积分消耗
Azure DevOps	Microsoft 托管、自托管	安全文件	Google Play 扩展任务	`Cache@2`	是	并行任务
Capgo 构建	由 Capgo 管理，可从任意 CI 调用	每次构建时从 CI secrets 发送	内置、track 与 status 标志	按 App 的构建缓存	是	构建分钟数，见定价

Xcode Cloud 未列入表中，因为它只构建 Apple 平台。Capgo Build 只构建 Capacitor 应用；而这里的其他平台也会构建原生 Kotlin 和 Java 项目。

逐平台对比

GitHub 操作

预装 Java 和 Android SDK 的 Linux runner ubuntu-latest，因此 ./gradlew bundleRelease 在……之后即可运行 actions/setup-java. gradle/actions/setup-gradle Gradle 缓存处理得很好。模拟器测试通过社区 action 在支持 KVM 的 Linux runner 上运行，例如 reactivecircus/android-emulator-runner.

签名就是从 secret 解码 keystore，并通过 Gradle 属性传递密码。上传使用 fastlane supply、Gradle Play Publisher 插件或社区 action。没有托管服务，但也没有黑箱，而且 Linux 分钟数是你找得到的最便宜的。指南：使用 GitHub Actions 自动构建 Capacitor Android.

GitLab CI

GitLab 也一样：任何包含 Android SDK 的 Docker 镜像都能在共享 Linux runner 上运行。GitLab 的 Mobile DevOps 功能包括用于 keystore 的安全文件，以及可将服务账号暴露给 job 的 Google Play 集成，这减少了 fastlane 配置中的一些样板代码。指南：在 GitLab 上自动构建 Capacitor Android.

Bitrise

Bitrise 的 Android 支持以 step 为核心：Android Build、Android Sign、Google Play Deploy，以及测试和模拟器 step。Keystore 只需在应用的 code 签名设置中上传一次。Google Play Deploy step 支持发布轨道和分阶段发布比例。你按 credit 付费，因此 Android 构建比 iOS 便宜，但仍比纯 Linux runner 贵。适合想要 UI 驱动工作流编辑器的移动团队。

Codemagic

Codemagic 将 keystore 存储为命名引用， codemagic.yaml 该引用指向 keystore，因此文件永远不会出现在代码库或日志中。 google_play publishing 块可设置发布轨道、发布比例以及是否以草稿提交。它可构建原生 Android、Flutter、React Native、Ionic 和 Capacitor。计费按构建分钟数或固定年费计划。

Appcircle

Appcircle 将 keystore 存储在 signing identities 模块中，并通过发布流程发布到 Google Play，同时支持测试人员分发和企业应用商店。自托管 Appcircle Server 是受监管团队选择它的主要原因：code 和密钥永远不会离开其网络。

CircleCI

CircleCI 发布 cimg/android 预装 SDK 的 Docker 镜像，以及一个提供模拟器测试和缓存辅助功能的 Android orb。签名和上传通过脚本或 fastlane 完成。计费使用 credits，Linux Docker 执行器是最便宜的资源类。如果 CircleCI 已经在运行你技术栈的其他部分，这是个合理的选择。

Azure DevOps

Azure Pipelines 为每个步骤都提供官方任务： Gradle@3 用于构建， AndroidSigning@3 进行签名和 zipalign，安全保管 keystore 文件，并使用 Google Play 扩展的发布任务完成轨道上传和分阶段发布。按并行任务计费。对于用过 App Center Android 构建的团队来说，这是自然的迁移选择。

Capgo 构建

Capgo 构建是供 CI 调用的 Capacitor 应用构建服务。任务运行 bun run build 以及 bunx cap sync android，然后：

bunx @capgo/cli@latest build request com.example.app \
  --platform android \
  --build-mode release \
  --android-track internal

Capgo 在其构建机上运行 Gradle，使用你的 keystore 签名，并读取最高的 versionCode Google Play 版本号并递增，然后将 AAB 上传到你选择的轨道。 --android-release-status, --android-flavor，以及 --submit-to-store-review 控制其余部分。对于 Google Play 之外的 APK 构建（kiosk 设备、MDM）， --no-playstore-upload --output-upload 则会返回一个下载链接。

设置有引导： bunx @capgo/cli@latest build init --platform android 创建或导入 keystore，并可通过 Google 登录配置 Google Cloud 服务账号和 Play Console 邀请，这一步大多数团队手动操作时最容易出错。

公平地说：在 Android 上，Capgo Build 省得最少，因为 Linux runner 到处都便宜。它在 Android 上的价值在于与 iOS pipeline 保持一致、自动管理版本号、在 CI 中无需维护 Android SDK 或 JDK，以及相同的 CLI 发布实时更新用于仅限 Web 的改动。单次 build 限制为 10 分钟。

Android 的痛点及各平台的应对方案

Keystore 丢失

过去丢失 keystore 意味着你再也无法更新 App。使用 Play App Signing 后，你持有的 keystore 只是 upload key，Play Console 支持团队可以注册新的 upload key。即便如此，仍要保留离线备份。上述每个平台都会加密存储 keystore；风险通常出在开发者笔记本上的副本。如果你需要一个新的， Android keystore 生成器可以在浏览器中创建。

Version code 冲突

Play 会拒绝上传，如果其 versionCode 版本号已被使用过。可选方案：根据 CI 运行编号生成（GitHub、GitLab、CircleCI），使用平台的 build number 变量（Bitrise、Codemagic、Appcircle），或者让 Capgo Build 从 Play 读取最新值并递增。

Gradle 构建缓慢

一次冷启动的 Capacitor Android 构建会下载数百 MB 的依赖。缓存 ~/.gradle/caches 以及 ~/.gradle/wrapper 能让重复构建快得多。在托管运行器上为 Gradle 分配足够的内存， gradle.properties (org.gradle.jvmargs=-Xmx4g并采用并行任务同时构建 iOS 和 Android，而不是串行执行。

插件与 AGP 升级

新版本的 Android Gradle Plugin 会导致旧插件失效。请在项目中固定 AGP 版本，并在分支上进行升级。具体修复方案见修复 AGP 9 中的 Capacitor 插件构建错误以及如何在 Capacitor 中解决 Android 构建错误.

Play 服务账号权限

“The caller does not have permission” 是最常见的上传错误。必须在 Play Console 的“用户和权限”中邀请该服务账号，并授予该应用的发布权限，同时必须在其 Google Cloud 项目中启用 Google Play Android Developer API。新服务账号可能需要一段时间才能被 API 接受。

如何选择

你的情况	适用场景
仅 Android，已使用 GitHub 或 GitLab	GitHub Actions 或 GitLab CI
希望使用可视化工作流编辑器的原生 Android 团队	Bitrise
希望托管密钥库并用 YAML 发布到 Play 的跨平台团队	Codemagic
必须完全自托管	Appcircle Server 或自托管 runners
从 App Center 迁移，使用 Microsoft 技术栈	Azure DevOps
对于 Capacitor 应用，想通过任意 CI 的单一 CLI 同时支持 Android 和 iOS	Capgo 构建

关于同一决策中 iOS 这一侧，请阅读 iOS 应用 CI/CD 平台对比。具体到 Capacitor 应用（包括 Live Updates），请参阅 Capacitor 应用的 CI/CD 平台对比.

迁移前的快速检查清单

请确认你已拿到 upload keystore 文件和两个密码，并确认 alias 一致。
在 Play Console 中查看哪个证书被注册为 upload key，并将其 SHA-1 与 keytool -list -v -keystore release.jks.
为新的 CI 创建专用的服务账号，而不是复用个人账号。
确保新平台在 Capacitor 8 项目中使用 JDK 21 构建。
在切换生产版本发布前，先做一次内部测试渠道的 upload。