Android App Bundle : Modular and Dynamic App Delivery : Part-1
Android App Bundle
Introduction
In Google IO ’18, Google has introduced a new publishing format (aab) called Android App Bundle. It’s new publishing format for the Android application. The Android App Bundle helps you to reduce the APK size of your application when your application is targeting different screen densities, CPU architectures and languages. I didn’t get chance to attend the app bundle IO session however, I had done the codelab for App bundle at Google IO and watched the session later. I’ve found it interesting. Overall, Android app bundle means smaller application size and more downloads of your application. Let’s talk more about this.
Android App Bundle provides the following advantages:
- Equals/Smaller than traditional APKs => Smaller size downloads to your users => more downloads :)
- Single build artifact makes easy to manage from google play console.
- Dynamic Delivery: Install the application as per user needs.
Basics
Let’s start with the basic, what is android app bundle? It has the same format as like apk file, consider it as zip bundle which contains all code, resources and configurations. App bundle is not directly installable and contains metadata/configuration files which help to build optimized apks for users ( Don’t worry !!, Google Play does this job for you with help of Dynamic Delivery concept). The Format of .aab file looks similar to .apk file, take a look.
Dynamic Delivery (The Right APK for the right users/devices)
Let’s understand how APK targeting works for the user. It’s concept of Google Play Dynamic delivery which I’ve mentioned above in one of the advantages. Dynamic delivery serves only those files to the users which they need and this is what allows us to make apps smaller. It’s the same concept as like split APKs. Now take a look and understand how it generates the apk from app bundle and serves to the user as per user’s device configuration.
App bundle contains three kinds of split apks, for more information check out android developer official website.
- Base APK: APK contains the common code and resources.
- Configuration APKs: APKs include native libraries and resources for a specific screen density, CPU architecture, or language.
- Dynamic feature APKs APKs contain code and resources that are not required when your app is first installed, but may be downloaded and installed later. I’m not discussing this part in this article. For more info please read here.
Ultimately, your app bundle has base apks and config apks. Now, when a user tries to install the application from the playstore, playstore serve only the subset of these apks. For example, User has the Android device with the configurations : arm, xhdpi ,en_US language then final apk will be the combination of (base+arm+xhdpi+en).apk. Refer the below image:
If user moves to different country and change/add the new language in the device settings when user does this Playstore detects this and attempts to download the new additional language split (apk) for all apps that use dynamic delivery concept on the device. If the internet is not available then it will download later.
On L+ devices
Full Dynamic delivery with app bundle only supports Lollipop and above. However, it supports on the pre Lollipop devices as well but doesn’t reduce much in the application size. On pre L devices app bundle only serves density, CPU architecture related splits.
Average Size Savings with help of App bundle + Dynamic Delivery
How to build Android App bundle
There are two ways to generate the app bundle
- Using Android Studio (Requires Android Studio 3.2 Canary 14+ version or above)
2) From Command line
./gradlew bundleDebug
./gradlew bundlefor both ways, the app bundle will be available at/build/outputs/bundleVariant/you_app_bundle.aab
Disable configuration types APKs
If you want to disable split apks for certain configuration then you can control it fully through your build.gradle
android {
// When building Android App Bundles, the splits block is ignored.
splits {...}
// Instead, use the bundle block to control which types of configuration APKs
// you want your app bundle to support.
bundle {
language {
// Specifies that the app bundle should not support
// configuration APKs for language resources. These
// resources are instead packaged with each base and
// dynamic feature APK.
enableSplit = false
}
density {
// This property is set to true by default.
enableSplit = true
}
abi {
// This property is set to true by default.
enableSplit = true
}
}
}Now, app bundle is ready as per your configuration/requirements. Let’s see how to upload to Google Play Console and publish it for play store.
Publishing the Android App Bundle
You must enroll in App signing by Google Play program, Google launched this program last year at IO’17. Otherwise, you can’t upload your app bundle to the Play Console. Play console will sign the generated apk before sending it to the user. Once you’ve uploaded the app bundle, play console will do all background work and generate all possible apks. You can explore your app bundle using Bundle Explorer tab on the Play console web portal. It would look like this :
Test your App bundle
There are two ways:
- Using Internal Test track/channel on Play Console, it may be useful during Q&A or internal testing.
- Using BundleTool, during the development phase. Please check the all possible solutions to install the apk from app bundle.
// 1. Generate apks archive file and install it.$ bundletool build-apks --bundle=<path to .aab>
--output=<out.apks>$ bundletool build-apks --bundle=myapp_bundle.aab
--output=myapp.apks$ unzip out.apks -d apks // unzip archive file and if you want to see all the apks split.$ bundletool install-apks --apks=myapp.apks // install on connected device from apks archive file. If it's giving an issue then check : https://github.com/google/bundletool/issues/8
As per the comment on issue8, we have to set the --ks and --ks-key-alias flags to ensure that the APKs are signed. Only signed APKs can be installed on a device.// 2. Install on connected device.$bundletool build-apks --bundle=myapp_bundle.aab
--output=myapp.apks
--connected-device// 3. Generate apk for specific device
$bundletool build-apks --bundle=myapp_bundle.aab
--output=myapp.apks
--device-spec=pixel2.jsonpixel2.json{
"supportedAbis": ["arm64-v8a", "armeabi-v7a", "armeabi"],
"supportedLocales": ["en-US"],
"screenDensity": 560,
"sdkVersion": 27
}Options 2 & 3 won't work, They will add support of these flags soon : https://github.com/google/bundletool/issues/9// 4. You can also generate signed apk bundle from your CI tool.$bundletool build-apks --bundle=myapp_bundle.aab
--output=myapp.apks
--ks=/Users/saurabh/keystore.jks
--ks-pass=file:/Users/saurabh/keystore.pwd
--key-pass=file:/Users/saurabh/key.pwd// 5. Universal apk, that means master apk (traditional apk) for all devices.
$bundletool build-apks --bundle=myapp_bundle.aab --output=myapp.apks --universal
This is all above the Android App bundle. We saw how App bundle works and helps us to reduce our application size. I highly recommend you to start using Android App Bundle publishing format if your application is big and has multiple configurations. I hope it helps you to reduce your application size and increase app downloads :). Make sure to visit known issues section if you face any issue. I’ll talk more about how to play around with bundletool and generate apks in the upcoming part of this article.
Dynamic feature modules
There is one more way to reduce your application size. Google has introduced another feature called Dynamic Feature Modules concept, a new way to break up the app into separate features and delivers them to the user when user needs it. For eg., your application has a bunch of features and one of them is payment functionality , your application total size is 10 MB which includes all functionalities. Among of them, payment functionality uses 2 MB of size and the only small fraction of your users are using this payment functionality so, in that case, it’s unnecessary to occupy 2 MB space for all the users when the application is being installed. With help of Dynamic Feature Modules concept, you can separate this payment functionality from your core/base application and serve it when it’s needed by the user. So, In the above payment feature example, the initial installation only requires 8 MB (20% app size saving) on the user’s device and later user can install the payment feature when it requires.
When to modularize/exclude any specific feature?
- A Small fraction of your users use that feature
- That feature takes the significant amount of space in your application.
- If users can wait a few seconds until that feature is available
In the next article I’ll talk more about Dynamic Feature Modules in depth, feel free to check more about it on android developers website until I publish next article. Share your questions/thoughts in the comments section. I would be happy to discuss more.
Next Article for dynamic feature module is here.
Resources & References
If you’re wishing to learn some more 💻
- Google I/O Video
- Android Developers
Thank you for using your precious time to reading this article, If you liked the article, Clap your 👏👏 to say “thanks!” and help others find this article by sharing it. Also, you can follow me on Twitter or Medium !! Keep Learning 📚
