Android Studio用NDK构建时出现libmxecg.so重复冲突报错

这个构建报错是Android Gradle插件（AGP）的预编译SO打包逻辑冲突触发的：

• 你当前模块通过两条独立路径引入了同一份libmxecg.so：
  • 手动配置jniLibs.srcDirs，将libs/libmxecg/lib目录下的SO纳入打包范围
  • 模块关联的CMake构建脚本中，通过IMPORTED目标引入了物理路径完全相同的这份SO
• 从AGP 4.0版本开始，构建系统会自动识别CMake中导入的预编译依赖，直接将其纳入APK/AAR的打包流程。两种引入方式最终输出的SO在安装包内的存储路径完全重合，就会触发“同操作系统无关路径下检测到多个同名文件”的构建阻断。
• 新增第二个CMake模块后才触发报错，是因为新模块的CMake脚本同样引入了这份公共的libmxecg.so，和原有模块的jniLibs手动配置产生了路径重叠。

按项目实际需求选择适配方案即可：

• 方案1（推荐，无额外维护成本）：删除冗余的jniLibs配置
  既然已经通过CMake IMPORTED方式引入libmxecg.so，AGP会自动完成对应SO的全ABI打包流程，完全不需要额外将SO所在目录加入jniLibs扫描范围。直接移除模块Gradle中的这段配置即可：

  sourceSets {
      main {
          // let gradle pack the shared library into apk
          jniLibs.srcDirs = ['libs/libmxecg/lib']
      }
  }
  

• 方案2（需保留手动jniLibs扫描时使用）：配置打包冲突解决规则
  如果有特殊业务需求必须保留jniLibs的手动扫描配置，可在模块的android{}代码块下新增packaging规则，指定冲突路径下的SO优先使用手动引入的版本：

  android {
      // 原有编译配置保持不变
      packagingOptions {
          // 按项目实际覆盖的ABI列表补充对应规则
          pickFirst 'lib/armeabi-v7a/libmxecg.so'
          pickFirst 'lib/arm64-v8a/libmxecg.so'
      }
  }
  

• 长期维护注意点
  高版本AGP已完全不支持同一份SO同时通过jniLibs和CMake IMPORTED两种方式重复引入，这种交叉配置没有兼容豁免空间。后续接入公共SO依赖时，统一选择单一路径引入（要么全走jniLibs手动配置，要么全走CMake IMPORTED），即可从根源避免这类打包冲突。

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