Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge points about how to deploy so files in android. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article.

1. What is CPU Architecture and ABI

The Android system currently supports the following seven different CPU architectures: ARMv***RMv7 (from 2010), x86 (from 2011), MIPS (from 2012), ARMv8,MIPS64 and x86 / 64 (from 2014), each associated with a corresponding ABI.

The application binary interface (Application Binary Interface) defines how binaries (especially .so files) run on the appropriate system platform, from the instruction set used, memory alignment to available system function libraries. On Android systems, each CPU architecture corresponds to an ABI:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64.

two。 Why do you need to focus on .so files

If NDK is used in the project, it will generate a .so file, so you are obviously already paying attention to it. If you are just coding in the Java language, you may be thinking that you don't need to pay attention to the .so file, because Java is cross-platform. But in fact, even if you only use the Java language in your project, in many cases, you may not realize that the dependent function library or engine library in the project already has .so files embedded in it and depends on different ABI. For example, the project uses RenderScript support libraries, OpenCV,Unity,android-gif-drawable,SQLCipher, etc., you have already included .so files in the generated APK files, and you need to pay attention to .so files.

The ABI supported by Android applications depends on the .so file located in the lib/ABI directory in APK, where ABI may be one of the seven ABI mentioned above.

The Native Libs Monitor app can help us understand which .so files are used in the APK installed on mobile phones and which libraries or frameworks the .so files come from. Of course, we can decompile the APP ourselves to get this information, but it's relatively troublesome.

Many devices support more than one ABI. For example, ARM64 and x86 devices can also run armeabi-v7a and armeabi binaries at the same time. However, * is a binary package that provides the corresponding platform for a specific platform, in which case there is one less simulation layer (such as the virtual layer that simulates arm on x86 devices), resulting in better performance (thanks to recent architectural updates, such as hardware fpu, more registers, better vectorization, etc.). We can use Build.SUPPORTED_ABIS to get a list of ABI supported by devices sorted by preference. But you should not read it from your application, because when the Android package manager installs APK, it automatically selects the .so file precompiled for the corresponding system ABI in the APK package, if there is a .so file in the corresponding lib/ABI directory.

3. Where should the .so file be put?

It's easy to get confused about where .so files should be placed or generated. Here's a summary:

The Android Studio project is placed in the main/jniLibs/ABI directory (of course, you can also specify it by setting the jniLibs.srcDir property in the build.gradle file)

The Eclipse project is placed in the libs/ABI directory (this is also the directory where the ndk-build command generates .so files by default)

The AAR package is located in the jni/ABI directory (.so files are automatically included in the APK that references the AAR package)

In the lib/ABI directory in the final APK file

After installation through PackageManager, the .so file is located in the nativeLibraryPath directory of app on systems less than Android 5.0.In systems greater than or equal to Android 5.0, the .so file is located in the nativeLibraryRootDir/CPU_ARCH directory of app.

4. PackageManagerService chooses the strategy to extract the so file when installing App

In the Android system, when we install the Apk file, the so file under the lib directory will be extracted from the original library directory of the App, generally speaking, it will be placed in the / data/data/package-name/lib directory. According to the difference between the system and the CPU architecture, the copy strategy is also different. The so file is configured incorrectly. For example, when some App uses a third-party so, only the so of one of the CPU schemas is configured. It may cause problems in the adaptation of App on some models.

Android version

So copy Policy

Strategy problem

5. Recommendations for configuring so

In view of these copy policies of the Android system, we give some suggestions for configuring so:

5.1 for both armeabi and armeabi-v7a ABI

Method 1: because the armeabi-v7a instruction set is compatible with the armeabi instruction set, if it is acceptable to lose the performance of some applications, and you do not want to keep two copies of the library, you can remove the armeabi-v7a directory and the library files under it, leaving only the armeabi directory; for example, when Apk uses a third-party so with only armeabi, you can consider removing the armeabi-v7a directory under the lib directory in Apk.

Method 2: put a copy of so in the armeabi and armeabi-v7a directories respectively.

5.2 for x86

At present, x86 models on the market, in order to be compatible with arm instructions, are basically built-in libhoudini modules, that is, binary transcoding support, which is responsible for converting ARM instructions into x86 instructions, so if it is for the consideration of Apk package size and can accept some performance losses, you can choose to delete the x86 library directory, and the so library of the armeabi directory configured under x86 can also be loaded and used normally.

5.3 for 64-bit ABI

If App developers plan to support 64-bit, then 64-bit so should be fully implemented, otherwise you can choose not to compile 64-bit so separately. All 32-bit so,64-bit models support 32-bit so loading by default. For example, if Apk uses a third-party so with only 32-bit ABI so, you can consider removing the 64-bit ABI subdirectory under the lib directory in Apk to ensure the normal use of Apk after installation.

