You can inspect the contents of an APK in Android Studio by opening it.

Modules such as Realm include code chunks on a per-ABI basis which are all included in your APK. Here you can see that Realm is occupying 4.9 MB (27.1%) of the total APK. What if we only included the .so file that would be used by the end-user? Our app download size might stand to go down by ~4 MB. We can make it happen with just a few changes to our Gradle file.

build.gradle

splits {

abi {

enable gradle.startParameter.taskNames.contains("assembleRelease")

reset()

include 'armeabi-v7a', 'arm64-v8a', 'mips', 'x86', 'x86_64'

universalApk false

}

} buildTypes {

...

}

This code chunk is adapted from the recommended one on realm.io. It tells Gradle to generate multiple APKs by ABI type during a release build (their example does it for all builds. I didn’t want to split for debug or our Crashlytics Beta build variant). Also note that universalApk is false by default, so it doesn’t need to be included, but I am going to make a point about that later.

If you read the Google documentation about multiple APK support, you will learn that each APK you upload to the Developer API / Console will need a different version code and each new APK must have a greater code than a previous fitting APK. This means that for multiple APK support, you will need to have different version codes for each APK even though they will be active at the same time. Here is my solution (adapted from Google this time):

build.gradle

android {

...

} // Map for the version code that gives each ABI a value.

ext.abiCodes = ['armeabi-v7a':'1', 'arm64-v8a':'2', 'mips':'3', 'x86':'4', 'x86_64':'5'] import com.android.build.OutputFile // For each APK output variant, override version code of outputs based on ABI codes

// ex) 'mips' -> 3xxx

// ex) 'x86' -> 4xxx

android.applicationVariants.all { variant ->

variant.outputs.each { output ->

def baseVersionCode = project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))

if (baseVersionCode != null) {

output.versionCodeOverride = Integer.valueOf(baseVersionCode + variant.versionCode)

}

}

}

This code will override the default version code for each of the generated APKs and apply a prefix number to it. For example, Hello is on build 257, so the version code for the mips-targeted APK will be 3257. The next build will be 3258. This works with the Developer API’s rules about version numbers because the rules are specific to the set of characteristics that an individual APK fits. In other words, version codes for APKs that support different devices will not be considered against each other. For more information, read the multiple APK support documentation.

This is Google’s suggestion for overriding the version code by ABI:

“…override versionCode with a combination of ext.abiCodes * 1000 + variant.versionCode”.

I think this method may not work permanently because they are adding numbers together rather than truly prepending. This could lead to situations where build numbers are repeated, which would produce an error on the Google Developer Console. ex)

1st arm64-v8a build: 2 * 1000 + 1 = 2001 1001st armeabi-v7a build: 1 * 1000 + 1001 = 2001

Using this method, when we get to the 1001st build of the app, the Google Developer API will reject the update! Sometimes with these types of mathematical conflicts, the numbers will never be reached because they are too far apart, but 1001 builds really doesn’t fit that bill.