1. Google 到底要求什么。官方口径不是「用混淆藏秘密」，而是「做好压缩与混淆抬高反编译成本，把真正的安全校验放到服务端」。Android 构建文档（https://developer.android.com/build/shrink-code）把 R8 定义为 Android Gradle 插件默认的代码压缩器：它在一次构建中完成代码裁剪、资源压缩、优化与标识符重命名（即混淆），并明确指出「混淆本身不是安全特性」——它抬高的是「随手反编译」的门槛，并不能让客户端变得可信。开发者安全指南（https://developer.android.com/privacy-and-security/security-best-practices）从另一面给出同样结论：任何密钥、接口地址或服务端逻辑都不要写进 APK，因为设备上的一切都能被读出来。
2. 发布版必须打开 R8。在 app 模块的 build.gradle(.kts) 里，release 构建类型应设置 minifyEnabled true（走 R8，ProGuard 兼容）与 shrinkResources true，并引用 proguard-rules.pro。shrinkResources 会删掉无用资源，且只有与 minifyEnabled 同时开启才生效。R8 默认使用 proguard-android-optimize.txt，在裁剪之外还会做方法内联、类合并、去除无用参数等优化。验证方式：对比 debug 与 release 的包体积，并检查 build/outputs/mapping/release/mapping.txt 是否生成。
3. Keep 规则是 release 崩溃的头号来源。R8 会重命名并删除它认为「不可达」的类，包括只能通过反射访问、它看不见的类。常见出问题的是：Gson/Moshi/Jackson 的 DTO、Retrofit 接口与其 @SerializedName 模型、Room 实体、kotlinx.serialization、ViewBinding/DataBinding、Parcelable、XML 里 inflate 的自定义 View，以及所有按类名加载的东西（Class.forName、JNI、ServiceLoader）。线上表现为 NoSuchMethodException、ClassNotFoundException、JSON 字段变空或改名，或「只有 release 崩、debug 不崩」。正确做法是加精确的 -keep 规则（例如给 DTO 加 -keep class com.example.model.** { *; }，给 @SerializedName 字段加 -keepclassmembers），而不是 -keep 全部；并且一定要测 release 包，不能只测 debug。Kotlin 通常还需 -keepclassmembers class **$WhenMappings 与 metadata 规则；AndroidX 自带 consumer rules，R8 会自动合并。
4. 上传 mapping.txt，否则崩溃日志不可读。R8 会产出 build/app/outputs/mapping/release/mapping.txt（连同 configuration.txt、seeds.txt）。发布时把它一并上传到 Play Console，Play 才能把线上堆栈与 ANR 还原成可读类名方法名；不上传的话，每个线上崩溃看起来都是 a.a.a.b(Unknown Source)，等于放弃排障能力。每个上线版本都要保留其对应的 mapping，重新构建的版本需要新的 mapping。
5. 安全判定绝不能放在客户端。最常见的致命设计错误，是把 isPremium / LicenseValid / IsTampered 这类标志放在 App 本地判断——客户端能判断的，客户端就能改，用 apktool 或 Frida 改一个字节即可翻转。正确做法是把判定移到后端：App 只负责上交「证据」（令牌、购买凭证、完整性裁定），由服务器做决定。具体例如：用 Play Developer API 在服务端校验 Google Play 结算购买（purchases.subscriptionsv2 / purchases.products），而不是信任设备端的确认；任何从不离开设备的「License 校验」都只是装饰，不是防护。
6. Play Integrity API 就是拿到这个服务端裁定的官方途径。Play Integrity API（https://developer.android.com/google/play/integrity）已取代废弃的 SafetyNet Attestation API。App 调用后拿到一个加密、带签名、短时效的完整性裁定，必须由 Google 服务器（或你的后端调用 Play Integrity API）解密并验证，不能在设备上验证。裁定包含设备完整性信号（MEETS_BASIC_INTEGRITY / MEETS_DEVICE_INTEGRITY / MEETS_STRONG_INTEGRITY）、应用完整性信号（二进制是否与你在 Play 上传的一致，可识别被重打包或魔改的 APK），以及账号与授权信号（PLAY_RECOGNITION / LICENSED）。新接入应使用 Standard 请求（官方推荐），Classic 请求属旧流程。配置入口在 Play Console 的 App integrity，可查看裁定失败率。注意：设备裁定不通过只是「信号」而非「铁证」，Google 明确提醒不要凭单台设备判定，应看整体比例与速率；默认每日请求额度 10,000 次（随装机量提升），更高额度见 https://support.google.com/googleplay/android-developer/answer/11395166 。
7. 签名、防篡改与 Play 的一键保护。两条线：(a) 应用签名——现代应用使用 APK Signature Scheme v2/v3（v4 用于快速安装）；启用 Play 应用签名后签名密钥由 Google 保管，你只持有上传密钥，因此密钥泄露不再等于应用被劫持，且可轮换上传密钥。运行时可比对证书，但这个校验本身也可被 patch，只能当服务端信号用。(b) Google Play 自动保护（Protected with Play，https://support.google.com/googleplay/android-developer/answer/13857328）是 Play Console 的一键开关，会在应用内加入运行时防篡改与防盗版检测，并在安装的二进制与商店版本不一致时上报，你无需自建后端。建议它与 Play Integrity 的应用完整性裁定配合使用，而不是只依赖其一。
8. 加固客户端，但假设它一定会被读。除混淆外的实操清单：关闭 debuggable 并移除 android:debuggable；release 去掉日志（R8 用 -assumenosideeffects 移除 Log.d，或提高日志级别）；不要硬编码 API key、token、接口地址，改由运行时下发并可轮换；设备上必须留存的密钥用 Android Keystore（https://developer.android.com/privacy-and-security/keystore）而非内嵌；加证书/公钥固定（pinning），防止假服务器或抓包代理驱动你的 App；root/模拟器/调试器检测只当软信号（易被绕过，但抬高成本）；对高价值字符串常量（接口、功能开关）做 R8 字符串混淆或商业加固；只有在确实需要时才把敏感逻辑放进 NDK/native——native 更难反编译但并非不可逆。
9. 政策维度：被克隆、被重打包，以及混淆的边界。混淆自己的应用合理且被鼓励；用混淆向 Google 审核隐藏违规行为则不行——Google 的开发者计划政策（https://support.google.com/googleplay/android-developer/answer/17190352）及其恶意软件（https://support.google.com/googleplay/android-developer/answer/9888380）、移动端不受欢迎软件（https://support.google.com/googleplay/android-developer/answer/9970222）、欺骗性行为（https://support.google.com/googleplay/android-developer/answer/16680223）政策，禁止具有欺骗性、隐瞒数据收集或功能、滥用设备/网络/个人数据的应用；靠「行为被藏起来」才成立的应用过不了审核，上线后被发现的会被下架。反过来说，客户端防护薄弱正是别人重打包你的应用、剥离你的计费、克隆你的产品的原因——当你对山寨/恶意克隆提 IP 投诉或恶意软件举报时，引用的正是上面这些政策，Play 的仿冒规则也覆盖复制你身份的山寨应用。举报入口在 Play Console 的 IP 投诉表单与政策举报路径。
10. 发布前反编译自查（每个版本做一次）：① 构建 release 的 AAB/APK；② 用 apktool/JADX 反编译 release 包（不是 debug），确认没有暴露业务逻辑的可读类名/方法名、没有明文密钥；③ 在 APK 里 grep 你的 API key、接口地址、Bearer、password、secret、http:// 与调试开关（如 strings assets/* | grep -i key）；④ 在 root 测试机上跑 Frida，试两分钟攻击——翻转 License/高级标志、hook 完整性调用、读本地存储，凡是成功的都必须挪到服务端；⑤ 确认已生成并上传本版本的 R8/ProGuard mapping.txt；⑥ 确认已开启 Play Integrity 和/或 Protected with Play，且后端确实会拒绝不通过的裁定。如果混淆是你唯一的防护手段，就把该应用的数据与付费逻辑当作公开的。