preface

First of all, it should be known that 64-bit devices are compatible with 32-bit SO files. At present, many mainstream apps only place 32-bit SO in APP, in order to reduce the packaging volume of APK. The drawback is that the computing power of 64-bit CPU cannot be fully played when running on 64-bit devices.

However, our project did not do this. Instead, we put both 32 and 64 bit SO in the APP, which resulted in a sudden increase in the volume of APK. The reason is that LOADING 3D graphics in the APP consumes CPU, so 64 bit SO is used for practical experience when running on 64 bit devices. Just use 32 bits. So the question arises, is it possible to place only the 64-bit SO required for loading graphics and the 32-bit SO required for other functions in the app? Mix 32 and 64-bit SO.

Try to process

  • Conclusion first, if there is no UI interaction (such as video transcoding) with 64-bit SO, there is a solution. If these functions require interface interaction, they cannot be solved at present.

  • Android does not allow mixed use of so files, either all 32 bits or all 64 bits, in the lib directory, otherwise the file will crash if it cannot be found when loading. Then I put the graphics function Activity that requires 64-bit SO into a new process, and dynamically loaded the 64-bit SO file, but still reported an error.

  • Then I tried to fool the lib folder by placing the 64-bit so in armeabi, but I failed to load it and the vm found that the armeabi did not contain the 32-bit so…

  • Then try, not putting any SO in the app project, dynamically loading 32-bit first, then 64-bit so. Still won’t do

  • After a day of trying and failing, I decided to try my luck on StackOverflow. This is an amazing site. https://stackoverflow.com/questions/45353090/how-to-mix-32-and-64-bit-so-files-in-an-app is roughly means that Android when install the apk have already decided on, Loading 32-bit or 64-bit so is a choice, but try compiling 64-bit Linux executables with c++ source code, skipping JNI calls and using runtime. exec directly from the android Runtime command line calls. In this way, we can mix 32 and 64 bit SO in the APP, but this will not solve the UI interaction function.

OK, the graphics loading of our project certainly has UI interaction. This problem has not been solved yet, but we have learned two new gestures: one is the mechanism of Android loading so file, and the other is how to load so file dynamically.

Android load so file mechanism

In the process of apK installation, the system will parse the APK according to the so file type in the APK to determine whether the APK is installed on a 32-bit or 64-bit VIRTUAL machine. If the APK is installed on a 32-bit virtual machine, the 64-bit SO cannot be used. If the APK is installed on a 64-bit virtual machine, the 64-bit SO cannot be used. 64-bit devices can provide both 32 – and 64-bit VMS. You can choose which vm to enable according to APK. Therefore, 64-bit devices are compatible with the 32 SO library.

The specific mechanism can be divided into the following four situations: 1. Assume that the APK lib directory contains both 32 and 64 bits of SO, then the installation will be filtered from top to bottom according to the CPU architecture of the current device (X86 > ARM64 > ARM32). Once the SO file matching the device is found in the lib, the architecture will be directly selected as the standard. Such as the current equipment is 64 and found that there is a 64 – bit lib so, then the apk will copy all 64 so under the lib files to the data/data/packageName/lib/directory (see this need ROOT directory)

2. Apk’s lib directory only places 32-bit so, according to the principle above, running on 32-bit devices is OK. Most 64-bit devices are OK, but x86 devices will definitely crash. If you’re running on a 64-bit device and you load a 64-bit so file dynamically in your code, you’ll get an error: so is 64-bit instead of 32-bit

Apk can only run on 64-bit devices. If you load 32-bit so in your code, you will get an error: so is 32-bit instead of 64-bit

4. Apk lib does not put any so files, all dynamic loading. If you install it on a 32-bit device, you can only load the 32-bit SO. If you install it on a 64-bit device, your APK will run on a 64-bit virtual machine by default.

Dynamic loading of SO

Let’s start with static loading: Development put so library project lib directory, install the apk System will copy the files to the data/data/packageName/lib/directory, System. LoadLibrary () this method does not specify the absolute path of the so file, because the System will go directly to the directory to find. This loading is a common way to use so files, but the downside is that apK can become very large.

In this case, dynamic loading can be considered: APK does not place any SO files. After installation and running, it downloads the corresponding SO files from the server according to the functional requirements, copies them to the specified directory and calls System.load(the absolute path of so) to load.

The disadvantage of dynamic loading is that it requires extra workload on the server side and the later maintenance of SO file. So far, I have not actually used it in the project. However, it is possible to put so in the Asset directory and then dynamically copy it to the specified directory. There are two things to note in the Demo:

  1. Directory of dynamic loading is not data/data/packageName/lib /, this directory is read only not to write, but this directory:

String libPath = “/data/data/” + getPackageName(); // Your application path

Download so to SD card, copy so to libPath (no special permissions required), then call system.load (libPath + “/libmp3lame.so”) to load dynamically.

  1. There are a lot of mainstream apps that are ditching 64 and x86 SO files in favor of 32 bits. If you also want to use only 32-bit SO and load it dynamically, you may find that the app runs on a 64-bit phone and crashes when loading SO, for the reason of the so loading mechanism # 4 above. The solution is to put a 32-bit so file in your app’s lib directory (you can put a small one).

Reference Documents:

http://www.wjdiankong.cn/android%E4%B8%ADso%E4%BD%BF%E7%94%A8%E7%9F%A5%E8%AF%86%E5%92%8C%E9%97%AE%E9%A2%98%E6%80%BB%E7%B B%93%E4%BB%A5%E5%8F%8A%E6%8F%92%E4%BB%B6%E5%BC%80%E5%8F%91%E8%BF%87%E7%A8%8B%E4%B8%AD%E5%8A%A0%E8%BD%BDso/