How does package manager service select library files in the armeabi/armeabi-v7a?

The C code is used in the Android application, and the so file is compiled and packaged into the libs path of the apk. To support ARMv5 and ARMv7, libs has two directories: armeabi and armeabi-v7a. It is safe to enable Application. mk when compiling C code,

APP_ABI := armeabi armeabi-v7a

The two so files generated by the compilation are stored in the armeabi/armeabi-v7a directory of the project respectively. Sometimes you need to compile libraries that support NEON and do not support neon for the v7a platform. For example,

in armeabi/: libp.so, libd.so, libvh.so, libvn.so in armeabi-v7a/: libp.so, libd.so, libd_neon.so, libvh.so, libvn.so

Note this: The 'armeabi-v7a 'machine code willNotRun on ARMv5 or ARMv6 based devices. if the performance of some applications is acceptable and you do not want to keep the two copies of the library, you can remove the armeabi-v7a directory and the library files under it and keep only the armeabi directory. InInstallThe behavior is like this during application,

When installing an application, the package manager service will scan the. apk and look for any shared library of the form:

lib/<primary-abi>/lib<name>.so

If one is found, then it is copied under $ APPDIR/lib. so, where $ APPDIR corresponds to the application's specific data directory. if none is found, and a secondary ABI is defined, the service will then scan for shared libraries of the form:

lib/<secondary-abi>/lib<name>.so

If anything is found, then it is copied under $ APPDIR/lib. so.

What are primary abi and secondary abi,

The Android system knows at runtime which ABI (s) it supports. more precisely, up to two build-specific system properties are used to indicate: the 'primary' ABI for the device, corresponding to the machine code used in the system image itself. an optional 'secondary' ABI, corresponding to another ABI that is also supported by the system image. for example, a typical ARMv5TE-based device wocould only define the primary ABI as 'armeabi 'and not define a secondary one. on the other hand, a typical ARMv7-based device wocould define the primary ABI to 'armeabi-v7a 'and the secondary one to 'armeabi' since it can run application native binaries generated for both of them. this mechanism ensures that the best machine code for the target device is automatically extracted from the package at installation time.

In this case, the armeabi-v7a directory has a part of the so file that is needed while packaging the apk. Or the example above,

in armeabi/: libp.so, libd.so, libvh.so, libvn.so in armeabi-v7a/: libd.so, libd_neon.so

In this way, what will happen to devices installed and running on v7a? I tried some mobile phones and tablets. the CPU is ARMv7 and Android is 4.x. The action is to copy the following library files to the $ APPDIR/lib/directory,

armeabi-v7a/libd.so, armeabi-v7a/libd_neon.so, armeabi/libp.so, armeabi/libvh.so, armeabi/libvn.so

To meet special requirements, libd has a great impact on performance, for ARMv7 devices, libraries using armeabi-v7a, and other libraries using armeabi. However, if you load libp. so on a mobile phone of ARMv7 + Android2.3.4, an error is returned. Try another ARMv7 + Android2.3.5 mobile phone. For the two phones, if the armeabi-v7a directory is removed when packaging the apk, no error is reported. Is the behavior of the package manager service different from that of the Android2.3 device?