APK Split Tutorial

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

The apk split is a process which allows you to optimize your apk by changing just a few criteria. The goal of this process is to reduce the size of an apk downloaded by a user. It does not compress the app or the pictures. The split of the apk can be done by switching the DPI (screen density) or the ABI (cpu architecture). This tutorial gives an overview of the DPI split because it allows a better apk size reduction.

1) Why Do An APK Split?

In Europe and North America, we have efficient smartphones with 32 or 64 GB of memory, but globally, the average smartphones have very little memory (sometimes, less than 512MB). So, if you want to access all markets, you need to adapt your application, otherwise many won’t be able to download your apk.

Facebook is a really good example of this. With their “Facebook lite” the apk size has been reduced by removing a lot of drawables.

In addition to the “lite app” Facebook implemented the apk split which allows them to reduce their apk size even further

So, if you don’t want to (or can’t) modify your design or drawable ; the apk split is a very good way to reduce your apk size.

2) How?

a) Preparation

First, be sure you have all drawables in all the dpi. If your app doesn’t support a specific dpi (like the ldpi or the tvdpi), don’t worry, you can remove them from the apk split and a “universal” apk will be generated. This apk will contain all the drawables just as if the apk split was not implemented. (The ‘universal’ apk is like a witness apk. It will be generated the same way as if there were no apk split implemented). It will be used by the users with unsupported dpi. When you’re ready, we’ll modify the build.gradle file.

b) Implementation

Add these lines into the android dsl :

That’s it! Now Gradle will generate one apk by density. But, you’re still not able to publish them to the Play Store. As you may know, the Play Store permits only one apk by versionCode. So, now, we’ll create one versionCode by apk.

c) Versioning

In the same file, add these lines in the android dsl :

This script overrides the versionCode of each apk. It allows you to have 100 different variants of your apk version. For, example, if your versionCode is 123, the script will generate an apk 12300 (for the universal), 12301 for the ldpi, 12302 for the mdpi, etc.

You’re now ready to publish these apks on the Play Store.

d) Renaming

This script is not mandatory, but I encourage you to use it to keep some order in your apks. It will rename each apk according to its dpi and place it into a dedicated folder. 

Now, add this script to the apk generation script. In the previous point, we created a
function for each time an apk was generated. Let’s modify it :

Run Gradle, and check into your project root ; a folder “archive” has been created containing your apks ordered by versionCode.

3) Publish on the Play Store

Now that you have your apks, you’re able to publish them.

Be very careful, once you have published an apk, you can’t remove it from the Play Store, so, test it twice…

Publishing multiple apks is the same process as publishing one. But, publish the apks in the same order as their versionCode. So, for example, publish the 12300 followed by the 12301, 12302, etc. Be sure not to forget one.

Finally, you should have something like this :

APK Split Tutorial

4) Drawbacks

a) Complexity of the tests

Without the apk split, if a drawable was missing in a specific dpi, Android would choose the same drawable in another dpi. Now, with the apk split, if a drawable is missing in a dpi, it will be missing in the whole apk. A lot of crashes may be due to this issue. I strongly encourage you to manually test your apk in all the DPIs possible before publishing it on the Play Store.

b) Complexity of the versioning

If you use the versionCode in your app, you’ll need to adapt your code because instead of giving you 123, Android will give you 12301. So, check everywhere if you don’t use the versionCode. Another problem of the versionCode override is that if you have a small bug in a specific dpi (due to a missing drawable for example), you will need to generate a new versionCode and publish all your apks to the Play Store.

5) Feedback

At Be-Bound, we’ve used the apk split for several months. It was very hard to implement because of the huge amount of drawables to check and modify.

It’s a simple concept, but can quickly become unstable. That’s why I recommend it only for people who have the time to test their apk2 or 3 times.

If you have the time, it’s worth it. At Be-Bound we were happy to see the apk size reduced from 20MB to 6MB (ldpi) → 12MB (xxhdpi).

5) Complete build.gradle Sample


4 Comments

  • Jonathan

    18 April 2016

    Please add an example build.gradle

    Reply
    • Bebound

      27 April 2016

      Hi Jonathan,
      Thanks for your suggestion. We’ll add an example by the end of the week! Stay tuned…

      Reply
    • Bebound

      2 May 2016

      Hi Jonathan,

      We’ve added a build.gradle sample to the article for you. Hope that helps!

      Reply
  • nandan

    23 December 2016

    Nice tips. Thanks for this post.

    Reply

Leave a Reply