本文介绍在 android/java 项目中，当第三方依赖（如 aar/jar）因特定类（如多进程场景下崩溃的类）引发冲突时，如何通过 gradle 原生机制安全地排除原始文件并注入修复版本，避免 dex 合并错误，无需手动解包重打包。
在 Android 开发中，遇到第三方库（如某 AAR）因内部某个类（例如 CrashProneHelper.class）在多进程环境下不可靠而频繁崩溃，且该类又与其他模块同名（导致 Duplicate class 或 Multiple dex files define 错误），此时简单地“覆盖源码”或“修改依赖路径”往往无效——因为 Gradle 默认会将所有依赖的字节码合并进最终 APK 的 DEX 中，重复类定义会直接导致构建失败。
虽然 ResolutionStrategy 仅作用于依赖版本解析、DuplicatesStrategy 仅控制资源/资产（assets）层级的冲突策略，二者均无法干预 JAR/AAR 内部的 class 文件粒度，但 Gradle 提供了一种更优雅、声明式且可复现的解决方案：依赖约束（Dependency Constraints） + 本地定制化构件（Custom Artifact）。
✅ 推荐方案：用约束强制使用修复版，配合本地发布
修复并重新打包依赖
首先，从原始 AAR/JAR 中解压，定位并替换问题类（如反编译 → 修改 → 重编译 → 重新打包为 fixed-lib-1.2.3.aar），确保其 package、class name 和 signature 完全兼容原版。-
发布到可控仓库
将修复版发布至：- mavenLocal（开发调试快）：
./gradlew publishToMavenLocal
- 私有 Nexus/Artifactory（团队协作必需）
- 或项目级 libs/ 目录（需配置 flatDir，不推荐用于 CI）
- mavenLocal（开发调试快）：
-
在 build.gradle 中声明约束
在根项目的 settings.gradle 或模块的 build.gradle 中，使用 constraints 强制所有传递依赖使用你的修复版本：dependencies { // 声明原始依赖（仍保留，便于语义识别） implementation 'com.example:problematic-lib:1.2.0' // 添加约束：任何 transitive 或 direct 引用该 group:name 的依赖，必须使用 1.2.3-fixed constraints { implementation('com.example:problematic-lib') { version { strictly '1.2.3-fixed' } because 'Fixes multi-process crash in CrashProneHelper' } } } 验证生效
运行 ./gradlew app:dependencies --configuration releaseRuntimeClasspath，确认 problematic-lib 所有出现位置均已解析为 1.2.3-fixed；同时检查 APK 解压后的 classes.dex，确认旧类已消失、新类正确存在。
⚠️ 注意事项与替代思路
- 不要使用 exclude 按类名过滤：exclude group: 'x', module: 'y' 仅支持 module 级别，无法按 .class 文件排除。
- 避免 packagingOptions { pickFirst }：它仅解决资源冲突（如 AndroidManifest.xml），对 classes.dex 中的类无效。
- 慎用 transformClassesWith... 自定义 Transform（AGP Android Gradle Plugin 的 Variant API。
- 终极兜底方案：若约束不可行（如闭源 SDK 无法重打包），可考虑 jetifier 风格的字节码插桩（如 ASM/Byte Buddy），但应作为最后手段。
通过依赖约束机制，你不仅解决了文件级替换问题，还实现了版本可审计、构建可复现、CI 友好——这才是现代 Gradle 工程化的正确实践。
