快速结论：一个 release-ready Android 构建应该通过安全、签名、压缩、SDK 合规、native 兼容性和依赖健康等检查。
开发者常问的问题
- Android App 发布前应该检查什么？
- 如何发现 debug flag 和暴露的 API Key？
- 哪些 Gradle 和签名设置影响发布？
- 如何检查 native libraries 的 16 KB page-size 兼容性？
为什么发布检查重要
很多发布事故不会导致编译失败，例如 debug 标记、测试域名、错误签名、未递增 versionCode、SDK 不合规或 native 兼容性问题。发布检查的目的就是提前暴露这些风险。
核心清单
建议覆盖 artifact identity、签名身份、release build type、环境配置、debuggable、R8/ProGuard、数据库 keep rules、cleartext traffic、测试域名、API key、versionCode、targetSdk、16 KB page size、依赖健康和 CI/CD 元数据。
手动流程
先选择候选 APK/AAB，再确认构建来源、签名、variant、manifest、资源、依赖和 SDK 信息。对于远程产物，应记录仓库、release tag、SHA-256 和下载路径。
ADB Pro 如何帮助
Release Readiness 将检查结果汇总成 PASS、WARNING、FAIL，并为每个结果提供 Docs 入口；Quick Setup、Dependency Health、R8 Assistant 和 Signing Tools 补齐对应修复路径。
VersionCode 检查需要上下文
本地重复构建相同 versionCode 不一定是错误。真正会被商店拒绝的是低于或等于目标商店已接受基线的 versionCode，因此本地历史相同更适合作为提醒而非绝对阻断。
FAQ：每次上传前都要跑检查吗？
建议每个 release candidate 都跑，尤其是依赖、Gradle、签名、CI/CD 或 SDK 配置发生变化后。
FAQ：Gradle 构建成功就够了吗？
不够。构建成功仍可能包含 debug flag、泄露 key、签名 scheme 缺失、测试环境配置或 release-only 崩溃。
FAQ：检查应该手动还是自动？
两者都需要。手动审查提供上下文，自动或工具辅助检查避免重复步骤被跳过。
相关指南
Release Signing Guide、Android APK Obfuscation 和 AAB 安装指南可以覆盖发布验证的关键分支。