android - 解决错误: all support libraries must use the exact same version的正确方法

Question

我正在使用 Tommy Buonomo 的优秀库(here on GitHub 和 this SO question where he introduced it)向 ViewPager 添加位置指示器，但是我收到了一个 gradle 错误关于支持库版本，这对我提出了一个更大的问题。

具体错误是:

Error:(39, 20) All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes). Found versions 27.0.0, 25.3.1. Examples include 'com.android.support:support-compat:27.0.0' and 'com.android.support:animated-vector-drawable:25.3.1'

(请注意，这已被 Android Studio 标记为错误，但该应用程序仍在编译和运行。)

这引发的更大问题是您如何正确处理像这样的支持库版本中的冲突？

我只是通过添加添加了库:

compile 'com.tbuonomo.andrui:viewpagerdotsindicator:1.0.1'

我在应用程序级别 build.gradle 中的依赖项，正如我所说，除了错误之外，一切都运行良好。

我想让我的应用尽可能避免错误和警告，因此我想了解我可以做些什么来解决这个问题。

这是我第一次在我的项目中使用第三方库，所以这是我第一次遇到这个具体问题。

那么，一些问题。

1. 库开发人员是否必须针对特定的其他支持库版本创建其库的各种版本，或者他们是否可以简单地创建一个支持所有版本直至特定版本的库？ (创建特定版本似乎不切实际，因为您不知道图书馆用户将使用什么版本)。

2. 用户通常可以更改第三方库调用的其他支持库的版本吗？我似乎无法在项目树的外部库部分找到允许我为 Tommy 的库执行此操作的任何地方，所以我假设很多库都是这样的。

3. 等待库开发人员创建使用与我的应用使用的相同 API 级别支持库的新版本是唯一的选择吗？ (或者更改我的应用使用的支持库版本)。

4. 另一种选择是在 github 上 fork 库并更改它在新 fork 中使用的支持库版本吗？这就提出了学习如何编译和使用库并重新发布它们供其他人使用的问题(可能作为对原作者的拉取请求，以便他们可以合并更改 - 这最符合 Tommy 发布的精神图书馆)——并且还需要理解所有问题 1-3。

我感觉遇到了这个错误，我在这里打开了一堆蠕虫，但我想了解更多有关如何修复这个问题的信息，如果我要正确地做事的话。

(仅供引用，我正在使用编译和目标 SDK v27 构建我的应用程序，以便遵循针对最新 API 级别的最佳实践。Tommy 的库已经有一个支持 API v26 的拉取请求正在等待操作)

Answer 1

您可以强制依赖项使用特定版本的support library，尝试在您的项目级build.gradle 文件中添加:

subprojects {
    project.configurations.all {
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == 'com.android.support'
                    && !details.requested.name.contains('multidex') ) {
                details.useVersion "yourSupportLibVersion"
            }
        }
    }
}

如果您使用的支持库版本 27.0.0 将 yourSupportLibVersion 替换为 27.0.0

解释:

• 我们为什么要使用子项目？

  在多项目 gradle 构建中，您有一个根项目和子项目。根项目是构建的起点。其他所有内容，无论是作为 gradle 中的依赖项添加还是手动添加的外部库，都将由 gradle 作为子项目处理。

• 什么是 ResolutionStrategy？

  引自docs , ResolutionStrategy 定义了依赖解析的策略。例如，强制执行某些依赖项版本、替换、冲突解决或快照超时。

• 为什么要排除 multidex？

  我们之所以将 multidex 排除在我们要求的版本之外，是因为 multidex 的依赖项名称还包含 com.android.support ，即 com.android.support:multidex:someVersion 其中 someVersion 与支持库版本不同，它独立于它，这就是我们将其排除在强制支持库版本之外的原因。 注意:如果你有更多这样的依赖，你应该在上面的if条件中添加它们。

在我们确定依赖项确实是一个支持库之后，我们只是告诉 gradle 使用我们想要的版本。