preface
With the continuous development of mobile phone hardware, the new mobile phones in the past two years have all adopted 64-bit CPU, 64-bit is really faster than 32-bit? The actual difference between 32-bit and 64-bit is mostly in memory addressing, with 32-bit supporting up to 4GB of memory, while 64-bit can support up to 128GB.
There are also demands for 64-bit adaptation in various application markets.
Google Play:
Starting August 1, 2019, apps distributed on Google Play must support 64-bit architecture.
Domestic:
Xiaomi App Store, OPPO App Store, Vivo App Store and others have issued a notice:
- End of December 2021: Existing and newly released apps/games will need to upload APK packages containing the 64-bit package (support for both in-rack and 32-bit compatible versions, no longer accept 32-bit only APK packages).
- End of August 2022: Systems with 64-bit hardware support will only receive APK packages with 64-bit versions.
- End of 2023: Hardware will only support 64-bit APK, 32-bit applications will not run on terminals.
Huawei App Store:
- From February 1, 2022, newly released or upgraded games and applications in Huawei App Market must contain 64-bit versions, and Huawei App Market will no longer accept apps with 32-bit versions only.
- From September 1, 2022, Huawei App Market will no longer accept applications containing 32-bit versions.
Android ABI
Different Android devices use different cpus, and different cpus support different instruction sets. Each combination of CPU and instruction set has its own application binary interface (ABI).
Android devices support the following ABI types:
| ABI | Supported instruction sets | note |
|---|---|---|
| armeabi-v7a | armeabi Thumb-2 VFPv3-D16 |
Incompatible with ARMv5/ V6 devices. It is suitable for 32-bit ARM-based cpus and is gradually being abandoned. |
| arm64-v8a | AArch64 | Suitable for ARMV8-A based CPU, support 64-bit AArch64 architecture, the current mainstream. |
| x86 | x86 (IA-32) MMX SSE/2/3 SSSE3 |
MOVBE or SSE4 is not supported. It’s usually a simulator. |
| x86_64 | x86-64 MMX SSE/2/3 SSSE3 SSE4.1, 4.2 POPCNT |
It’s usually a simulator. |
For example, arm64-V8A cpus can run ARmeabi-V7A sO, and vice versa. This is why many apps now only contain Armeabi-V7a packages that run on the latest cpus. Apps that currently only include Armeabi or Armeabi-V7a will no longer run if future cpus are no longer compatible with older architectures.
If the application includes both architectures, the application will run with two Zygote (one 32-bit and one 64-bit) processes running at the same time. APP installation is based on the supported architecture in the lib directory and the machine’s own CPU type. At startup, the child process is fork from the 64-bit or 32-bit Zygote process based on the value of primaryCpuAbi determined at installation time, or if fork from 64, run in 64-bit mode.
Due to the increasing functions of some software, the volume of the installation package and the running memory required to consume are becoming larger and larger, and the limitations of 32-bit applications are becoming more and more prominent. 64-bit systems, which can use more than 4GB of operating memory in a single thread, can take advantage of the advantages of mobile hardware when processing large software or high-pixel images and videos. For example, some large games, live network video, high quality video and so on. And 64-bit systems offer at least a 20% increase in efficiency over 32-bit systems.
Check to see if your application supports 64-bit architecture
As for how to retrieve so files that do not support 64-bit in APK, there are two official methods, please refer to the specific methods
An easy way to do this is to use the APK analysis tool provided by Android Studio and look at the lib folder. If the folder contains only armeabi or Armeabi-v7a, it only supports 32 bits, not 64 bits. If you also have the arm64-V8A folder, it indicates that there is a 64-bit native library, whether it has the same functionality and quality as 32-bit, still need to test.
As you can see there are no ARM64-V8A or X86_64 libraries, you need to update the build process to start building and packaging these artifacts in APK.
In-app native libraries generally come from three sources:
- Third-party libraries
- So files in the project
- C/C++ source module
Many third-party libraries support both 32 and 64 bits, but some do not. How to find out which libraries or files are not supported? If the number of.so files in your project is large, it is difficult to find them visually.
The mergeReleaseNativeLibs Task (mergeDebugNativeLibs is also available, depending on your situation) can be used to retrieve the.so file during the project packaging process using Gradle scripts or some existing third-party frameworks. Check whether the path of each. So file contains names such as “aremeabi-v7a”, “arm64-v8a”, “x86”, and “x86_64” to determine the type of.
Core code:
void apply(Project project) {
project.afterEvaluate {
// 1. Find the task merge[BuildVariants]NativeLibs
Task mergeNativeTask = null
for (Task task : project.getTasks()) {
if (task.name.startsWith("merge") && task.name.endsWith("NativeLibs")) {
mergeNativeTask = task
}
}
if (null == mergeNativeTask) {
return
}
// 2. Create detect task.
project.getTasks().create("support 64-bit abi") {
group "privacy"
dependsOn mergeNativeTask
doFirst {
println "EasyPrivacy => Support 64-bit abi start."
SoFileList soList = new SoFileList()
// 2.1 Find so file recursively.
mergeNativeTask.inputs.files.each { file ->
findSoFile(file, soList)
}
// 2.2 Print 64-bit abi supported status
soList.printlnResult()
}
}
}
}
/** * Find so file recursively. */
void findSoFile(File file, SoFileList soList) {
if (null == file) {
return
}
if (file.isDirectory()) {
// recursively
file.listFiles().each {
findSoFile(it, soList)
}
} else if (file.absolutePath.endsWith(".so")) {
println "EasyPrivacy => so: ${file.absolutePath}"
SoFile so = generateSoInfo(file)
if (so.soPath.contains("armeabi-v7a")) {
soList.armeabiv_v7a.add(so)
} else if (so.soPath.contains("armeabi")) {
soList.armeabi.add(so)
} else if (so.soPath.contains("arm64-v8a")) {
soList.arm64_v8a.add(so)
} else if (so.soPath.contains("x86_64")) {
soList.x86_64.add(so)
} else if (so.soPath.contains("x86")) {
soList.x86.add(so)
} else if (so.soPath.contains("mips64")) {
soList.mips_64.add(so)
} else if (so.soPath.contains("mips")) {
soList.mips.add(so)
}
}
}
Copy the codeHere we use a packaged Gradle plug-in, EasyPrivacy through integration and use, detect the project, arm64-V8A has not been adapted. So files.
So files in armeabiv-v7A, but not in arm64-V8a need to be adapted according to the project
We will see jetified- gsyVideoPlayer-armv7A-8.0.0 :libijkffmpeg.so, and we are tified-gsyVideoPlayer-armv7a-8.0.0:libijkplayer.so Will we be tified- gsyVideoPlayer-armV7A-8.0.0: libijKsdl. So.
64-bit adaptation modified
First we will modify the packaging configuration:
NDK {// Select the.so library of the corresponding CPU type to add. Separate multiple ABIs with commas (,). AbiFilters "armeabi-v7a" // Can specify the values of 'armeabi-v7a', 'arm64-v8A ', 'armeabi', 'x86', 'x86_64',}Copy the codeTo:
ndk {
abiFilters "armeabi-v7a", "arm64-v8a"
}
Copy the codeThe arm64-V8A.so folder is now visible
64-bit libraries are now supported, but further checks and testing are needed to see if they have the same functionality and quality as 32-bit libraries.
Then through the reference instructions of gsyVideoPlayer, we can select com.shuyu:gsyVideoPlayer-arm64 version for access, after access modification, re-check:
We found that the following reminder didn’t go away:
so in armeabiv-v7a, but not in arm64-v8a: [jetified - gsyVideoPlayer - armv7a - 8.0.0: libijkffmpeg. So] [jetified - gsyVideoPlayer - armv7a - 8.0.0: libijkplayer. So] [jetified - gsyVideoPlayer - armv7a - 8.0.0: libijksdl. So]Copy the codeDon’t be nervous, this is due to the naming problem of the three-party library. According to the arm64-V8A size in the figure above, we can observe that the size value has changed from 52 to 55. Then we go to the corresponding APK to check. Check whether libijkffmpeg.so, libijkplayer.so, libijksdl.
As you can see, tripartite.so files with 64-bit support have been successfully introduced.
Although putting all the SUPPORTED ABI’s SO in one package can be used for all devices, the disadvantage is that the package size can increase, especially if there are many native libraries. If you are a Google marketplace application package, you can use the Android App Bundle to reduce the size. However, the domestic application market does not support this, but some domestic application markets provide the ability to upload 32-bit compatible packages and 64-bit packages respectively, so the ability to build multiple APKs can be used to print packages that support different ABI, and the application market distributes corresponding packages according to the CPU type of users’ mobile phones. Can reduce the size of the package downloaded by the user.
The split configuration is reset and the mono {abi {enable true // Splits within this range. Include 'armeabi-v7a', 'arm64-v8a'// which schema types are included. UniversalApk false // Whether to create an APK for all available ABIs. }}Copy the codeThe Task assembleRelease is then executed to package and you can see the packages that produced the different ABIs in the specified directory.
You can use adb to check the CPU type of your phone:
adb shell getprop ro.product.cpu.abi
arm64-v8a
Copy the codeAdb shell getprop ro.product.cpu.abi if arm64-v8a is displayed, it indicates that the CPU type of the mobile phone is 64-bit.
If the function test is correct, the Apk package can be uploaded according to the upload requirements of the application market
summary
64-bit adaptation is the current mainstream trend of Android mobile applications, good adaptation can not only meet the policy, but also improve the operation efficiency of the application on the new model. Although the domestic market has just begun to require, but to avoid one day due to the impact of the policy, your application can not be put on the shelves, or make a plan