Apk splits: What I learnt and Why you should definitely try it out
I will like to believe every user loves apps that can do so much for them and at the same time take as little memory space as possible (if this is not true then I just succeeded in wasting my time and probably yours ha!). As android developers, we want to add as many features(that we think users would love) as possible to our apps but as we do this, we need to keep an eye out on the apk size as it is one of the major reasons users that can cause users to uninstall/not install our precious apps.
One of the apps I work on had a relatively large size and from the time I started working on it, this fact hunted me. That some of the people I recommended the app to pointed out apk size as the reason they did not install/ uninstalled it did not make it any better. I actively strived to reduce the size. I used several recommended methods including:
1. proguard,
2. using vector drawables over pngs and jpegs and converting those without . vector drawable equivalents to webP format.
3. swaping 3rd party libraries for first party equivalents (well some of them, I did not swap realm for room, a story for another day 😀 )
These worked, mind you; it cut out about 4mb off the app size and made me happy for a while…
Then we added more cool features and the app size started to grow AGAIN
I did more of those things listed above but the size reduction was negligible so I sought other ways to achieve my aim.
APK Splits to the rescue
I learnt about apk splits while watching a Google I/O’18 talk on android app bundle. While apk splits is not exactly that, on further research, I found out about apk splits.
Apk splits allow app developers to divide (split) their apks across device densities and Application Binary Interfaces (ABIs). These separate apks are uploaded to Google play store and users only get to download the right and optimized apks for their device. The main advantage this offered in respect to apk size reduction is that resources (images, libraries etc) that are not for a device will not get bundled to the device. Each user’s device only gets resources it needs and nothing more!
How To
Go to your app-level build.gradle and add a splits block directly inside inside the android block.
The splits block above contains two sub-blocks: abi block specifying how the apk will be split across device ABIs and a density block specifying the split across device densities.
enable: this could takes values true or false; set it to true to enable the split blocks or false to make gradle skip them.
reset() : This should be used alongside include; it clears the default list of supported densities or ABIs. Using this without the include line would mean no ABI-specific apk would be generated(if it is done within the abi block) and/or no density-specific apk would be generated (if done within the density block).
include: This specifies a list of allowed densities (for the density block) or ABIs (when used within the ABI block) that apks would be generated for.
exclude: This specifies a list of densities or ABIs that will be excluded i.e no apk will be generated for densities or ABIs specified in the exclude line. When exclude is to be used, reset() should not be used.
As a rule of thumb, exclude should be preferred over include if the number of densities or ABIs to remove is far lesser than the ones you want to generate apks for and vice versa.
Note that universalApk is only specified in the abi block. It can take values true or false (it is false by default). When it is set to true, it instructs that a generic apk that contains code and resources for all ABIs be generated alongside the per-ABI apks. This can be used as a fall-back strategy so devices that their ABIs were not included in the split configuration can still use the app via the universal apk. There is no need to specify universalApk for density splits as it is always generated.
Results
These were the apks generated when I built the app
Note that you do not need (you shouldn’t) generate this much separate apks, ideally, you should check your google play console for the major densities and ABIs your users use and make splits for those, other devices outside this range would fall back to use the universal apk.
So that’s it from me now. This post will definitely be continued; the next post will be about how I went about versioning the split apks as they need to have different/unique version codes to be uploaded on google playstore. I am still in the process. If you enjoyed this, please do that clap 👏 thing for me 😉
