Androidiots Podcast 3: Android App Bundles

In this episode of Androidiots podcast, your hosts (me & Anupam Singh) discuss a new publishing format introduced in I/O 2018 by Google called App Bundles.

Show Notes

Multiple APKs:

We have always had support to upload multiple APKs on Play Store to target each device configuration separately. Each APK is a complete and independent version of your application, but they share the same application listing on Google Play are also signed with same release key. This feature is useful for cases in which an application cannot reach all desired devices with a single APK. A single APK is not the most optimised one in terms of size at the very least.

But building multiple APKs involves some work and playing with your gradle files and maintaining different version codes for each APK.

Android App Bundles (AAB):

With Android App Bundles we build only one artifact that includes all of your app’s compiled code, resources, and native libraries for our app. We no longer need to build, sign, upload, and manage version codes for multiple APKs. We automatically get benefits of a smaller apk size as the Dynamic Delivery mechanism (available on Android 5.0 (API level 21) and higher) downloads only those APKs which our users' device needs from the bundle.

Dynamic Delivery with Split APKs:

Fundamental component of Dynamic Delivery is Split APKs. Similar to regular APKs they include DEX code, resources and an Android Manifest. Split APKs are of three kinds:

1. Base APK:
   Basic functionality of the app is included here. Other Split APKs rely on Base APK for resources and code.
2. Configuration APK:
   Each of this APK includes code & resources specific to specific screen density, CPU architecture, or language. An international Dictionary App with a support for 100 languages will have 1 APK per langauge and 1 APK per screen density (ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi). These are automatically generated.
3. Dynamic feature APKs:
   Code download on demand. Each of these APKs contain code and resources that are not required when your app is first installed, but may be downloaded and installed later. Interesting huh..

When we use Android App Bundle, Google Play builds and serves all of our app’s APKs for on our behalf on L+ devices. On Pre-L devices, a single APK is served just as before. So Google Play has backward compatibility covered.

Dynamic Feature Modules:

Dynamic feature modules allows us to separate certain features and resources from the base module of our app and include them in app bundle. Through Dynamic Delivery, users can later download and install those components on demand after they’ve already installed the base APK of our app.

Consider WhatsApp, which has support for both call and chat. Only a small percentage of users use call feature. It might make sense to make call feature a downloadable dynamic feature module. This will make initial download size smaller and only intetested Users need to download additional component.

This seperation of features in dynamic modules requires effort but has lots of benefits. You can learn to create one here.

Testing:

Testing is extremely important and Google has got us covered. Important point to remember is AAB is not same as an APK. We can't install an AAB format on our device. We need to extract the correct APK from it and Google made bundletool. Its a command line tool using which we can extract APK for a specific device configuration. It is the same underlying tool that Gradle, Android Studio, and Google Play use to convert an app bundle into the various APKs that are deployed to devices.

This is average saving on +L device once we move to AAB format.

We discuss a lot more in the podcast and would love to get your feedback, suggestions & questions in the comments.

Cheers!!