先把问题拆开：混淆不是加固的同义词
在 Android 构建流程里，ProGuard 或 R8 通常只做两件事：压缩未使用的类与方法、把类名/方法名/字段名替换成 a、b、c 这类短标识。它的直接收益是减小体积、提高逆向阅读成本。但很多团队在发布检查表上写下“已开启混淆”，就默认这个包已经“加固”过了，这是一个常见的认知错位。
混淆改变的是代码的可读性，它不改变 APK 的结构，也不阻止任何人解包、改资源、重新签名。换句话说，混淆让“看懂”变难，但没有让“改动”变难。要判断只做混淆算不算加固，需要把防护目标拆成三层来看。
第一层：代码混淆解决什么，不解决什么
混淆主要对抗的是静态分析。攻击者用反编译工具打开 dex，看到的是被重命名的符号，字符串常量、控制流、资源文件名仍然清晰可见。所以混淆的实际效果取决于配置：
- 能防住的：随手翻代码找接口地址、找校验逻辑、找开关字段的成本上升。
- 防不住的：字符串仍是明文，反射调用点仍能定位，资源文件与 AndroidManifest 完全没动。
- 容易踩的坑：为了“混淆得更狠”把反射、序列化、JNI 回调相关的类也一起改掉，导致线上崩溃；或者只开了压缩没开混淆，误以为已经生效。
结论很直接：混淆是必要的基线，但它属于“提高阅读成本”，不属于“阻止篡改”。把它单独称为 APK 加固，是把手段当成了目标。
第二层：完整性校验解决什么
完整性校验回答的问题是：这个包还是不是我签发的那个包？常见做法包括校验签名证书指纹、校验 dex 或关键资源的摘要、在运行时比对预期值。它防的是“包被改过但仍在运行”的情况，例如插入广告 SDK、替换支付回调地址、注入启动页。
这一层的关键不在算法强弱，而在校验点是否可被绕过。如果校验逻辑写在一个容易被定位的方法里，攻击者改一个返回值就失效了。因此实践中通常要做的是：
- 校验分散在多个位置，且与业务逻辑耦合，避免单点开关。
- 校验结果不要只返回布尔值，而是参与后续流程的正常执行。
- 签名指纹比对使用证书公钥摘要，而不是仅比对包名或版本号。
需要说明的是，完整性校验是“发现异常”，不是“阻止安装”。它无法阻止别人把你的包重新签名后分发，只能让你的应用在运行时识别出自己被动过。
第三层：防二次打包解决什么
二次打包指的是把原包解包、修改、重新签名后分发。它和完整性校验是同一枚硬币的两面：校验是检测手段，防二次打包是让重打包后的包无法正常运行或无法获得收益。常见思路包括签名一致性判断、渠道信息与签名绑定、关键能力依赖服务端下发的凭证等。
这里要避免一个误区：纯客户端的对抗没有终点。攻击者可以不断打补丁，防护方只能不断提高成本。因此更现实的目标是“让重打包的收益低于成本”，而不是“绝对不可破解”。把关键校验和服务端结合，往往比在客户端堆更多检测代码更有效。
三层怎么组合：一个可执行的顺序
如果要在发布流程里落地，建议按下面的顺序检查，而不是笼统地写一句“已加固”：
- 构建期：确认 R8/ProGuard 规则生效，保留反射与序列化所需的类，产出 mapping 文件并归档，便于线上崩溃还原。
- 签名期：固定签名证书，记录证书摘要；发布包与测试包使用不同证书，避免测试证书流入生产。
- 运行期：加入签名与关键资源校验，校验结果参与业务流程；对异常情况做上报而非静默放行。
- 分发后：监控异常上报中的签名不匹配、校验失败比例，作为发现重打包的早期信号。
如果团队需要把加固、签名与分发环节统一管理，可以参考站内的服务说明：APK 加固与签名相关服务。另外，判断一个包是否已经被二次打包，可以对照这篇排查思路：APK 是否被二次打包的三层校验方法。
回到标题的问题
只做混淆，不算完整的 APK 加固。它解决的是“读起来费劲”，不解决“改起来容易”。完整性校验负责发现篡改，防二次打包负责提高重打包成本，三者面向不同的攻击面，缺一层就会留下明显缺口。对大多数应用来说，合理的做法是：混淆作为基线必开，完整性校验作为运行期兜底，防二次打包结合服务端能力做成本抬升，而不是指望某一种手段包打天下。