我们能否构建一个依赖 v3 的 AAR，而不会有与 v2 的客户端应用程序依赖发生冲突的风险？

Question

我们想制作一个 Android 档案库 (AAR) 并分发给我们的客户。在这个 Android 库中，我们使用了一些第三方依赖项，我们希望保护它们免受任何版本冲突的影响。我们也不希望将依赖项自动更新到最新版本。

例如这个场景：我们正在使用（并且需要）版本 3 的依赖项和相同依赖项的客户端版本 2 - 由于某种原因，这些版本不兼容，我们的客户端无法更新到版本 3。或者这个：客户端还使用来自另一个提供程序的 AAR，该 AAR 反过来使用版本 2 的依赖项 - 将其更新到版本 3 会破坏其他 AAR。要求软件链的每个部分都与相同的依赖版本兼容并不总是可能的。

使用普通 JAR 时，通过使用ShadowJar在构建步骤中包含和重新定位依赖项，可以轻松避免这种情况。但是对于 AAR，我发现的最佳方法是根据以下内容创建自定义 gradle ShadowJar 任务：https : //github.com/johnrengelman/shadow/issues/183 并在编译实际 AAR 之前执行重新定位步骤。但这使得你的应用源文件需要直接导入重定位的依赖项，即：import relocated.org.com.dependency。

然而，这不是我们认为的 AAR:s 常见问题场景的最佳解决方案，如上所述。我们希望在开发阶段之后，在构建 AAR 时进行迁移步骤。我还没有找到一种令人满意的方法来做到这一点。真的没有更好的解决方案吗？

Answer 1

这与混淆所做的很接近，重新定位（或重新命名，但有点相同）并重新链接包，这样依赖关系就不会被破坏。我可能会尝试为您使用的版本 3 库正确启用混淆（排除所有其他不需要混淆的东西）。这样，您的开发就可以按原样使用版本 3，而无需处理重新定位，并且您的客户将通过重新定位获得 AAR。我很难说出如何实现这一点，因为我只在构建 APK（而不是 AAR）时使用了混淆，但我认为这是可能的。

要做的一件额外的事情就是将此构建逻辑与开发构建逻辑分开，可能类似于创建另一个 gradle 模块并使用模块依赖关系来获取开发创建的构建 AAR，然后执行在 gradle 中重新定位包的步骤AAR 和版本 3 库。