1. Architecture introduction
The early Android system almost only supported the ARMv5 CPU architecture, and later developed to support 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 defines how binary files (especially .so files) run on the corresponding system platform, from the instruction set used, memory alignment to available system function libraries.
On the Android system, each CPU architecture corresponds to an ABI: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.
But the latest Google official document has removed mips and armv5, as shown in the figure:
- x86 / x86_64: Mobile phones with x86 architecture will include an instruction set dynamic transcoding tool called Houdini provided by Intel to achieve compatibility with arm .so. Considering that x86 has a market share of less than 1%, there are two related to x86. so can also be ignored
- armeabi: ARM v5 This is a very old version that lacks hardware support for floating point calculations and has performance bottlenecks when a large amount of calculations are required.
- armeabi-v7a: ARM v7
- arm64-v8a: 64-bit support, the current mainstream version. Although many blogs on the Internet say that v7 is the mainstream version, I have personally tested many mobile phones, which all have the arm64-v8a architecture. The test models include Xiaomi 5-Xiaomi 9. Huawei P30, Huawei mate10, Meilan 2, etc. all use v8 architecture
Query the mobile phone cpu command line:
adb shell getprop ro.product.cpu.abi2. How ABI works
An Android device can support multiple ABIs, the device's main ABI and auxiliary ABI. For devices with arm64-v8a as the main ABI, the auxiliary ABI is armeabi-v7a and armeabi. For devices with armeabi-v7a as the main ABI, the auxiliary ABI is armeabi.
In addition, x86-based mobile phones will include an instruction set dynamic transcoding tool called Houdini provided by Intel to achieve compatibility with arm.so, which means that APPs that adapt to the armeabi platform can run on x86 mobile phones.
3. ABI specific adaptation process
For a mobile phone whose CPU is arm64-v8a architecture, when it runs the app and enters jnilibs to read the library file, first check whether there is an arm64-v8a folder. If there is no such folder, go to the armeabi-v7a folder. If No, then look for the armeabi folder. If there is no such folder, an exception will be thrown.
If there is an arm64-v8a folder, then look for the .so file with a specific name. Note: If the desired one is not found. so file will not be found further down (armeabi-v7a folder), but an exception will be thrown directly.
4. How to adapt in the project
Q1: It is only adapted to armeabi-v7a. If the APP is installed on a mobile phone with other architectures, such as arm64-v8a, will it crash?
A: No, but it will work the other way around.
Because armeabi-v7a and arm64-v8a will be backward compatible:
- Apps that only adapt to armeabi can run on armeabi, x86, x86_64, armeabi-v7a, arm64-v8
- Only adapts to armeabi-v7a and can run on armeabi-v7a and arm64-v8a
- Only adapted to arm64-v8a and can run on arm64-v8a
So how should we adapt? The following options are given:
- Only suitable for armeabi
Advantages: Basically adapted to all CPU architectures (except for the eliminated mips and mips_64)
Disadvantages: low performance, which is equivalent to requiring auxiliary ABI or dynamic transcoding to be compatible on most mobile phones
- Only suitable for armeabi-v7a
In the same way, Plan 1 only filters out some old equipment and is more balanced in terms of performance and compatibility.
- Only suitable for arm64-v8
Advantages: Best performance
Disadvantages: Can only run on arm64-v8. If you want to give up some old equipment users, all
three options are available. Nowadays, in the APP adaptation of major manufacturers, all three options are available, most of which are The first 2 options. Which one you choose depends on your own considerations. If you trade performance for compatibility, arm64-v8 is the choice; if compatibility is trade-off for performance, armeabi, the one with a slightly better balance between the two is armeabi-v7a.
As early as January of this year (2019), Google issued a notice that starting from August 1 this year, in addition to providing 32-bit versions, apps on the shelves must also provide 64-bit versions.
Therefore, the previous method of forcing the project to use only armeabi architecture is no longer feasible.
So what exactly is the 64-bit version support mentioned here?
If your application is entirely coded in Java or Kotlin and does not contain any native support, it means that the application already supports 64-bit.
However, if any native support (so library) is used in the application, different versions of so support need to be provided for different CPU architectures for these so files.
It should be noted that sometimes, in our own code, we do not use native support, but it is included in some third-party libraries used in the App.
The most reliable way at this time is to analyze the final packaged and generated APK file to determine whether support for 64-bit architecture is needed.
5. Packaging configuration
split subcontracting
This command can subcontract according to various rules, such as subcontracting according to abi, screen density (i.e. ldpi, hdpi, etc.)
splits {
abi {
enable true
reset()
include 'x86','armabi'
exclude 'armeabi', 'armeabi-v7a', "arm64-v8a"
universalApk true
}
}
ndk{abiFilters:} filtering
This command can be configured to only package the so library you configured. If it is not configured, it will not be packaged. It is very flexible.
Third-party AAR files, if the SDK has relatively complete support for ABI, it may include five ABIs: armeabi, armeabi-v7a, x86, arm64-v8a, and x86_64, while other SOs you apply only support armeabi, armeabi-v7a, and x86 Three types, directly refer to the aar of the sdk, will automatically compile a package that supports 5 kinds of abi. However, other so of the application lacks support for the other two abi, so if the application is run on a device with arm64-v8a and x86_64 as the preferred abi, it will crash, so we need to configure the abiFilter configuration in our app to Avoid some unknown errors
//Filter x86 so library
//过滤x86的so库
ndk {
abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
}
This configuration will package the so libraries under the three packages armeabi, armeabi-v71, and arm64-v8a into one apk, unlike splits which will pack an apk for each package.
Reprinted from: Android arm64-v8a, armeabi-v7a, armeabi detailed explanation