Gradle是否仍无法解决本地AAR与远程仓库的依赖冲突？

你提到的2012年的说法在当前Gradle版本（7.x及以上）中已不完全成立，但本地目录拉取的AAR/JAR仍存在特殊的依赖解析行为

核心逻辑说明 #

• Gradle的自动依赖冲突处理，本质依赖于模块元数据（如Maven的pom.xml、Gradle的module.json）。当依赖来自本地/远程仓库时，这些元数据会被用来识别依赖的版本、传递依赖关系，进而执行冲突解决策略（比如默认的最新版本优先）。
• 对于直接从本地目录引入的AAR/JAR：
  • 若通过implementation files('libs/fat-aar.aar')这类方式引入，Gradle无法获取该文件的模块元数据，不会将其视为“模块依赖”，自然不会对其中包含的重复类做自动去重或冲突处理。此时如果应用同时直接依赖library A，就会出现Duplicate class或Duplicate entry错误——因为fat-aar中的类和直接依赖的library A类会被同时打包，无去重逻辑。
  • 但如果把本地目录配置为本地仓库（比如启用mavenLocal()或自定义本地Maven仓库路径），并通过坐标方式（如implementation 'com.example:fat-aar:1.0'）引入（前提是已将fat-aar发布到本地仓库并生成元数据文件），Gradle就能读取到元数据，此时冲突处理机制会正常生效，按照常规规则处理重复的library A依赖。

总结 #

当前Gradle对本地文件依赖的处理逻辑核心未变：只有当依赖被识别为带元数据的“模块”时，才会触发自动冲突解决；直接文件引用（files()方式）只是将文件内容加入编译路径，无模块身份，因此不会处理重复类问题。

内容的提问来源于stack exchange，提问作者longv