共享代码/同一库的不同版本导致Java/Android命名空间冲突

在我的日常工作中，我开发了Android库（我们称之为libA和libB）。在某种程度上，我们意识到它们之间有很多共享代码，因此我们将这些代码移动到另一个文件夹，并使用sourceset指令引用它

当我们构建一个项目时，我们开始得到“错误：程序类型已经存在”，这让我认为Android编译器变得更智能了，或者项目结构的改变（我们合并了项目）使重复可见。在任何情况下，这个问题仍然是间歇性的，但它可能总是一个坏主意。谷歌不得不就这个问题发表意见

我正在考虑的解决方案是将共享代码移动到一个单独的模块。这样，每个类只编译一次。我做了一个简单的项目来测试这个架构

由此产生的项目将具有以下模块：

• 演示应用程序（lib*或所有人共享的应用程序）
• 利巴
• libB
• 共享数据库

这引发了以下问题：

• 这是正确的方法吗？我意识到这可能是一种基于观点的观点，但这是一个边缘案例，我无法在关于名称空间冲突的更一般问题的海洋中找到任何关于它的讨论
• 我们如何分发共享代码？理想情况下，我希望以某种方式将其捆绑到库的aar*中。（目前，lib*aar不包括共享代码）否则，我只分发两个aar文件
• java/android编译器如何处理此问题？假设我尝试使用相同的包/类编译两个库，我假设它将发出上述错误，或者只选择一个并尝试编译
• 流行的库如何处理这个问题？我可以很容易地看到okHTTP被捆绑到几个第三方库和主应用程序中。我特别想问的是API破坏版本和非API破坏版本之间的差异
• 为了完整性起见，我知道DEX没有用于多个同名类的选项。我假设在java编译过程中，这一切都被整理好了。IIRC，我做了检查，DEX creation有一个linter/验证器来检查这个。清除此链接并参考相关链接的额外点

注意事项：

• 这不是C/C++之类的问题，因为您可以选择使用静态库并复制代码
• 一些关于名称空间一致性的S/O问题实际上是关于变量阴影（例如）
• 向我证明了我在这个问题上的直觉是正确的。不同的JAR可能会导致此问题，但编译会检测到它
• 尤其是一个由Commonware提供的答案暗示了一个更大的讨论