原文地址:https://blog.mindorks.com/avoiding-conflicts-in-android-gradle-dependencies-28e4200ca235#.c49sh2v55
Gradle让Android开发变得更简单,只需要在build.gradle中添加一行依赖，然后所需的库就无缝的包含项目中，但是当两个依赖关系依赖于同一个库的不同版本时会发生什么？请考虑以下示例：
androidTestCompile 'junit:junit:4.12' //(Depends on version 1.3)
androidTestCompile 'org.mockito:mockito-core:1.10.19' //(Depends on version 1.1)
如果两个依赖在内部使用同一个库的不同版本，那么哪个版本会包含在构建中呢？答案是，最高版本会包含在构建中，在声明依赖的模块中运行以下命令：
./gradlew dependencies
上面的命令的输出在下面给出，清楚地表明gradle在最终构建中将hamcrest库版本从1.1自动升级到1.3。
依赖冲突错误
上面的两个依赖都是测试依赖，所以gradle能够自动解决冲突，但是如果两个依赖属于不同的配置，即app和test，那么gradle会抛出一个错误。
考虑一下下面的代码片段：
compile 'junit:junit:4.12' //denpends on version 1.3
androidTestCompile 'org.mockito:mockito-core:1.10.19' //denpends on version 1.1
现在第一个依赖属于app配置，第二个依赖属于测试配置，当我们构建项目的时候，会出现如下的异常：
异常
根据Android gradle的官方文档，以上的错误原因如下：
当运行测试时，主APK和测试APK共享相同的classpath，如果主APK和测试APK使用相同的库，但是在不同的版本时，Gradle将构建失败，如果gradle没有捕捉到，你的app在测试和正常云期间会表现不同的行为。
解决依赖冲突
一旦在构建中存在依赖冲突，开发人员需要决定哪个版本的库最终包含在构建中，有许多解决冲突的方法。
- 从依赖项中排除冲突的模块/库，当生命一个依赖，我们可以指定我们不需要的模块，例如，在我们的例子中，如果我们不想要最新版本1.3，而是想要版本1.1的hamcrest库，那么我们可以在声明“junit”依赖时排除该模块。
compile('junit:junit:4.12'){
exclude group : 'org.hamcrest',module:'hamcrest-core'
}
```
最终，如果我们向包含1.3版本到构建中，我们可以从“mockito"中排除他
```
androidTestCompile('org.mockito:mockito-core:1.10.19'){
exclude group : 'org.hamcrest',module:'hamcrest-core'
}
```
> 在真实项目中会有很多依赖项，他们会存在相同库的冲突版本，对于每个依赖，我们都需要有exclude标记。
- 在build.gradle中显示定义冲突的库，这是解决冲突的一种方式，在这种情况下，我们需要明确提出我们想要包含在任何一个配置的最终构建中的库的版本。
```
compile 'junit:junit:4.12'
androidTestCompile 'org.mockito:mockito-core:1.10.19'
androidTestCompile 'org.hamcrest:hamcrest-core:1.3'
```
如果多个依赖具有冲突版本的依赖或传递依赖的话，则不是从每个依赖性中排除模块，而是可以简单的使用期望的版本号来定义冲突依赖。
> 这种是一种更清洁的解决冲突的方法，但缺点是，当更新实际的依赖关系的时候，开发人员需要更新冲突的库。
### 强制库的解析
这是解决冲突的另一种方式，不是声明一个配置，而是强制他用于所有配置。
```
android{
configurations.all{
resolutionStrategy.force 'org.hamcrest:hamcrest-core:1.1'
}
}
```