Android AAR库第三方依赖未正确打包问题求助

问题背景 #

我正在开发一个需要打包为AAR文件的Android库，希望将依赖的第三方库（比如Lottie）包含在AAR中，避免使用者手动添加。目前已经用api和implementation添加了依赖，也配置了生成AAR的构建，但直接引入AAR文件到项目后，第三方依赖无法访问；而通过模块依赖（implementation(project(":PrettyDialogLibrary"))）引入时功能正常。

我的疑问 #

1. 用api和implementation添加依赖是在AAR中打包第三方依赖的正确方式吗？
2. 是否需要特殊步骤，比如处理ProGuard规则或避免消费项目中的依赖冲突？

核心问题说明 #

AAR文件本身不会自动打包第三方依赖的代码，它仅会记录依赖的元信息。当通过模块依赖引入时，Gradle会自动解析并拉取这些依赖；但直接引入本地AAR文件时，Gradle无法获取这些元信息，导致依赖缺失。

疑问解答 #

1. 关于依赖声明方式

   • api和implementation的作用是控制依赖的传递性：
     • api：依赖会传递给消费你的库的项目，适合需要让使用者直接访问的依赖（比如库中暴露了Lottie的API）
     • implementation：依赖仅在库内部可用，不会传递给消费项目
   • 但无论用哪种方式，第三方依赖的代码都不会被打包进AAR，这两种方式只是影响依赖的传递性，不是打包依赖到AAR的方法。

2. 特殊步骤处理

   • ProGuard规则：如果库开启了混淆，需要确保第三方依赖的规则被正确处理：
     • 在consumer-rules.pro中添加第三方依赖的ProGuard规则（比如Lottie的规则），避免消费项目混淆时破坏依赖代码
   • 依赖冲突：即使解决了打包问题，也要注意版本冲突。建议在库中使用api声明依赖时，尽量指定兼容的版本范围，或者在消费项目中通过resolutionStrategy统一版本。

实现第三方依赖打包进AAR的方案 #

要把第三方依赖的代码真正打包进AAR，需要使用fat AAR的方式，常用实现方法如下：

方案1：使用Gradle插件（推荐） #

可以使用现成的Gradle插件构建包含依赖的fat AAR，比如com.kezong.fat-aar：

1. 在库的settings.gradle中添加插件仓库：

   pluginManagement {
       repositories {
           gradlePluginPortal()
           mavenCentral()
       }
   }
   

2. 在库的build.gradle中应用插件：

   plugins {
       alias(libs.plugins.android.library)
       alias(libs.plugins.jetbrains.kotlin.android)
       id 'com.kezong.fat-aar' version '1.3.8'
   }
   

3. 修改依赖声明，将需要打包的依赖用embed替换api或implementation：

   dependencies {
       // 内部依赖，不需要打包的继续用implementation
       implementation(libs.androidx.core.ktx)
       implementation(libs.androidx.appcompat)
       implementation(libs.material)
       
       // 需要打包进AAR的依赖用embed
       embed(libs.lottie)
       
       // 测试依赖保持不变
       testImplementation(libs.junit)
       androidTestImplementation(libs.androidx.junit)
       androidTestImplementation(libs.androidx.espresso.core)
   }
   

4. 重新构建AAR，生成的AAR会包含Lottie的代码，直接引入到项目中即可使用。

方案2：手动打包（不推荐） #

手动将第三方依赖的jar/aar解压，合并到库的构建产物中，再重新打包成AAR。这种方法容易出错，维护成本高，不建议使用。

注意事项 #

• 打包第三方依赖进AAR会增大AAR体积，需权衡必要性
• 避免打包系统依赖（比如AndroidX核心库），这类依赖通常消费项目已包含，易导致重复依赖
• 确保第三方依赖的许可允许你将其代码打包进自己的库中

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