TG咨询云上安卓应用部署流水线设计，核心是把代码检查、构建、测试和发布连接起来，让每次变更都能按相同步骤验证。先明确“部署”指什么：向 Google Play 发布应用，还是生成 APK 后交给内部用户安装。前者通常以 Android App Bundle（AAB）为发布产物；后者可能需要 APK，发布渠道和测试步骤也会不同。
先定发布路径，再选云端工具
一个常见组合是 GitHub Actions 执行工作流、Gradle 构建应用，再将产物上传到 Google Play Console 的测试轨道。Firebase Test Lab 可用于云端设备测试；若项目只需验证构建和单元测试，可以先不接入设备测试服务，减少配置和运行成本。
团队已有 Jenkins 或其他 CI 服务时，也可以继续使用，不必为“上云”重写所有流程。选择时看三点：代码托管平台能否触发构建、是否方便管理密钥、设备测试和发布权限能否分开。无论选哪种工具，构建环境都应固定 JDK、Android SDK 与 Gradle 版本，并记录变更，减少环境差异导致的偶发失败。
把流水线拆成可执行阶段
- 提交触发：为拉取请求和主分支配置不同流程。拉取请求先运行静态检查与测试；合并后再构建候选发布包。
- 准备环境：安装项目所需的 JDK 和 Android SDK，使用 Gradle Wrapper 执行构建，并缓存 Gradle 依赖以缩短后续任务时间。缓存应有失效策略，避免旧依赖掩盖问题。
- 检查代码：运行单元测试和 Android Lint。测试失败或存在需要阻断发布的问题时，停止后续步骤，而不是继续生成可发布产物。
- 构建并留档：按发布目标生成 AAB 或 APK，同时保存版本号、提交记录和构建日志。Android 的 versionCode 每次发布都要递增；版本名称则用于展示，可按团队约定管理。
- 签名与发布：签名密钥放在 CI 的密钥管理功能中，不写入代码仓库、构建日志或普通配置文件。通过权限控制限制谁能触发正式发布；先推送到测试轨道，确认后再发布到生产轨道。
签名、安全与回滚要分开设计
避免密钥跟着代码走
上传密钥和应用签名密钥不是一回事。启用 Google Play App Signing 时，应用签名密钥由 Google Play 管理，开发者上传经过上传密钥签名的版本；仍需保护上传密钥，并妥善保留恢复所需的信息。CI 任务只在发布阶段读取密钥，日志中屏蔽敏感值，日常测试任务不应拥有发布权限。
失败时回到可用版本
将“构建成功”和“发布成功”分开记录，保留每次产物与对应提交的关联。出现问题时，可以停止后续推广，并根据 Google Play 的发布能力处理版本；内部 APK 分发则应准备上一版产物和明确的替换步骤。回滚不能只靠重新构建旧代码，因为依赖或构建环境可能已经变化。
先跑小流程，再增加自动化
云上安卓应用部署流水线设计不必一次覆盖所有场景。先做到每次提交可检查、合并后可重复构建、正式发布需人工确认；稳定后再增加 Firebase Test Lab 的设备覆盖、自动版本管理或分阶段推广。云端设备测试的耗时会受设备型号、测试数量和排队情况影响，应把它安排在适合的触发节点，而不是假设每次提交都能快速完成。
常见问题
CI 应该生成 AAB 还是 APK？
发布到 Google Play 通常使用 AAB；需要直接安装或通过内部渠道分发时，可能使用 APK。按目标渠道配置构建任务即可。
每次提交都要做真机测试吗？
不一定。可以先让每次提交运行单元测试和静态检查，再对合并版本或候选发布版本执行云端设备测试，具体频率取决于项目风险和运行成本。
流水线失败后，怎样避免错误版本上线？
将测试失败设为阻断条件，并把正式发布权限留给受控任务或授权人员。按这些阶段逐步落地，云上安卓应用部署流水线设计就能兼顾重复构建、安全发布与问题处置。