生产构建中libbetter.so在部分Android设备引发致命异常的排查求助

异常信息 #

Fatal Exception: could not delete: /data/user/0/com.package_name/lib-0/libbetter.so on production build
Fatal Exception: java.lang.RuntimeException: Unable to create application com.packageName.MainApplication: java.lang.RuntimeException: java.io.IOException: could not delete: /data/user/0/com.packageName/lib-0/libbetter.so

问题详情 #

生产构建版本出现该崩溃，已通过Firebase捕获，但本地无法复现。受影响设备：

• Galaxy Note20 Ultra 5G（Android 13）
• OnePlus 9 5G（Android 12）

环境版本 #

• react: "18.2.0"
• react-native: "0.71.7"

排查思路与解决方案 #

1. 定位libbetter.so的来源 #

先搞清楚这个so文件是哪个依赖引入的——可以通过查看android/app/build.gradle的依赖列表，或者执行./gradlew app:dependencies命令分析依赖树。找到对应的RN插件或原生库后，检查其版本是否存在已知的so文件处理bug，尝试升级该依赖到最新稳定版。

2. 适配Android 12/13的文件权限与进程占用 #

Android 12+对应用私有目录的文件操作有更严格的限制，且如果so文件被当前进程或其他进程占用，会导致删除失败：

• 检查应用启动时的so加载逻辑，确保在尝试删除libbetter.so前，该库已完成相关操作（so加载后通常无法卸载，可能需要调整删除时机）；
• 在抛出异常的代码位置添加IOException捕获，不要直接让异常导致应用崩溃，而是做降级处理（比如跳过删除、标记文件后续清理）。

3. 检查RN打包构建配置 #

• 查看android/app/build.gradle中的ABI拆分配置（splits.abi），如果开启了ABI拆分，确认so文件的复制、清理逻辑是否正确；
• 检查混淆（minifyEnabled）和资源压缩设置，是否因混淆导致so文件的路径或引用出现异常；
• 排查是否有自定义Gradle脚本在处理so文件，比如复制到指定目录后未正确处理旧文件的删除逻辑。

4. 绕过不必要的删除操作 #

如果libbetter.so的删除是某个依赖的冗余操作（比如更新时的旧文件清理，但实际不影响运行），可以修改对应代码：

• 找到抛出异常的原生代码位置（通常在MainApplication初始化逻辑里），添加异常捕获；
• 如果是RN插件导致的，可fork插件源码，修改删除逻辑后本地引入。

5. 模拟生产环境复现问题 #

虽然本地无法直接复现，但可以尝试：

• 打release包安装到Android 12/13的测试设备上，用adb shell chmod命令手动将libbetter.so设置为只读，重启应用看是否触发崩溃；
• 通过adb命令模拟文件被占用的情况，比如用另一个进程打开该so文件，再启动应用。

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