Android加载SO库UnsatisfiedLinkError错误的原因及解决方案

Android 应用开发者应该对 UnsatisfiedLinkError 这种类型的错误比较熟悉了，这个问题一直困扰着广大的开发者，那么有没有想过有可能你什么都没做错，也会出现这个问题呢？

我们在 Android 应用开发测试过程中曾经碰到过这样的案例，apk 在某机型上安装完成之后运行即崩溃，报错 UnsatisfiedLinkError。

java.lang.UnsatisfiedLinkError: Couldn’t load mobsec from loader dalvik.system.PathClassLoader.....findLibrary returned null

首先怀疑是在 apk 中相应的 libs\abi 目录下没有放置 libmobsec.so，然而检查发现这个 so 在所有的 libs\abi 下都有放置过，继续排查;

然后的想法是放置的 so 不是对应 abi 的，比如由于粗心在 armeabi 目录下放置了 x86 指令集的 so，导致在 armeabi 指令集手机上加载出错，这个也被排除掉;

就在没有头绪的时候，想到 System.loadLibrary 函数加载 so 时，系统是从指定的路径下加载的，那么这个路径下 so 是否存在呢?

我们知道应用的私有 Native library 目录 /data/data/packagename/lib 是一个符号链接，链接到 /data/app-lib/<package name> 目录，System.loadLibrary 是到这个目录去尝试加载 so 的。

adb shell 到这个路径下，使用命令 ls 查看，果然这个 libmobsec.so 是不存在的。那么是什么原因导致的呢？

分析 Android 系统源码的实现，发现 /data/app-lib/<package name> 这个目录下的 so ，是在系统安装 apk 时从 apk 的 lib 目录下去抽取的。

在安装 app 时，Android package manager 代码需要分析当前手机支持的指令集并拷贝相关指令集的 so。从 Android2.X 到 Android6.0 系统，由于相继加入了 x86、64位等指令集的支持，这一部分代码处理逻辑有不少变动，然而这个代码是存在逻辑缺陷的，存在遗漏拷贝的可能，导致在一些机型上并不一定保证所有的 so 都能被正确抽取到 /data/app-lib/<package name> 目录下，从而导致应用在加载 so 的时候出现 UnsatisfiedLinkError 这样的错误。

已经有开发者意识到这个 bug，比如在 Chromium 的源代码的一段注释，说明了 Android package manager 中的问题：

     * PackageManager may fail to update shared library.
                    *
                    * Native library directory in an updated package is a symbolic link
                    * to a directory in /data/app-lib/<package name>, for example:
                    * /data/data/com.android.chrome/lib -> /data/app-lib/com.android.chrome[-1].
                    * When updating the application, the PackageManager create a new directory,
                    * e.g., /data/app-lib/com.android.chrome-2, and remove the old symlink and
                    * recreate one to the new directory. However, on some devices (e.g. Sony Xperia),
                    * the symlink was updated, but fails to extract new native libraries from
                    * the new apk.

　　

“在 Android 平台上加载本地库的危险性”这篇文章中提到了作者遇到同样的问题，并基于 Chromium 给出的一种权宜的解决办法：封装 System.loadLibrary 接口为 ReLinker 接口，如果发现无法正常加载 so，则获取 apk 路径并解压相应指令集的 so，然后尝试去加载。这种方案经过验证是可以显著减少 UnsatisfiedLinkError 错误的出现，下图为作者使用了 ReLinker 接口后的日上报 UnsatisfiedLinkError 错误数的变化趋势图。

ReLinker 接口现在已经集成到网易云捕的SDK中，使用方法如下：

用

ReLinker.loadLibrary(context, “mylibrary”);

来代替

System.loadLibrary(“mylibrary”);

参考链接：
apk安装过程及原理说明：http://blog.csdn.net/hdhd588/article/details/6739281
在Android平台上加载本地库的危险性：http://www.csdn.net/article/2015-11-10/2826182-the-perils-of-loading-native-libraries-on-android

更多资讯文章，可关注微博公众号：网易云捕

时间： 2024-10-21 22:34:58

Android加载SO库UnsatisfiedLinkError错误的原因及解决方案的相关文章

LoadLibrary加载动态库失败

