Google I/O 2018 Session in 5 mins – Build the new, modular App Bundle

During the developer keynote at Google I/O 2018, Google announced a new app model for Android app distribution that promises to significantly cut down on average app size and decrease the time to download. This new model is called Android App Bundle and it works on 99% of Android devices out there. It introduces some new concepts but is built on existing platform concepts (such as splits and multiple APKs). According to Google, larger APKs directly correlate to fewer app installs. App Bundle’s main purpose is to remedy this by decreasing the overall APK size.

Later in the first day of Google I/O there was an entire hour-long session dedicated to the changes in the new app model. You can watch the session here or continue reading for a summary and highlights from the talk.

The session is a highly technical deep dive into the new app model and a lot of time is spent on the App Bundle specification and how it is used to shrink app sizes, so we’ll start there.

APP BUNDLE

The App Bundle is a zip file with a structure not too different from regular Android APKs, however the file itself is not installable on devices. It is purely used as a format for app distribution. It contains extra files with metadata and has stricter validation requirements than APKs.

The manifest file is still present but instead of being compiled to a binary format, it is compiled into a Protocol Buffer format to ease processing and transformation.

Just like the APK format, App Bundle supports File Targeting of resources (e.g. ‘res/drawable-hdpi/banner.png’, ‘res/layout-w200dp/activity_main.xml’, etc.), but it also adds support for Assets Targeting.

This new targeting allows developers to categorize assets in directories by specific attributes (such as language, texture compression format and graphic API type)

By using the targeting information in the App Bundle file the Google Play Store can generate all the possible APKs. First a Base APK is generated with all the common components, and then the rest of the Split APKs are generated based on supported screen densities, CPU architectures, and languages.

All the generated APKs are called Configuration Splits or Config Splits. There are some caveats when dealing with Pre-Lollipop devices as the Config Splits for those devices will always contain all of the language resources.

Generating the new App Bundle is pretty straightforward. Support for it is included in the upcoming version of Android Studio (or in the latest 3.2 Canary version) and the newest Gradle Android plugin. Similar to the existing “assemble” task, a new “bundle” task can be used to generate App Bundles for all flavors or only for a specific variant:

• “$ ./gradlew modulename:bundle”

• “$ ./gradlew modulename:bundleVariant”

The Gradle Android plugin also allows developers to opt-out of Config Split generation by overriding them in the build.gradle file of the application.

Once the App Bundle is generated developers have a couple of options for generating the Config Splits. Google’s recommended approach is to enroll in App Signing by Google Play and then upload the App Bundle file to the Google Play Console. Play will use the securely stored release key to sign all the generated APKs before serving them to users (there is also a new Bundle Explorer page that lets you see and download each of the generated split APKs)

BUNDLETOOL

The second option is to use Bundletool, a newly released open source tool available here. This tool can be used by developers to locally generate specific Config Splits and test with the exact APKs that a user will get from Play Store. It can also be added into Continuous Integration (CI) environments to generate the full set of Config Splits supported by the application or to generate a single universal APK file that can be installed anywhere.

DYNAMIC FEATURES AND DYNAMIC DELIVERY

The second big topic of the session was modularization by using the new Dynamic Features and Dynamic Delivery functionality. For most developers this new functionality is the most interesting aspect of the new app distribution model as it allows for even more size savings and flexibility.

Using Dynamic Features allows developers to:

• Split up parts of their application and only deliver to devices as features are used

• Installation of features in the background after the initial download

• Request that parts of the application be uninstalled when they are no longer used

Some examples of features that could benefit from this modularity are user registration flows, content upload flows, FAQ pages, support pages, and other similar flows.

Breaking up your app features into modules can be achieved by using the new Dynamic Module template available in Android Studio and the new Play Core Library which has APIs for managing the requesting and installation of on-demand modules.

An important aspect of these on-demand modules is that versions are always kept in sync by Play Store. When you push an update to your Base application any previous dynamic feature is also updated and kept in sync.

Dynamic Delivery is now in Beta and is available for developers to start building and uploading to Google Play Console, but publishing is limited to the “Internal” and “Alpha” tracks, with support for “Production” rolling out over the coming months. You can find more information about Android App Bundle and Dynamic Delivery here.

Are you an app developer excited by the new Google I/O announcements? Apply to Credera today!

• Android
• App Bundle
• Google I/O
• Customer Engagement & Commerce