Android打包遇libc++_shared.so重复：如何确定选中版本及修复？

React Native 0.67.0对应的libc++_shared.so版本 #

React Native 0.67.0基于NDK 23.x版本构建，它携带的libc++_shared.so是NDK 23版的C++标准库实现，这个版本和RN 0.67的底层JNI调用逻辑完全适配，稳定性有保障。

pickFirst的选择逻辑 #

当你配置packagingOptions { pickFirst 'lib/*/libc++_shared.so' }时，Gradle会按照依赖树的遍历顺序选取第一个遇到的文件。通常情况下，build.gradle里声明靠前的依赖会被优先选中，但这个顺序可能因依赖传递、模块引入顺序变化而改变，稳定性较差，不建议作为长期解决方案。

靠谱的修复方案 #

1. 统一NDK版本（首推） #

如果jetified-base-7.5.8支持的话，强制整个项目使用和RN 0.67匹配的NDK 23.x版本：

• 在项目根目录的build.gradle中添加：

  android {
      ndkVersion "23.1.7779620"
  }
  

  或者在gradle.properties里追加一行：

  android.ndkVersion=23.1.7779620
  

• 清理缓存并重新构建项目：

  ./gradlew clean
  ./gradlew assembleRelease
  

这样所有模块都会生成适配NDK 23的libc++_shared.so，从根源上消除冲突。

2. 排除冲突库的so文件 #

如果jetified-base-7.5.8的核心功能不依赖libc++_shared.so，可以在依赖声明中直接排除该文件：

implementation('com.yourgroup:jetified-base:7.5.8') {
    exclude fileTree(dir: 'lib', includes: ['**/libc++_shared.so'])
}

注意：使用该方案前务必测试jetified-base的全部功能，避免排除后出现运行时崩溃。

3. 用pickFirst并锁定依赖顺序（临时过渡） #

如果前两种方案不可行，只能依赖pickFirst的话，调整依赖声明顺序，将RN的依赖放在最前面：

// 先声明RN依赖，确保它的so被优先选中
implementation 'com.facebook.react:react-native:0.67.0'
// 再声明jetified-base依赖
implementation 'com.yourgroup:jetified-base:7.5.8'

同时保留packagingOptions配置：

packagingOptions {
    pickFirst 'lib/*/libc++_shared.so'
}

这种方式大概率能选中RN的so文件，但依赖顺序变化时可能出问题，仅作为临时过渡方案使用。

验证修复有效性 #

• 解压打包后的APK，查看lib/arm64-v8a/目录下的libc++_shared.so，可以用readelf工具查看版本信息，或对比RN库中对应文件的哈希值，确认是RN的版本。
• 在真机上测试核心功能，尤其是涉及JNI调用、C++逻辑的部分，确保无崩溃或异常。

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