Android加载libpolarssl.so遇UnsatisfiedLinkError问题排查

崩溃信息 #

Fatal Exception: java.lang.UnsatisfiedLinkError: dlopen failed:
/data/user/0/com.gbox.android/_root/data/internal_app/com.company.android-gep493u9x7yrZ9yoy5Lqtw==/lib/arm/libpolarssl.so" is 32-bit instead of 64-bit

核心原因 #

lib/arm是早期Android armeabi ABI的路径别名，系统处理ABI兼容时会做映射。你的应用出现这个问题，本质是运行环境错误地将目标ABI识别为arm（而非官方支持的armeabi-v7a/arm64-v8a等），触发了旧路径的查找逻辑。

可能的触发条件 #

• 虚拟容器的环境篡改：你使用的com.gbox.android属于虚拟容器类应用（如双开工具），这类应用可能修改应用运行沙箱环境，错误地将64位设备的ABI识别为arm，迫使系统去lib/arm路径加载库。
• 代码中的硬编码路径：检查Java或JNI代码，是否存在硬编码指定arm路径加载库的情况——比如手动调用System.load("/path/to/lib/arm/libpolarssl.so")，或者JNI层拼接路径时错误使用arm作为ABI名称。
• 打包配置的隐性问题：虽然你确认Native库适配了官方ABI，但检查build.gradle的ndk.abiFilters是否真的只包含armeabi-v7a, arm64-v8a, x86, x86_64；另外，第三方打包插件可能修改ABI规则，导致AAB中存在隐性的armeabi依赖，触发系统的兼容查找。
• ABI回退机制异常：64位设备找不到对应64位库时，会尝试回退加载32位库，但如果容器或系统的回退逻辑出错，会错误地将回退路径指向lib/arm而非标准的lib/armeabi-v7a。
• 第三方库的隐性依赖：排查项目依赖的第三方库，是否有某个库内部依赖了armeabi ABI版本，导致打包时引入未预期的ABI需求，触发系统查找lib/arm路径。

排查方向 #

1. 检查com.gbox.android的设置，是否有强制32位运行、模拟旧ABI的选项，关闭后重试。
2. 核对build.gradle的ABI配置，确保ndk.abiFilters仅包含官方支持的ABI，同时检查android.bundle.enableUncompressedNativeLibs等打包参数是否正常。
3. 解压AAB文件，直接查看内部lib目录结构，确认没有armeabi相关的残留文件或配置。
4. 在代码中添加日志，打印Build.CPU_ABI和Build.CPU_ABI2的值，确认当前运行环境识别的ABI是否正确。

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