Android项目开启minifyEnabled后R8未混淆代码的原因排查

直接按照排查成本从低到高定位，不用无目的翻配置：

先确认R8真的在当前构建流程里生效了 #

• 不要只看到minifyReleaseWithR8任务跑完就默认混淆开了，先核对你反编译的APK来源：是不是当前选中构建变体对应的最新输出包，有没有误拿debug包、或者上一次构建遗留的旧Release包做反编译。
• 拉取构建控制台的完整日志，搜索R8关键字，确认日志输出里明确记录了minifyEnabled: true的状态。很多人踩过优先级坑：minifyEnabled true写在了buildTypes.release块里，但是自定义的productFlavor块里单独写了同名属性minifyEnabled false，因为Flavor配置的优先级高于buildType配置，实际构建时混淆是关闭的，根本不会触发变换。
• 检查gradle.properties全局配置，确认没有开android.enableR8=false的开关，这个开关会直接跳过R8的混淆、裁剪全流程。

再核对是不是规则把所有业务代码全保留了 #

这是最高发的原因：

• 先找构建输出目录下的mapping.txt文件（你的规则里已经配置了-printmapping mapping.txt），路径一般在app/build/outputs/mapping/release/下：
  • 如果mapping.txt有大量类名、方法名的原始名称到短名的映射记录，说明R8已经正常跑了混淆逻辑，只是你在apktool里看到的同名类都是被规则显式保留的类（比如JS接口、跨模块导航接口、异常类这些本来就必须留原始名的元素）。
  • 如果mapping.txt几乎是空的，没有任何映射记录，说明确实没触发混淆，接着往下查。
• 临时在proguard规则里加-printusage app_usage.txt，重新构建一次，打开生成的usage文件，R8会明确标注每个类被保留的触发规则，顺着提示就能找到是哪条通配规则把全应用的类都keep住了——很多人写规则的时候把通配符写太宽，比如-keep class * implements ru.sbi.android.**、或者不小心写了覆盖整个业务包名的-keep class ru.sbi.** {*;}，等于把所有自己写的代码全留了原始名，看起来就像R8没工作一样。
• 不要漏查依赖AAR里内置的consumer-proguard规则：很多第三方SDK会在自己的AAR里附带consumer.txt配置，里面可能存在大范围的keep规则，这些规则会在构建时自动合并到你的混淆规则里，不专门翻依赖内容很难发现。

排除反编译工具的判断误差 #

• 别用apktool的默认输出判断混淆效果：apktool主要解析资源和Manifest，看代码混淆要直接用jadx打开APK里的dex文件，找业务层的普通工具类、POJO类看命名是不是变成了无意义的短字符。apktool本身不会对dex里的类名做转换展示，哪怕代码已经混淆了，拆出来的AndroidManifest里的组件类名只要是被保留的，就会显示原始名，很容易造成“没混淆”的误判。
• 可以临时在proguard规则里加强制混淆的测试规则，去掉所有自己写的keep规则跑一次构建，看普通业务类是不是被改成了短名，如果改了，就说明R8流程是好的，问题全出在自己的规则太宽上。

常见的隐形踩坑点：Kotlin反射相关的配置、Crashlytics的规则、跨模块导航的keep规则如果通配符写宽，很容易把相邻包下的业务类也一并保留，单看自己写的主规则很难排查到。

内容的提问来源于stack exchange，提问作者Fyodor Sherstobitov