Android App Bundle（AAB）混淆工作原理及与APK混淆的区别

一、AAB的混淆工作机制 #

混淆的核心执行环节在AAB打包前完成，不会针对已生成的AAB文件直接做混淆处理，具体流程如下：

• 构建AAB时，R8/ProGuard会先对所有编译后的class文件执行混淆逻辑，包括类/字段/方法短名重命名、无用代码裁剪、字节码优化，规则完全由项目中配置的proguard-rules.pro以及各依赖库自带的混淆规则决定。
• 混淆完成后，处理后的代码、资源文件、原生库等内容才会被打包为AAB格式文件，同时生成对应mapping.txt文件，记录原始名称与混淆后名称的映射关系，用于后续崩溃堆栈还原。
• 若使用Google Play官方应用签名服务，Play商店在基于AAB生成分发用APK时，不会再额外执行代码混淆操作，仅会做模块拆分、资源对齐等分发侧优化。

二、AAB混淆与APK混淆的区别 #

二者的核心混淆逻辑都是由R8/ProGuard实现，差异主要体现在执行阶段、作用范围和后续分发适配三个维度：

• 执行时机与限制不同：常规APK构建的混淆在打包前完成，也支持对已生成的APK做二次混淆（比如第三方加固环节的二次混淆），直接修改APK内的dex文件即可。而AAB不支持对已生成的成品包做直接混淆，因为AAB是结构化的分发归档文件，直接修改会破坏内部结构校验和签名合法性，无法正常上传到应用商店。
• 作用范围不同：AAB构建时的混淆会覆盖项目所有模块，包括基础模块和所有动态Feature模块，生成的mapping.txt包含全模块的名称映射关系，全局统一。如果是单独对APK做混淆，仅能处理当前APK内包含的dex文件，若项目有多个拆分APK，需要分别处理，容易出现映射关系不一致的问题。
• 分发兼容性不同：AAB混淆后的结果会被沿用到Play商店生成的所有分发APK中，同一类/方法的混淆名称在所有版本的分发APK中完全一致，便于后续崩溃排查。如果是单独构建多个APK分别混淆，可能出现同一类在不同APK中被重命名为不同名称的情况，会大幅提升问题排查成本。

内容的提问来源于stack exchange，提问作者Nặśř' Eddíŋě