LoadLibrary加载动态库失败的可能原因以及解决方案: (1)dll动态库文件路径不对.此场景细分为以下几种情况: 1.1 文件路径的确错误.比如:本来欲加载的是A文件夹下的动态库a.dll,但是经过仔细排查原因,发现a.dll动态库竟然被拷贝到B文件夹下去了. 若真遇到这种低级错误,建议你找个没人的墙角蹲下用小拇指逆时针划圈圈去吧... 1.2 实参传值错误.比如:实参类型为LPCWTR,经常都会因为字符串转换导致实参事与愿违. 网上的经验总结实例.某程序员经过一番周折后通过以下语句调用

【转载】cocos2dx 中 Android NDK 加载动态库的问题

原文地址:http://blog.csdn.net/sozell/article/details/10551309 cocos2dx 中 Android NDK 加载动态库的问题 闲聊 最近在接入各个平台的SDK,遇到了不少问题,也从中了解了不少知识,之前一直觉得没啥好写的,毕竟做了4个月的游戏开发,也没有碰上什么真正的大问题,cocos2dx的引擎包得也很好,能让人把大部分时间都关注在游戏逻辑.效果的处理上,当然,之前的libevent还是小坑一下,但是和后来遇到的相比,也算不上什么了. 我最

Android-Universal-Image-Loader （图片异步加载缓存库）对Bitmap的优化处理

转载请注明出处:http://blog.csdn.net/u011733020 前言: 前面两篇分别介绍了: Android-Universal-Image-Loader (图片异步加载缓存库)的使用配置 Android-Universal-Image-Loader (图片异步加载缓存库)的源码解读 通过前两篇,我们了解了 UIL的使用配置,UIL将服务器上的一张图片保存到本地,加载到内存的过程,以及UIL对DiscCache和MemoryCache的策略,但是还有一部分比较重要,因为它是我们的

Linux下c函数dlopen实现加载动态库so文件代码举例

dlopen()是一个强大的库函数.该函数将打开一个新库,并把它装入内存.该函数主要用来加载库中的符号,这些符号在编译的时候是不知道的.这种机制使得在系统中添加或者删除一个模块时,都不需要重新编译了.可以在自己的程序中使用 dlopen().dlopen() 在 dlfcn.h 中定义,并在 dl 库中实现.它需要两个参数:一个文件名和一个标志.文件名就是一个动态库so文件,标志指明是否立刻计算库的依赖性.如果设置为 RTLD_NOW 的话,则立刻计算:如果设置的是 RTLD_LAZY,则在需要

Xilinx SDDoc 加载opencv库

Xilinx SDSoc 加载opencv库需要下载两个文件 xfopencv 和 Revision Platform 1.xfopencv : github地址 https://github.com/Xilinx/xfopencv 2.revision platform : https://www.xilinx.com/member/forms/download/design-license-xef.html?akdm=1&filename=zcu102-rv-ss-2017-4.zip p

有效解决Android加载大图片时内存溢出的问题

首先解析一下基本的知识: 位图模式,bitmap颜色位数是1位 灰度模式,bitmap颜色位数是8位,和256色一样 RGB模式,bitmap颜色位数是24位 在RGB模式下,一个像素对应的是红.绿.蓝三个字节 CMYK模式,bitmap颜色位数是32位  在CMYK模式下,一个像素对应的是青.品.黄.黑四个字节 图像文件的字节数(Byte) = 图像分辨率*颜色深度/8(bit/8) 例如:一幅640*480图像分辨率.RGB色一般为24位真彩色,图像未经压缩的数据容量为:640X480X24

记：Ubuntu14.04 Android加载项目失败

Android 加载项目失败: sdk/build-tools/android-4.4.2/aapt: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory 安装: sudo apt-get install lib32z1 记:Ubuntu14.04 Android加载项目失败,布布扣,bubuko.com

Android加载大图片到内存

加载大图片到内存 步骤: 步骤一: 获取品屏幕的宽高数据;[HD1] 步骤二: 获取图片的宽高;[HD2] 步骤三: 计算屏幕与图片的宽高比例,按照差距最大的进行缩放处理;[HD3] 步骤四: 图片的缩放处理;[HD4] [HD1]// 获取手机的屏幕的窗体大小 WindowManager windowManager = (WindowManager) getSystemService(WINDOW_SERVICE); Display display = windowManager.getDef

Android -- 加载大图片的方法

在android中要加载一张大图片到内存中如果通过如下方式进行: Bitmap bitmap= BitmapFactory.decodeFile("/sdcard/a.jpg"); iv.setImageBitmap(bitmap); 则会抛出内存溢出异常Caused by: java.lang.OutOfMemoryError 正确的做法应该是这样的: public class MainActivity extends Activity { private ImageView iv;