Let’s take an example to understand ABI in detail

I have created a sample app with one activity and launcher icons.

Analysis of the APK file

Now let’s add a native library with multiple ABIs, for this demo I will be using Realm.

Note: This issue is not specific to realm, this is how all native library will behave on Android.

APK details after adding Realm

APK size is now 5MB from 74KB and we all are like …

Let’s take a look what happened there.

Realm distribution for different CPU architecture

So basically realm adds .so file for 5 CPU architectures mips, X86, X86–64, armeabi-v7a, and arm64-v8a this increases the apk size by 4.8 MB; remaining ~130KB is increased in dex size.

If you release this application Google Pixel device will install this 5MB apk where it needs only one version of the Realm lib (arm64-v8a) that is just 947KB, that is a huge overhead. (It will even work fine with v7 version of realm which is just 771KB, we will understand this soon.)

Let’s see how ABI split can help us in avoiding this problem

ABI split is basically telling gradle build system to create multiple apks for the different CPU architecture and include only relevant native libraries. The app module’s build.gradle looks like below with ABI split.

Android application level build.gradle file.

If you add this configuration in the application it will create a different version of apk for all different architectures as shown below.

Multiple APK files generated after enabling split

Amazing right! We went from 74KB to 5MB and came back to 1.3 MB. But But But….

Though we now have a tailored version of apk only with necessary things, these are 5 apk for one application and we haven’t even gone through the apk splitting based on the density (This option generates individual apk for xhdpi, xxhdpi, and xxxhdpi depending on the configuration) which is more helpful than optimising for native library.

Normally we would want to split apk for at least hdpi, xhdpi, and xxhdpi version of the application so now we have 15 APKs to release. Let’s say you release an update of the application every month then you have to maintain 15 apks and imagine your client/senior comes and tells you need to do sanity for every apk before release just to be sure.

There is even a bigger problem than this cumbersome maintenance.

If you are building the application for the mass audience, users in emerging market like India where the mobile data and WiFi is not as cheap as other developed countries, users share the application using Bluetooth or Hot-Spot via SHAREit or Xender and side-load it.