有关 Android Studio 重复引入包的问题和解决方案

时间:2021-10-07 05:07:29

虽然相同包名相同类名的文件在不同 SDK 中出现的概率极低,但是一旦出现,处理起来就比较棘手。最好的解决方案就是联系提供 SDK 的技术人员反映问题,让其通过修改源码重新打包一个新的 Jar 包。

还有一个解决办法就是,重新命名 Jar 包里的包名或者文件名。网上也有一个工具:jarjar.jar,可以帮助我们重命名包名和文件名,以及 Jar 包中的相关代码引用路径。参考地址如下:

该工具提供有多种使用方式,最简单实用的就是通过命令行使用。举个例子,打开命令行工具,执行:

作者:唠嗑008
链接:https://www.jianshu.com/p/dd5d4fda1df8
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

随着产品功能需求的增加,我们开发的安卓项目不得不入引入越来越多的第三方库。这些三方库可能以 Jar 包的形式放置在 libs 目录下,可能以 Gradle 远程依赖的形式下载引入,也可能是以 Library Module 的形式放置在工程目录下,等等。

随之而来的问题是,复杂的依赖关系很可能导致重复引入包的问题。比较常见的使用场景就是 support-v4 包的重复引入。这样就会导致,执行 Run 操作打包生成 Apk 文件时出现类似这样的 DexException 错误提示,导致编译失败:

Error:Execution failed for task ':app:transformClassesWithDexForDebug'.
> com.android.build.api.transform.TransformException:
com.android.ide.common.process.ProcessException:
java.util.concurrent.ExecutionException: com.android.dex.DexException:
Multiple dex files define Landroid/support/v4/app/ActivityCompatHoneycomb; 有多种使用场景会出现这种问题。根据解决方案的不同,大体上可以分为两种:本地 Jar 包重复嵌入和 Gradle 远程重复依赖。 第一种,比较好理解。比如 app module 与 library module 各自 libs 目录中嵌入了相同的 Jar 包。这种情况也比较好解决,只需要将 app module 下的重复 jar 包删除即可。 第二种,稍微复杂一点。比如对于 Gradle 远程依赖的两个第三方库,他们内部同时依赖相同的另一个辅助第三方库。这个时候我们就没办法像第
一种情况那样手动删除本地文件。好在 Gradle 插件提供了相应的解决方案,即使用 exclude 语法,如: compile 'com.yifeng.example:example-1:1.0'
compile ('com.yifeng.example:example-2:1.0') {
exclude group: 'com.android.support', module: 'support-v4'
}

如例子中所示,远程依赖的第三方库 example-1 与 example-2 内部同时引入 support-v4 包,那么只需要在其中一个的引入地方添加 exclude 语句,根据 group 和 module 过滤规则,将相同引入的 v4 包剔除在外即可。

当需要在一个依赖中去除多个递归依赖项时,可以使用多条 exclude 语句,比如:

compile ('com.wdullaer:materialdatetimepicker:3.2.2') {
exclude group: 'com.android.support', module: 'support-v4'
exclude group: 'com.android.support', module: 'design'
}

还有一种更简单的写法,使用 Groove 语言的循环语句,模板如下(同样适用于 module 规则):

compile() { dep ->
[group1, group2].each{ group -> dep.exclude group: group }
}

对于上面的例子,便可以改造成:

compile() { dep ->
['support-v4', 'support-v13', 'design'].each{ module -> dep.exclude module: module }
}
更多细节,参考:ModuleDependency
以上两种场景算是比较好处理的。还有一种特殊情况,就是不同第三方库内部出现相同包名相同文件名的 java 类。这种情况出现的概率很低,但是不幸的是我在工作中就遇见过。
当时项目中引入的 友盟统计移动统一认证 的 SDK 出现重复引入问题,执行 Run 操作编译打包时出现 duplicate entry 错误,如图:

有关 Android Studio 重复引入包的问题和解决方案

通过错误提示,很容易就找到错误出处,我们看下两个 SDK 中的 jar 包源码:

有关 Android Studio 重复引入包的问题和解决方案

有关 Android Studio 重复引入包的问题和解决方案

虽然相同包名相同类名的文件在不同 SDK 中出现的概率极低,但是一旦出现,处理起来就比较棘手。最好的解决方案就是联系提供 SDK 的技术人员反映问题,让其通过修改源码重新打包一个新的 Jar 包。

还有一个解决办法就是,重新命名 Jar 包里的包名或者文件名。网上也有一个工具:jarjar.jar,可以帮助我们重命名包名和文件名,以及 Jar 包中的相关代码引用路径。参考地址如下:

该工具提供有多种使用方式,最简单实用的就是通过命令行使用。举个例子,打开命令行工具,执行:

java -jar jarjar-1.4.jar process rule.txt example.jar example_output.jar

其中,rule.txt 是包含重命名规则的文件,内容如下:

rule p.rn.asm.** com.yifeng.example.@

我们看一下重命名前后 Jar 包内容的代码对比图:

有关 Android Studio 重复引入包的问题和解决方案

有关 Android Studio 重复引入包的问题和解决方案

可以看到,不仅包名改变,Jar 包中的相关类引用路径也自动改变。这种 Jar 包重命名的方式虽然能解决重复引入包的问题,但不是长久之计,需要后续持续关注 SDK 的升级替换。
不同 Jar 包包含相同文件(路径也相同)的情况还有一种,就是 duplicate files 错误。多个 Jar 包包含重复的文件。这种情况在网上看到过,出自 *,错误提示类似:

Error:duplicate files during packaging of APK E:\Code\iDoc\app\build\outputs\apk\app-debug-unaligned.apk
Path in archive: META-INF/license.txt
Origin : E:\Code\iDoc\app\libs\spring-core-3.1..RELEASE.jar
Origin : E:\Code\iDoc\app\libs\spring-web-3.1..RELEASE.jar
You can ignore those files in your build.gradle:
android {
packagingOptions {
exclude 'META-INF/license.txt'
}
}

可以看到,解决方案已经在错误提示中有给出,使用 packagingOptions 配置的 exclude 语句删除重复文件即可,比如:

packagingOptions {
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/NOTICE'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/NOTICE.txt'
}

最后再补充一点,关于 Gradle 依赖的 Scope 问题。通常依赖某个第三方库我们使用的都是 compile 关键字,实际上,还有一个 Provided 关键字偶尔也会用到。

打开 Project Structure,查看 Modules 的 Dependencies 内容时,可以看到每一个依赖项的右边有个 Scope 选项:

 有关 Android Studio 重复引入包的问题和解决方案
compile 表示依赖的第三方库在工程编译阶段、测试阶段和 Apk 运行阶段都需要使用到;而 provided 表示该第三方库仅仅是在编译阶段和测试阶段使用到,不会出现在运行阶段,即表示不会打包到最终的 apk 文件中去,目标运行环境已经包含有该第三方库。(貌似 Dagger2 的使用可能会涉及到这个问题。)