Android编译报错：lib/x86/libcrypto.so路径文件重复，添加packagingOptions仍未解决

嘿，我之前也踩过一模一样的坑！你已经配置了pickFirst但还是报错，大概率是多个依赖库（甚至是你自己的模块）都在引入同名的.so文件，而且当前的配置可能没覆盖到所有冲突场景，或者Gradle缓存在搞怪。下面是几个能帮你解决问题的实用步骤：

1. 先定位到底是谁在重复引入.so文件 #

首先得搞清楚哪些依赖包带了重复的libcrypto.so和libssl.so。在终端运行Gradle命令查看完整依赖树：

./gradlew app:dependencies --configuration debugRuntimeClasspath

搜索libcrypto或者相关的openssl关键词，你会发现至少有两个不同的依赖在引入这些so文件（比如可能是OkHttp、某个第三方SDK，甚至是你手动引入的openssl库）。

2. 排除多余的依赖（推荐优先尝试） #

找到重复的依赖后，直接在gradle里排除其中一个的重复so。比如你发现com.example:problem-sdk:1.0和主依赖都带了libcrypto，就给这个SDK加exclude：

implementation('com.example:problem-sdk:1.0') {
    // 替换成实际的openssl相关分组和模块，比如org.openssl:openssl
    exclude group: 'org.openssl', module: 'openssl'
}

这种方式从根源上解决重复问题，比pickFirst更稳妥，能避免后续运行时可能出现的so版本冲突。

3. 调整packagingOptions的覆盖范围 #

如果找不到明确的重复依赖，或者排除后还是有问题，试试把pickFirst的路径改成通配符，覆盖所有可能的目录：

packagingOptions {
    pickFirst '**/libcrypto.so'
    pickFirst '**/libssl.so'
}

这样不管so文件在哪个架构目录下，Gradle都会只保留第一个找到的版本，能覆盖你之前可能没写到的非标准路径。

4. 检查自己模块的jniLibs目录 #

别忘了看看你自己的app模块下src/main/jniLibs里有没有这些so文件！如果有，很可能是你自己的so和依赖库的so重复了——要么删掉自己的，要么调整pickFirst的优先级确保保留正确的版本。

5. 清理Gradle缓存 #

有时候Gradle的缓存会残留旧的依赖文件，导致配置不生效。运行命令清理缓存后再重新编译：

./gradlew clean
./gradlew assembleDebug

最后提醒一句：用pickFirst的时候要尽量确保所有依赖用的是同一个版本的openssl，否则虽然编译过了，运行时可能会出现奇怪的兼容性问题哦！

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