packagingOptions exclude仅在资源合并阶段生效，不处理类重复、依赖解析或编译期classpath；它只解决so库路径冲突（如lib/arm64-v8a/xxx.so）和META-INF文件重复，对Duplicate class等错误无效。
packagingOptions exclude 为什么经常失效
不是写法错了，而是 exclude 只在资源合并阶段生效，它不处理类重复、不干预依赖解析、也不影响编译期 classpath。如果你看到的是 Duplicate class 或 More than one file was found with OS independent path，那大概率不是 packagingOptions 能解决的问题——它只管打包时的文件路径冲突，比如 lib/arm64-v8a/xxx.so 或 META-INF/MANIFEST.MF。
常见误用场景：
- 对
classes.jar里的同名 class 写exclude 'com/example/Utils.class'→ 无效，packagingOptions不处理 class 文件路径 - 在
implementation块里用exclude group: 'x'，却期望它也过滤掉 AAR 里自带的 so 文件 → 两者机制完全隔离 - 排除了
META-INF/DEPENDENCIES，但没同步排除META-INF/LICENSE和META-INF/license.txt→ Gradle 会继续报另一条冲突
so 库冲突必须用 pickFirst 而不是 exclude
当错误日志明确出现 2 files found with path 'lib/arm64-v8a/libxxx.so'，说明多个依赖提供了相同 ABI 下的同名原生库。此时用 exclude 直接删掉一个，极可能引发运行时 UnsatisfiedLinkError——因为被删的 so 可能是某个 SDK 运行必需的，只是名字撞了。
更安全的做法是保留第一个遇到的，忽略后续重复：
android {
packagingOptions {
pickFirst 'lib/arm64-v8a/libwechat.so'
pickFirst 'lib/armeabi-v7a/libwechat.so'
pickFirst 'lib/x86_64/libffmpeg.so'
}
}
注意点：
-
pickFirst按 Gradle 解析依赖的顺序生效，顺序由implementation声明顺序和依赖树深度共同决定 - 不要对整个目录写
pickFirst 'lib/**'，这会破坏 ABI 分离逻辑，导致 arm64 设备加载到 x86 库 - 如果两个 so 实际版本差异大（如 v1.2 vs v3.0），
pickFirst不能保证功能兼容，得回退到协调 SDK 版本
META-INF 冲突要批量排除而非单个文件
第三方 SDK 常把 META-INF/ 下的证书、许可证、签名文件一并打进 AAR，不同 SDK 的 META-INF/NOTICE 或 META-INF/license 容易重复。逐个 exclude 效率低且容易漏。
推荐写法：
android {
packagingOptions {
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/license.txt'
exclude 'META-INF/LICENSE-notice'
exclude 'META-INF/LICENSE-notice.txt'
exclude 'META-INF/MANIFEST.MF'
exclude 'META-INF/*.SF'
exclude 'META-INF/*.DSA'
exclude 'META-INF/*.RSA'
}
}
关键细节：
-
*.SF、*.DSA、*.RSA是 JAR 签名文件，Android 构建时若检测到多个会直接失败 - 排除
MANIFEST.MF一般不影响运行，但某些旧版插件（如部分加固工具）会读取其中的Implementation-Version字段 - 如果项目用了 Java 9+ 的模块化特性，
module-info.class也在META-INF/下，排除时需确认是否真不需要
本地 JAR 的重复资源根本不在 packagingOptions 管辖范围
用 implementation files('libs/xxx.jar') 引入的本地 JAR，Gradle 不解析其 MANIFEST.MF，也不把它纳入依赖图谱——这意味着 packagingOptions 对它完全不可见。你看到的重复，其实是这个 JAR 自身解压后和其他资源撞了路径。
可行方案只有两个：
- 改用
flatDir+ 坐标声明，让 Gradle 把它当正规依赖管理：repositories { flatDir { dirs 'libs' } } implementation(name: 'xxx', ext: 'jar') { exclude group: 'org.slf4j' } - 提前手动剥离 JAR 内部冲突内容（如删掉里面自带的
logback.xml或lib/目录），再重新签名（否则 Android 启动时校验失败）
最常被忽略的一点：这类 JAR 往往还偷偷带了 resources/ 下的配置文件或字体，它们和 src/main/assets/ 下同名文件也会触发 OS independent path 冲突——而这种冲突，packagingOptions 同样无能为力。
