新笔记本上Android多模块项目编译遇Multiple dex files定义重复错误

看起来你在新笔记本上遇到了头疼的Dex重复定义问题，虽然已经尝试了不少常规操作，但咱们可以从几个更针对性的方向排查：

1. 排查子模块的依赖重复 #

你的项目有5个子模块，很大概率是vuforia相关的库被多个模块重复引入了：

• 逐个打开子模块的build.gradle，查找是否有重复的implementation/api依赖指向edu.hawhamburg.vuforia相关库
• 在终端执行./gradlew :app:dependencies（Windows用gradlew.bat :app:dependencies），生成依赖树后搜索edu.hawhamburg.vuforia，看是否有多个来源
• 如果发现重复，建议在子模块中用compileOnly替代implementation，或者在主模块统一引入，让子模块通过依赖传递获取该库

2. 解决BuildConfig的生成冲突 #

BuildConfig是每个模块自动生成的，但如果第三方库（比如vuforia的aar）本身自带了BuildConfig类，就会和你的模块生成的同名类冲突：

• 检查是否有子模块的applicationId或packageName设置成了edu.hawhamburg.vuforia，导致生成的BuildConfig和第三方库的撞名
• 可以尝试在冲突的子模块中禁用自动生成BuildConfig：

android {
    buildFeatures {
        buildConfig = false
    }
}

注意：如果子模块需要用到BuildConfig里的变量，这个方法需要配合手动定义常量替代

3. 对齐新旧环境的Gradle配置差异 #

旧电脑能正常运行，说明环境差异是关键：

• 确认新电脑的JDK版本和旧电脑完全一致（Android项目对JDK版本敏感，尤其是Java 8及以上的版本差异）
• 检查gradle-wrapper.properties中的distributionUrl，确保和旧电脑使用相同版本的Gradle
• 核对项目根目录build.gradle里的com.android.tools.build:gradle插件版本，不同插件版本的Dex处理逻辑可能有差异

4. 更彻底的清理与重构 #

虽然你已经做过清理，但可以试试更深度的操作：

• 删除项目根目录下的.gradle文件夹（不是用户目录的Gradle缓存）
• 删除每个模块的build文件夹
• 执行./gradlew clean :app:assembleDebug，强制重新构建所有模块

5. 检查vuforia库的引入方式 #

如果vuforia是通过本地aar/jar引入的：

• 确认是否有多个模块同时添加了同一个本地库文件
• 可以把vuforia库统一放到项目根目录的libs文件夹，在主模块引入后，子模块通过依赖传递使用

如果以上方法都没解决，你可以执行./gradlew :app:transformDexArchiveWithDexMergerForDebug --info获取详细日志，看看具体是哪些dex文件包含了重复的BuildConfig类，这样能精准定位问题。

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