Menu
I have developed an app which is mostly in C++ and is compiled by NDK to .so libraries as usual. We know that native apps have to be build for each CPU architecture separately; So I have different so files for armeabi and armeabi-v7a. (I deliberately left out x86 and mips, since not many Android devices with these architectures are released.)
However, the size is very big and each so file takes about 90 MB of space and I want to reduce it.
I know I can leave out armeabi-v7a, because of backward compatibility, but in that case the app will run very slowly.
Considering the fact that my app supports only android ICS and above (minSdkVersion="14"), Can I safely remove armeabi and suppose that all of these new devices use armeabi-v7a? Or some of the devices may still use the old armeabi and not armeabi-v7a architectures?
951
armeabi-v7a is the older target, for 32 bit arm cpus, almost all arm devices support this target. arm64-v8a is the more recent 64 bit target (similar to the 32-bit -> 64 bit transition in desktop computers).
armeabi-v7a This ABI is for 32-bit ARM-based CPUs.
Many modern Android devices (i.e. Nexus 5x) have AArch64 processors with arm64-v8a instruction set. Both - armeabi and armeabi-v7a - libraries run fine on these modern devices.
EABI - Embedded Application Binary Interface. So ARMEABI are compiled binaries matching your android device's CPU architecture.
Many x86-based devices can also run armeabi-v7a and armeabi NDK binaries. For such devices, the primary ABI would be x86, and the second one, armeabi-v7a. You can force install an apk for a specific ABI .
Note: Historically the NDK supported ARMv5 (armeabi), and 32-bit and 64-bit MIPS, but support for these ABIs was removed in NDK r17. Note: ARMv7-based Android devices running 4.0.3 or earlier install native libraries from the armeabi directory instead of the armeabi-v7a directory if both directories exist.
Note: ARMv7-based Android devices running 4.0.3 or earlier install native libraries from the armeabi directory instead of the armeabi-v7a directory if both directories exist. This is because /lib/armeabi/ comes after /lib/armeabi-v7a/ in the APK.
By contrast, a typical, ARMv7-based device would define the primary ABI as armeabi-v7a and the secondary one as armeabi, since it can run application native binaries generated for each of them. 64-bit devices also support their 32-bit variants. Using arm64-v8a devices as an example, the device can also run armeabi and armeabi-v7a code.
The unmodified, original Android source for Android 4.0 and newer doesn't support ARMv5/ARMv6 by default (but can be modified to build for ARMv5/ARMv6 - there are custom builds of it that run on ARMv6). I'm not sure if one can get an ARMv6 device certified compatible with such Android releases, or if it only is applicable for unofficial firmwares. Since Android 4.4, the CDD (compatibility definition) strictly requires ARMv7. See https://android.stackexchange.com/questions/34958/what-are-the-minimum-hardware-specifications-for-android for details on this.
So yes, maybe, in principle, you could drop armeabi if your app requires Android 4.0, but I'm not sure if there is any such official guarantee. If you require Android 4.4, it should absolutely be fine though.
82
There are no Android 4+ devices which support armeabi but not armeabi-v7a, so you can safely drop armeabi.
You can check this yourself in Google Play: create 2 APK's (1 which supports armeabi and 1 which supports armeabi-v7a) and try uploading both to Google Play. You'll notice they have the same number of supported devices.
You will even get an error when uploading to Google Play if you split your APK by architecture while trying to support both architectures:
Version xxx of this app can not be downloaded by any devices as they will all receive APKs with higher version codes.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
