面向 Android 混淆、资源保护、应用签名、AAB 部署和发版检查的场景化指南。
每篇指南都会解释手动流程、常见错误，以及 ADB Pro 如何把重复步骤自动化到 JetBrains IDE 内。
AAB 是应用商店分发格式，不能像 APK 一样直接安装到设备。本地测试需要用 bundletool 生成 APKS 或 Universal APK，配合正确签名和目标设备选择完成安装。
一个 Android 项目可以通过 flavor、applicationId、资源覆盖和签名配置产出多个 App，但必须把包名、图标、版本、渠道和签名放进可复现的构建配置里。
Android 混淆不是一个开关。稳定发布通常需要 R8 代码混淆、精确 keep 规则、mapping 归档、可选资源混淆，以及对最终 APK/AAB 做真实运行测试。
Android release 产物需要稳定 keystore、正确 signingConfig、可验证签名，以及本地、CI 和应用商店之间一致的签名假设。
多商店 Android 发布需要一致的构建产物、签名、版本号、隐私检查、SDK 合规、渠道差异和可重复的上传前清单。
可靠的 Android CI/CD 应生成可追踪的签名 APK/AAB，保存 mapping 和产物，并把本地 release 检查纳入流水线。
Android 代码混淆最安全的方式是在标准 Gradle release 构建里运行 R8，审查 keep 规则，保存 mapping，并验证最终 APK 或 AAB。
minifyEnabled true 会为 release 变体启用 R8，但安全发布还需要 keep 规则、mapping 保存、资源压缩检查和运行验证。
资源混淆会重命名 Android 资源标识，但必须通过白名单保护运行时依赖资源，并保持 Gradle 插件配置可复现。
R8 支持 ProGuard dictionary 指令，包括类名、成员名和包名混淆字典，但字典只控制命名风格，不能替代 keep 规则和发布测试。
一个 release-ready Android 构建应该通过安全、签名、压缩、SDK 合规、native 兼容性和依赖健康等检查。
本地安装 AAB 需要 bundletool、生成 APKS、正确签名，以及明确是面向单个目标设备还是多设备 Universal APK 测试。
Android release 产物必须 zipalign、使用正确签名 scheme，并在分发前完成签名验证。