快速结论：可靠的 Android CI/CD 应生成可追踪的签名 APK/AAB，保存 mapping 和产物，并把本地 release 检查纳入流水线。
开发者常问的问题
- 如何自动化 Android APK 或 AAB 构建？
- 如何用 GitHub Actions 或 GitLab CI 构建 Android？
- CI 中如何处理 Android 签名密钥？
- 多渠道构建如何自动化？
开发者通常想要什么
一个好的流水线不只是自动打包，还要可复现、可追踪、可验证。它应该输出明确命名的 APK/AAB、保存 mapping、记录版本信息，并在发布前运行必要检查。
推荐 CI 流程
典型步骤包括 checkout、安装 JDK、Gradle cache、运行测试、执行 assemble/bundle、注入签名配置、归档产物、上传 artifacts、生成 release notes 和运行 release readiness 检查。
常见自动化错误
常见问题包括把 keystore 提交进仓库、在日志打印密码、没有保存 mapping、产物命名不含 variant/version、只构建一个渠道，以及本地构建与 CI 构建配置不一致。
ADB Pro 如何帮助
CI/CD Tools 生成 GitHub Actions、GitLab CI 或 Jenkins 配置；Build Tools 帮你对齐本地任务；Release Readiness 把本地检查迁移到发布流程。
FAQ：CI 应该构建 APK、AAB 还是两个都构建？
取决于分发渠道。Google Play 通常需要 AAB，第三方市场或内部测试可能需要 APK。多渠道发布通常两个都要。
FAQ：签名密码应该放在哪里？
应放在 CI secrets 或安全变量里，运行时注入，不要写进仓库、Gradle 文件或构建日志。
FAQ：发布检查应该在本地还是 CI 跑？
两边都应该有。本地用于快速发现问题，CI 用于保证每次候选发布都经过同一套可审计检查。
相关指南
多商店发布清单、Release Readiness Checklist 和 Release Signing Guide 可以补齐自动化发布链路。