如何单次对多Android库执行ProGuard混淆并保留私有API调用

这个场景在插件化库分发中非常常见——既要混淆核心库A的私有代码，又要让依赖A的插件库B能正常调用指定的私有API，同时还要分别发布独立的混淆后AAR。我来给你拆解可行的解决方案：

核心思路 #

关键是让库A保留所有需要被B调用的私有API的原始名称，同时混淆其他无关代码；并将这些保留规则传递给库B，确保B在混淆时不会破坏对A的API调用。这样不管是开发阶段还是发布后，B调用A的API名称都是一致的，不会出现找不到方法的问题。

步骤1：配置库A的混淆规则 #

在库A的proguard-rules.pro中，精确指定需要暴露给B的私有API（类、方法、字段），用-keep规则保留它们的原始名称。例如：

# 保留给B调用的内部类及方法
-keep class com.example.librarya.internal.CorePrivateHelper {
    void init(android.content.Context);
    String getConfigValue(java.lang.String);
}

# 如果有需要保留的字段，也添加进去
-keepclassmembers class com.example.librarya.internal.CorePrivateHelper {
    private int internalState;
}

注意：只保留必须给B调用的API，不要过度使用-keep，避免影响混淆效果。

步骤2：让库A传递保留规则给依赖模块 #

在库A的build.gradle（Android块下）中，配置consumerProguardFiles，将上述保留规则传递给所有依赖A的模块（比如B）：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            # 传递保留规则给依赖A的模块
            consumerProguardFiles 'proguard-consumer-rules.pro'
        }
    }
}

然后创建proguard-consumer-rules.pro文件，内容和proguard-rules.pro中保留API的规则完全一致。这样B在构建时会自动应用这些规则，不会混淆对A的API调用。

步骤3：构建并依赖混淆后的库A #

1. 执行库A的assembleRelease任务，生成混淆后的AAR（路径：libraryA/build/outputs/aar/libraryA-release.aar）。
2. 将这个AAR发布到你的私有maven仓库（或本地maven），方便库B依赖。
3. 在库B的build.gradle中，修改依赖为混淆后的AAR版本：

   implementation 'com.example:libraryA:1.0.0@aar'
   

步骤4：构建混淆后的库B #

直接执行库B的assembleRelease任务即可。此时B的混淆过程会自动应用A传递过来的规则，保留对A私有API的调用名称；同时B自身的代码会被正常混淆。

进阶场景：如果不想保留API原始名称（可选） #

如果你的需求是连给B的API也要混淆名称（但会增加版本绑定的复杂度），可以这样做：

1. 构建库A的release版本后，拿到mapping.txt文件（路径：libraryA/build/outputs/mapping/release/mapping.txt）。
2. 在库B的build.gradle中，指定应用A的mapping文件：

   android {
       buildTypes {
           release {
               minifyEnabled true
               proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
               # 应用A的混淆映射，让B的调用对应A混淆后的名称
               applyMapping file('../libraryA/build/outputs/mapping/release/mapping.txt')
           }
       }
   }
   

   这种方式下，A和B的版本必须严格绑定（每次A的mapping变化，B都要重新构建），不适合用户自由搭配插件，所以更推荐前面的保留名称方案。

测试验证 #

1. 单独测试混淆后的A：用测试APP依赖A的release AAR，确保核心功能正常，且未被保留的私有API已被混淆。
2. 测试混淆后的B：依赖混淆后的A，验证B能正常调用A的私有API。

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