Gradle构建突发报错：Program type already present: com.google.android.gms.internal.measurement.zzabn

我之前也碰到过这种毫无预兆的Gradle构建故障——明明前一天还好好的，突然就卡在Multidex相关任务上了。结合你已经排查过Firebase版本、试过常规方案的情况，分享几个针对性的排查方向：

• 彻底清理构建缓存，刷新依赖
  缓存损坏是这类突发问题的常见元凶，先执行这几条命令清空缓存并重新拉取依赖：

  ./gradlew clean
  ./gradlew :app:cleanBuildCache
  ./gradlew build --refresh-dependencies
  

  跑完之后再试构建，大概率能解决缓存导致的异常。

• 核对Multidex配置是否被意外修改
  哪怕你没手动改配置，依赖更新或者代码提交可能间接影响了Multidex的配置：

  1. 打开app/build.gradle，确认defaultConfig里的multiDexEnabled true还在正确位置
  2. 如果你自定义了MultidexApplication类，检查是否有代码变更导致类加载异常
  3. 查看混淆规则文件，有没有误加阻止Multidex扫描必要类的规则

• 排查Multidex相关依赖的版本冲突
  就算Firebase是最新版，也可能和其他依赖存在隐性冲突。先看依赖树找问题：

  ./gradlew :app:dependencies
  

  重点看multidex相关依赖的版本是否统一，如果有多个版本，在app/build.gradle里强制统一：

  configurations.all {
      // 如果你用AndroidX，替换成androidx.multidex:multidex:2.0.1
      resolutionStrategy.force 'com.android.support:multidex:1.0.3'
  }
  

• 检查是否新增了超量依赖导致方法数超限
  突然加入的大依赖可能让方法数突破65536的阈值，触发Multidex任务异常。可以用这条命令统计方法数：

  ./gradlew :app:countDebugMethods
  

  如果接近或超过阈值，除了确保Multidex配置正确，还可以考虑移除无用依赖，或者开启R8优化压缩方法数。

• 获取详细栈定位具体问题
  你现在只看到任务失败的提示，加上--stacktrace参数跑构建，能拿到完整错误日志：

  ./gradlew :app:transformClassesWithMultidexlistForDebug --stacktrace
  

  日志里会明确指出是哪个类扫描失败、哪个依赖出问题，这才是精准定位根源的关键。

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