5. Android Studio configure abiFilters

Android {defaultConfig {abiFilters' armeabi-v7a' / /, 'armeabi',' arm64-v8a', 'x864th,' x86y64, 'mips',' mips64'}

This means to specify that NDK requires a compatible architecture, filtering out all compatibility packages except armeabi-v7a, leaving only one armeabi-v7a folder.

Even if we do not specify another compatible framework, we still need a filter. When we access multiple third-party libraries, it is likely that the third-party libraries are compatible with multiple platforms. For example, fresco makes each platform compatible, so it creates a directory of each compatible platform. Because as long as this directory appears, the system will only look for .so files in this directory and will not traverse other directories, so the .so files cannot be found.

6. Java.lang.UnsatisfiedLinkError

There are many types of errors, which are classified as follows:

Java.lang.UnsatisfiedLinkError: dlopen failed: library / / dlopen failed to open java.lang.UnsatisfiedLinkError: findLibrary returned null / / cannot find library java.lang.UnsatisfiedLinkError: Native method not found / / cannot find the corresponding function java.lang.UnsatisfiedLinkError: Cannot load library: load_library / / cannot load library

Cause of occurrence:

Obviously, the root cause of the above collapse is:

(1) so cannot be loaded, which may be due to the absence of so

(2) so loads normally, but the corresponding function is not found.

For the second reason, it is obviously relatively easy to troubleshoot, and in development, such function calls are bound to be tested at compile time and debug mode, so the probability of this cause is small.

Then the following mainly summarizes the reasons for the above crashes caused by several types of "so cannot be loaded":

6.1The generated so itself is defective

A simple example:

Crash stack:

Java.lang.UnsatisfiedLinkError: Cannot load library: find_library (linker.cpp:889): "/ data/data/com.netease.nis.apptestunit/app_lib/libdemo.so" failed to load previously at java.lang.Runtime.load (Runtime.java:340) at java.lang.System.load (System.java:521) at com.netease.nis.bugrpt.ReLinker.loadLibrary (ReLinker.java:76) at com.example.crash.MainActivity.onCreate (MainActivity.java:272) at android .app.Activity.performCreate (Activity.java:5220) at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1086) at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:2193) at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:2279) at android.app.ActivityThread.access$600 (ActivityThread.java:142) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1272) at android.os.Handler.dispatchMessage (Handler.java:99) at android.os.Looper.loop (Looper .java: 137) at android.app.ActivityThread.main (ActivityThread.java:5105) at java.lang.reflect.Method.invokeNative (Native Method) at java.lang.reflect.Method.invoke (Method.java:511) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:793) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:560) at dalvik.system.NativeStart.main (Native Method)

Solution:

Look at the original project Application.mk and find that APP_STL: = gnustl_shared. The original solution uses a shared library, which does not necessarily support all models, so use static library gnustl_static to solve the problem.

Correspondingly, the shared library needs to be changed to the static library gnustl_static in Android Studio. This type of problem with so compiled and shared libraries needs to be checked.

APP_STL available values system system default stlport_static-use STLport as static library stlport_shared-use STLport as shared library gnustl_static-use GNU libstdc++ as static library gnustl_shared-use GNU libstdc++ as shared library

The above example is only a simple example. During the compilation and generation of so, UnsatisfiedLinkError may crash due to reasons such as not considering the model matching of shared libraries, followed by 64-bit 32-bit system architecture problems, which may also lead to UnsatisfiedLinkError crash.

6.2 there is no space for mobile devices

If the so is generated correctly, the corresponding library is generated according to the set framework that supports the so library. In the Android system, when we install the Apk file, the so file under the lib directory will be extracted to the App's original library directory, generally speaking, it will be put under the / data/data/package-name/lib directory. When you are ready to load the so of the native layer, although there is a corresponding so file in the Apk, but because the mobile device does not have enough space to load the so, the loading fails and the above crash occurs.

6.3 so configuration error

If the so is generated correctly and the mobile phone space is sufficient, then, as mentioned above, in the Android system, when we install the Apk file, the so file in the lib directory will be extracted to the App's native library directory, generally put in the / data/data/package-name/lib directory. However, depending on the system and CPU architecture, the copy strategy is also different. If the so file is not configured correctly, for example, when some App uses a third-party so, the so of only one of the CPU architectures is configured, which may cause App adaptation problems on some models and cause the above crash.

6.4 PackageManager installation issues for Android

The user installs the Apk installation package that does not conform to the CPU architecture of the phone, or the so file is not released correctly during the App upgrade process for various reasons. This problem can be solved using ReLinker.

It is very simple to use ReLinker, using the

ReLinker.loadLibrary (context, "mylibrary")

Instead of the standard one.

System.loadLibrary ("mylibrary"); that's all of the article "how to deploy so files in android". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.