5

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

例如这种情况：我们正在使用（并且需要）版本 3 的依赖项和相同依赖项的客户端版本 2 - 由于某种原因，这些版本不兼容，我们的客户端无法更新到版本 3。或者这样：客户端还使用来自另一个提供程序的 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 时，我们希望在开发阶段之后进行迁移步骤。我还没有找到令人满意的方法来做到这一点。真的没有更好的解决方案吗？

4

1 回答 1

0

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

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

于 2019-12-17T09:19:03.470 回答