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

What this article shares with you is the example analysis of the .so file about Android. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

There was a project that asked to access Amap SDK, and Gao de had .so files, so he was cheated a lot when testing compatibility, so let's start today's topic.

Early Android systems almost only supported ARMv5's CPU architecture. Do you know how many it supports now? Seven!

The Android system currently supports the following seven different CPU architectures: ARMv5,ARMv7 (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 set of instructions 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 mps64 ABI:armeabi,armeabi-v7a,x86,mips,arm64- x865064.

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 .so documents, 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.

Screenshot of Native Libs Monitor

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, it is best to provide binary packages for specific platforms, in which case there is one less analog 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.

Possible mistakes in App

There is a simple but unknown important rule when dealing with .so files.

You should provide .so files optimized for each ABI as much as possible, but either all or none of them: you should not mix them. You should provide the corresponding .so file for each ABI directory.

When an application is installed on a device, only the .so files corresponding to the CPU schema supported by the device are installed. On x86 devices, .so files in the libs/x86 directory will be installed, if they do not exist, .so files in armeabi-v7a will be selected, and if they do not exist, .so files in the armeabi directory will be selected (because x86 devices also support armeabi-v7a and armeabi).

Other places can also make mistakes.

When you introduce a .so file, it not only affects the CPU schema. I can see a series of common errors from other developers, the most common of which are "UnsatisfiedLinkError", "dlopen: failed" and other types of crash or poor performance:

The .so file compiled using the android-21 platform version runs on the android-15 device

When using NDK, you may prefer to use the latest compilation platform, but in fact this is wrong, because the NDK platform is not backward compatible, but forward compatible. It is recommended to use the compilation platform corresponding to app's minSdkVersion.

This also means that when you introduce a precompiled .so file, you need to check the platform version on which it is compiled.

Mix .so files compiled by different C++ runtimes

.so files can be compiled statically or loaded dynamically depending on different C++ runtimes. Mixing different versions of C++ runtimes can lead to a lot of strange crash and should be avoided. As a rule of thumb, there is no problem with statically compiling the C++ runtime when there is only one .so file, otherwise, when there are multiple .so files, you should have all .so files dynamically link to the same C++ runtime.

This means that when a new precompiled .so file is introduced, and there are other .so files in the project, we need to first verify that the newly introduced .so file uses the same C++ runtime as the existing .so file.

No corresponding .so file is provided for each supported CPU schema

This has been mentioned earlier, but you should really pay special attention to it, because it may happen without even realizing it.

For example, your app supports armeabi-v7a and x86 architectures, and then use Android Studio to add a function library dependency that contains .so files and supports more CPU schemas, such as the new android-gif-drawable function library:

Compile'pl.droidsonroids.gif:android-gif-drawable:1.1.+'

After releasing our app, we will find that Crash occurs on some devices, such as Galaxy S6, and eventually only .so files in the 64-bit directory are installed on the phone.

Solution: recompile our .so file to support the missing ABIs, or set the

Ndk.abiFilters

Displays the ABIs supported by the specified.

One last point: if you are a SDK provider but the libraries provided do not support all ABIs, you will screw up your users because they will only support less ABIs than you provide.

Put the .so file in the wrong place

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 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.

Provide only the .so file of the armeabi schema and ignore the other ABIs

All x86/x86_64/armeabi-v7a/arm64-v8a devices support .so files for the armeabi architecture, so removing .so files from other ABIs seems to be a good technique for reducing APK size. But it's not: this not only affects the performance and compatibility of the library.

X86 devices can run ARM type libraries well, but there is no guarantee that crash will not occur at 100%, especially for older devices. 64-bit devices (arm64-v8a, x86x64, mips64) can run 32-bit libraries, but running in 32-bit mode, running 32-bit versions of ART and Android components on 64-bit platforms will lose 64-bit optimized capabilities (ART,webview,media, etc.).

It is a wrong excuse to reduce the size of the APK package, because you can also choose to upload a specified ABI version of APK in the application market. Generating different ABI versions of APK can be configured in build.gradle as follows:

Configuration of build.gradle

You can also optionally configure it, such as the red box:

The above is the example analysis of the .so file of Android. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow 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.