Android ABI Understanding

ABI

MIPS uses a single syscall instruction for all access to operating system services. The setup for a syscall instruction puts a syscall code into a register. ... They allocate and keep track of the addresses and allow a programmer to use labels instead of addresses in assembly language code.

MIPS (Microprocessor without Interlocked Pipelined Stages) is a reduced instruction set computer (RISC) instruction set architecture (ISA)
A reduced instruction set computer, or RISC (/rɪsk/),

 For example, if we are having mips, x86, armeabi, armeabi-v7a, armeabi-v8a, then the .so file will be generated for all the five architectures. So, if the size of one .so file is 5MB then the application size should be 5MB but in reality, it will be of 5*5 = 25MB.

Arm, previously Advanced RISC Machine, originally Acorn RISC Machine, is a family of reduced instruction set computing (RISC) architectures for computer processors, configured for various environments.
Bits: 32-bit, 64-bit

Android devices have CPUs. Many of those CPUs are based on the ARM architecture, while some are based on x86, and a few others are based on other stuff like MIPS.

Some Android apps use the Native Development Kit (NDK) to create C/C++ code to link into their app. C/C++ code needs to be compiled for a specific CPU architecture. The NDK places the version of the C/C++ code compiled for each architecture into an architecture-specific directory. One of those directories is armeabi/, which is for a generic ARM CPU. There is also armeabi-v7/ (for an ARM v7-compatible CPU), x86/ (for x86 CPUs), etc.


Depends on what your native code does, but v7a has support for hardware floating point operations, which makes a huge difference. armeabi will work fine on all devices, but will be a lot slower, and won't take advantage of newer devices' CPU capabilities. Do take some benchmarks for your particular application, but removing the armeabi-v7a binaries is generally not a good idea. If you need to reduce size, you might want to have two separate apks for older (armeabi) and newer (armeabi-v7a) devices.

ABI - Application Binary Interface

EABI - Embedded Application Binary Interface

So ARMEABI are compiled binaries matching your android device's CPU architecture.

arm64-v8a (Nexus 5x) - 64bit - ARM Cortex-A35, ARM Cortex-A53, ARM Cortex-A57, ARM Cortex-A72, ARM Cortex-A73

armeabi-v7a - 32bit - ARM Cortex-A5, ARM Cortex-A7, ARM Cortex-A8, ARM Cortex-A9, ARM Cortex-A12, ARM Cortex-A15, ARM Cortex-A17

android {
    sourceSets {
        main {
            jniLibs.srcDirs = ['src/main/jniLibs']
        }
    }
}

dependencies {
    compile fileTree(dir: 'jniLibs', include: ['*.so'])
}
mips
mips64
X86
X86–64
arm64-v8a
armeabi
armeabi-v7a



Android ABIs
Different Android devices use different CPUs, which in turn support different instruction sets. Each combination of CPU and instruction set has its own Application Binary Interface (ABI). An ABI includes the following information:

The CPU instruction set (and extensions) that can be used.


The disadvantage of using native language
The disadvantage associated with using native language is that if you don't use the APK Split or APK Bundle then using NDK alone will increase the APK size. What happens is that the NDK makes the .so file i.e. the machine executable file based on the Architecture of Android. For example, if we are having mips, x86, armeabi, armeabi-v7a, armeabi-v8a, then the .so file will be generated for all the five architectures. So, if the size of one .so file is 5MB then the application size should be 5MB but in reality, it will be of 5*5 = 25MB.

But if you are using APK Split or APK Bundle, then you will make five different APK for different architecture and you will upload all the five APK on play store. Now, the Play Store must identify the device architecture and then give the desired APK to download.

Great explanation.
Thank you.