Reasons and solutions for Android loading so library unsatisfiedlinkerror errors

Android app developers should be familiar with Unsatisfiedlinkerror this type of error, this problem has been plagued by the vast number of developers, then have you ever thought that there may be nothing wrong with you, also will appear this problem?

We have encountered such cases in the Android application development testing process, the APK is installed on a certain model after the completion of the operation is crash, error unsatisfiedlinkerror.

Java.lang.UnsatisfiedLinkError:Couldn ' t load mobsec from loader dalvik.system.pathclassloader.....findlibrary Returned null

The first suspect is in the apk in the corresponding Libs\abi directory is not placed libmobsec.so, but the check found that so in all libs\abi have been placed, continue to troubleshoot;

Then the idea is to place so is not corresponding to the ABI, for example, because of carelessness in the Armeabi directory placed in the x86 instruction set of so, resulting in the armeabi instruction set phone loading error, this is also ruled out;

In the absence of a clue, when the thought of system.loadlibrary function loading so, the system is loaded from the specified path, so does this path exist?

We know that the application's private Native Library directory/data/data/packagename/lib is a symbolic link to the/data/app-lib/<package name> directory, System.loadlibrary is going to this directory to try to load so.

ADB shell to this path, using the command LS View, sure enough, this libmobsec.so does not exist. So what's the cause?

Analysis of the implementation of the Android system source code, found/data/app-lib/<package name> in this directory of So, is installed in the system apk from the Lib directory of the apk when extracted.

When installing the app, the Android Package Manager code needs to analyze the instruction set supported by the current phone and copy the so of the associated instruction set. From the android2.x to the Android6.0 system, due to the addition of x86, 64-bit instruction set support, this part of the Code processing logic has a lot of changes, but this code is a logical flaw, there is the possibility of missing copies, resulting in some models do not necessarily guarantee that all so can be correctly extracted to the/data/app-lib/<package name> directory, causing the application to unsatisfiedlinkerror such errors when loading so.

There are already developers who are aware of this bug, such as a comment in the source code of Chromium, explaining the problem in Android Package Manager:

     * Packagemanager may fail to update the shared library.                    *                    * Native Library directory in an updated package is a symbolic link                    * to a directory In/data/app-lib/<packag e 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 is updated, but fails-extract new native libraries from                    * The new apk.

　　

"The dangers of loading a local library on Android" This article mentions the same problem that the author encounters and is based on an expedient solution given by Chromium: encapsulating the System.loadlibrary interface as a ReLinker interface, if it is found to not load properly , get the APK path and unzip the so of the corresponding instruction set, then try to load it. This scheme is validated to significantly reduce the occurrence of unsatisfiedlinkerror errors, which is a trend graph of the number of days reported unsatisfiedlinkerror errors after the ReLinker interface is used by the author.

The ReLinker interface is now integrated into the NetEase cloud capture SDK, using the following methods:

Use

ReLinker.loadLibrary(context, “mylibrary”);

To replace

System.loadLibrary(“mylibrary”);

Reference Links:
APK installation process and principle Description: http://blog.csdn.net/hdhd588/article/details/6739281
Dangers of loading a local library on Android: Http://www.csdn.net/article/2015-11-10/2826182-the-perils-of-loading-native-libraries-on-android

More information articles, can follow Weibo public number: NetEase Cloud capture

Why Android loads so library Unsatisfiedlinkerror errors and solutions