1. Lib and libs
are referenced in lib and included in libs.
Files placed in libs will be automatically included by the editor. So don't put the API in libs.
The content of lib will not be packaged into the APK, the content of libs will be packaged into the APK
2. .so library
NDK compiled dynamic link library.
Some important encryption algorithms or core protocols are generally written in C and then called to Java. This can avoid viewing the application source code after decompilation.
3. How to store the .so library
. The correct posture for placing the .so file is actually two sentences:
• In order to reduce the size of the apk, only keep the two folders armeabi and armeabi-v7a, and ensure that the .so files are in these two folders. Consistent quantity
• For the third-party .so that only provides the armeabi version, copy a copy to the armeabi-v7a folder
. Rules for storing so:
You should provide as many .so files optimized for each ABI as possible, but either all Support or none: you should not mix them. You should provide a corresponding .so file for each ABI directory.
Regarding storage, you can look at this article
. What is the role of armeabi under libs?
Storage .so library is mainly compatible with different devices, or it can be said to be compatible with CPU architecture under different Android phones.
Let's talk about
the CPU types of Android cpu Android devices (usually called "ABIs")
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 of which is associated with a corresponding ABI.
Application Binary Interface (Application Binary Interface) defines how binary files (especially .so files) run on the corresponding system platform, from the instruction set used, memory alignment to the available system function library. On the Android system, each CPU architecture corresponds to an ABI: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.
However, the latest Google official documents have removed mips and armv5, as shown in the figure: 
The analysis of each version is as follows:
• mips / mips64: rarely used in mobile phones and can be ignored (Google's latest documentation is no longer supported)
• 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, and considering the x86 market share below 1%, the two x86 related .so are also negligible
• armeabi: ARM v5 this is a fairly old version, the lack of hardware support for floating-point calculations, there are performance bottlenecks when you need a lot of computing
• 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, all of which are based on arm64-v8a. The tested models include Xiaomi Mi 5-Xiaomi 9, Huawei P30, Huawei Mate 10, Meizu Blue 2, etc. v8 architecture
query mobile phone cpu command line:
adb shell getprop ro.product.cpu.abi
- 1
No picture, no truth: 
only an unknown oppo phone, android system 4.3, using v7 architecture
How does ABI work
2020.06 update, I saw a very good article moved over, thank the original author ( https://juejin.im/post/5eae6f86e51d454ddb0b3dc6 )
official document explains as follows:
Android system knows which ABIs it supports at runtime, because the version is specific The system properties of will indicate:
- The main ABI of the device corresponds to the machine code used in the system image itself.
- (Optional) Auxiliary ABI corresponding to other ABIs also supported by the system image.
This mechanism ensures that the system extracts the best machine code from the software package during installation.
For best performance, you should compile directly against the main ABI. For example, a typical device based on ARMv5TE will only define the main ABI: armeabi. In contrast, a typical ARMv7-based device defines the main ABI as armeabi-v7a and the auxiliary ABI as armeabi, because it can run the application native binary files generated for each ABI.
64-bit devices also support its 32-bit variant. Take arm64-v8a device as an example, this device can also run armeabi and armeabi-v7a codes. Note, however, that if the app targets arm64-v8a instead of relying on the device running the armeabi-v7a version of the app, the app will perform much better on 64-bit devices.
Many x86-based devices can also run armeabi-v7a and armeabi NDK binaries. For these devices, the primary ABI will be x86 and the secondary ABI will be armeabi-v7a.
In general , an Android device can support multiple ABIs, the main ABI and auxiliary ABI of the device, the device with arm64-v8a as the main ABI, the auxiliary ABI is armeabi-v7a and armeabi, and the device with armeabi-v7a as the main ABI , The auxiliary ABI is armeabi.
In addition, mobile phones with x86 architecture will include an instruction set dynamic transcoding tool called Houdini provided by Intel to achieve compatibility with arm.so, which means that apps that are compatible with the armeabi platform can run on x86 phones.
ABI specific adaptation process
For a mobile phone whose cpu is arm64-v8a architecture, when it runs the app, when it enters jnilibs to read the library file, first see if there is an arm64-v8a folder, if there is no such folder, go to the armeabi-v7a folder, if No, go to the armeabi folder. If there is no such folder, an exception will be thrown;
if there is an arm64-v8a folder, then go to the .so file with a specific name. Note: If you don't find what you want. The so file will not be searched further down (armeabi-v7a folder), but an exception will be thrown directly.
How to adapt in our project
Q1: Only armeabi-v7a is adapted, so if the APP is installed on a mobile phone with other architectures, such as arm64-v8a, will it bounce?
A: No, but vice versa.
Because armeabi-v7a and arm64-v8a will be downward compatible:
- App that only adapts to armeabi can run on armeabi, x86, x86_64, armeabi-v7a, arm64-v8
- Only adapt to armeabi-v7a can run on armeabi-v7a and arm64-v8a
- Only adapt to arm64-v8a, can run on arm64-v8a
How should we adapt? The following solutions are given:
Solution 1: Only adapt to armeabi
Advantages: Basically adapted to all CPU architectures (except for the obsolete mips and mips_64)
Disadvantages: low performance, equivalent to the need for auxiliary ABI or dynamic transcoding for compatibility on most mobile phones
Solution 2: Only adapt to armeabi-v7a. Same as
Solution 1, except that some of the old devices are filtered out, and the performance and compatibility are more balanced.
Solution 3: Only adapt to arm64-v8
Advantages: Best performance
Disadvantages: Can only run on arm64-v8, some users of old devices have to abandon
These three schemes are all possible. Nowadays, Dachang APP adapts to all three of them, and most of them are the first two schemes. Which one to choose depends on your own considerations, the performance is replaced by compatibility, arm64-v8, and compatibility is replaced by performance armeabi, and the balance between the two is armeabi-v7a.
For 64-bit phones and 64-bit processors
ARM64-bit processors and computer 64-bit processors are two completely incompatible concepts. It is not that 64-bit can be natively backward compatible with 32-bit programs, but 32-bit architecture is integrated into 64-bit processors to run 32-bit programs. Bit program. To put it plainly, it does not run 32-bit programs in 64-bit form, but runs 32-bit programs in 32-bit form.
Since the new 64-bit processor contains two architectures, and the process technology has not been improved (28nm), at the same time, on mobile phones and tablets, the chip area is strictly limited and cannot be excessively increased, which leads to an even distribution of 64-bit ARM processors The number of transistors in each architecture has dropped sharply, which means that from the 32-bit architecture of the 64-bit processor, for the 32-bit processor of the same specification, not only has the performance not improved, but the performance has decreased to a certain extent. But processor manufacturers must give consumers an explanation to better promote 64-bit, so manufacturers must improve performance in other areas to make up for the loss caused by the reduction in the number of transistors in the CPU. For example: replacing GPUs with higher performance, increasing memory bandwidth, multi-core virtual single cores to improve single-core performance, joint running software vendors to modify running score weights (increase GPU scores, reduce CPU scores weights) and so on. In this way, the strengths and weaknesses are maximized, and finally reached the hands of consumers. After running with the running software, it is indeed improved, the users are happy, and the manufacturers' pockets are also bulging.
In summary, the ARM64-bit processor is more appropriate to call it ARM32+64 in the strict sense. Compared with the ARM32-bit processor, it has a step backward and there is room for improvement, but it is precisely because of the retrogression that it has inspired ARM to make progress. The determination to make it drastically change forward, it has to be said that it is also a kind of progress. But is ARM64 really useful on mobile phones? I can only say that it is really useless at the moment, but it may be in the future. (Collected elsewhere) To sum up, the ARM64-bit processor is more appropriate to call it ARM32+64 in the strict sense. Compared with the ARM32-bit processor, there is a step backward and there is room for improvement, but precisely because Backward aroused ARM's aggressive determination, let it make drastic changes forward, it has to be said that it is also a kind of progress. But is ARM64 really useful on mobile phones? I can only say that it is really useless at the moment, but it may be in the future. (Collected elsewhere)
A real 64-bit mobile phone does not just stay on the processor. If it is called a 64-bit mobile phone just because its processor is 64-bit, we can say without hesitation that this may be false propaganda. Fortunately, Lenovo Very clever, when the A678t and A805e were released, only 64-bit processor phones were mentioned.
"64-bit processor mobile phone" and "64-bit mobile phone" are two very different concepts: as long as the processor contains 64 architecture bits, it can be called a "64-bit processor mobile phone". This kind of mobile phone may not work. 64-bit programs are only used to seize the market, and the advantages are not obvious compared with 32-bit phones.
The "64-bit mobile phone" is different: it contains a 64-bit processor, a 64-bit standard system, a 64-bit Android virtual machine, and a 64-bit program. This is the real 64-bit mobile phone!
Google officially said that Android supports 64-bit a long time ago. This is true. From Android 4.0 to Android 4.4, Android systems support 64-bit hardware, but this only means that the underlying driver supports 64-bit and can run. On 64-bit hardware, nothing more. However, the upper layer running the software, whether it is the Dalvik virtual machine or the ART virtual machine, is 32-bit. In other words, as long as your mobile phone system is Android4.0-4.4, even if your processor is 64-bit, you can only run 32-bit programs under a 32-bit virtual machine, even if the real 64-bit programs are in front of you, It cannot be installed either. .
However, Google officially announced the mandatory requirement for 64-bit architecture at the beginning of this year : 
As early as January this year (2019), Google issued a notice that starting from August 1st this year, in addition to providing 32-bit versions of apps, A 64-bit version is required.
Therefore, it is no longer possible to force the use of only armeabi as an architecture before the project.
So what exactly is the 64-bit version support mentioned here?
If your application is written entirely in Java or Kotlin and does not contain any native support, then it means that the application already supports 64-bit.
However, if any native support (so library) is used in the application, it is necessary to provide different versions of so support for these so files and for different CPU architectures.
It should be noted that sometimes, in our own code, the native support is indeed not used, but some third-party libraries used in the App are included.
At this time, the safest way is to analyze the APK file generated by the final package to determine whether it is necessary to provide support for the 64-bit architecture.
Package configuration
split subcontracting
This command can be subcontracted according to various rules, such as subcontracting according to abi, screen density (ie ldpi, hdpi, etc.)
splits {
abi {
enable true
reset()
include 'x86','armabi'
exclude 'armeabi', 'armeabi-v7a', "arm64-v8a"
universalApk true
}
}Include means to include, exclude means not to include. Each item of the included configuration will generate an apk package.
But this configuration will generate two packages, one containing only the x86 so library, and one containing only the armabi so library. , Obviously does not meet the demand
ndk{abiFilters:} filtering
This command can be configured to package only the so library you configured, and not package if there is no configuration, it is very flexible.
Third-party aar files, if this SDK has full support for abi, it may include five kinds of abi, armeabi, armeabi-v7a, x86, arm64-v8a, x86_64, and other so you apply only support armeabi, armeabi-v7a, x86 Three, directly refer to the aar of the sdk, it will automatically compile a package that supports 5 kinds of abi. But the other so of the application lacks support for the other two abi, then if the application is running on the arm64-v8a, x86_64 is the preferred abi device, it will crash, so we need to configure the abiFilter configuration in our app. Avoid some unknown mistakes
//过滤x86的so库
ndk {
abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
}This configuration will package the so libraries under the three packages of armeabi, armeabi-v71, arm64-v8a into one apk, unlike splits, which will have one apk for each package.