虽然相同包名相同类名的文件在不同 SDK 中出现的概率极低，但是一旦出现，处理起来就比较棘手。最好的解决方案就是联系提供 SDK 的技术人员反映问题，让其通过修改源码重新打包一个新的 Jar 包。
还有一个解决办法就是，重新命名 Jar 包里的包名或者文件名。网上也有一个工具：jarjar.jar，可以帮助我们重命名包名和文件名，以及 Jar 包中的相关代码引用路径。参考地址如下：
- GitHub 源码：https://github.com/shevek/jarjar
- Jar 文件下载：https://code.google.com/archive/p/jarjar/downloads
该工具提供有多种使用方式，最简单实用的就是通过命令行使用。举个例子，打开命令行工具，执行：
作者：唠嗑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 }
}
以上两种场景算是比较好处理的。还有一种特殊情况，就是不同第三方库内部出现相同包名相同文件名的 java 类。这种情况出现的概率很低，但是不幸的是我在工作中就遇见过。
当时项目中引入的 友盟统计 和 移动统一认证 的 SDK 出现重复引入问题，执行 Run 操作编译打包时出现 duplicate entry 错误，如图：
通过错误提示，很容易就找到错误出处，我们看下两个 SDK 中的 jar 包源码：
虽然相同包名相同类名的文件在不同 SDK 中出现的概率极低，但是一旦出现，处理起来就比较棘手。最好的解决方案就是联系提供 SDK 的技术人员反映问题，让其通过修改源码重新打包一个新的 Jar 包。
还有一个解决办法就是，重新命名 Jar 包里的包名或者文件名。网上也有一个工具：jarjar.jar，可以帮助我们重命名包名和文件名，以及 Jar 包中的相关代码引用路径。参考地址如下：
- GitHub 源码：https://github.com/shevek/jarjar
- Jar 文件下载：https://code.google.com/archive/p/jarjar/downloads
该工具提供有多种使用方式，最简单实用的就是通过命令行使用。举个例子，打开命令行工具，执行：
java -jar jarjar-1.4.jar process rule.txt example.jar example_output.jar
其中，rule.txt 是包含重命名规则的文件，内容如下：
rule p.rn.asm.** com.yifeng.example.@1
我们看一下重命名前后 Jar 包内容的代码对比图：
可以看到，不仅包名改变，Jar 包中的相关类引用路径也自动改变。这种 Jar 包重命名的方式虽然能解决重复引入包的问题，但不是长久之计，需要后续持续关注 SDK 的升级替换。
不同 Jar 包包含相同文件（路径也相同）的情况还有一种，就是 duplicate files 错误。多个 Jar 包包含重复的文件。这种情况在网上看到过，出自 StackOverFlow，错误提示类似：
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 1: E:\Code\iDoc\app\libs\spring-core-3.1.0.RELEASE.jar Origin 2: E:\Code\iDoc\app\libs\spring-web-3.1.0.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 选项：
