Main Website

Android Application Bundles – A complete guide to AAB files

The world of mobile apps is always in a state of flux. New changes continue to transform the way people go about developing and launching mobile apps.

These changes are often imperceptible on the user side. How many users feel the process of downloading an Android app from the Google Play Store has changed in the past five years?

Many Android users would say the process remains the same. However, things have changed in the background. In the background, the process of downloading an Android app from the Play Store has been changed with the arrival of AAB files.

What are AAB files?

AABs (short for Android app bundles) are a type of Android file used to publish and distribute Android apps. They are now the standard file format used to publish Android apps on the Google Play Store. Their arrival marks the ebb of APK files which were used earlier to publish apps on the Play Store.

According to Google’s very own guidelines, AABs will become the only file format new apps can use to get published on the Play Store from the second half of 2021.

This marks a drastic change in the process of Android app publication. Many apps have already switched over to AABs thanks to the many advantages it brings along.

The following sections will provide a lot of insights on the need for AABs.

The size question

Apps are getting better, and bigger.

We couldn’t play the type of mobile games we play today ten years back. Besides the obvious graphical and performance-related challenges, most devices couldn’t support large apps.

Improvement in device performance and storage has encouraged developers to create feature and function-rich apps. From a game developer to someone using a DIY builder to convert WooCommerce site to mobile app, everyone wants to provide a whole variety of functions and features.

This desire comes at a cost.

A single app today has to cater to a range of different devices. Thus, developers have to create separate resources to make an app work on low-end, middling, and high-end devices. This need to cater to different devices naturally mandates developers to create more app resources. More app resources directly equates to larger app sizes.

One would think users wouldn’t mind large app sizes. After all, increase in storage capacity should naturally allay fears about big apps.

Right?

Look at the chart below.

App install rate vs app size

Despite an increase in storage capacity of smartphones, users are not open to installing large apps.

A trend like this naturally forces developers to compromise and cut down file size. This also means cutting down features and functions that can set the app apart in the market.

This is where the arrival of AABs helps.

How do AABs help compress the size of mobile apps?

Developers naturally need to build up a lot of resources to ensure their app performs well on a range of devices. This is the major cause for large APK files.

The main idea behind AABs is this – what if developers could upload several app resources to Google Play? Google Play could then selectively choose the resources needed for each app download. This would cut down on the size of Android apps as Google Play would selectively provide the resources needed for an app to work on a particular device.

Here’s how the process works –

  • Developers create an AAB build of their app when working on IDE like Android Studio or Unity. Those using a mobile app builder can simply download their app in AAB format.
  • Upon uploading the AAB file, Google Play will divide it into various split APKs. Each split APK basically refers to a version of the app built to work in a specific device configuration and language. For example, Google Play would create separate APKs for a Moto E device and Nexus 5 device.
  • When a Moto E user presses the install button on the app listing page, Google Play would specifically download the Moto E split APK.
  • Similarly, a different split APK will be downloaded on other devices based on their device configuration and language.
  • A Moto E user won’t need to download the app resources of a Nexus 5 user. The same is true for all other Android devices.
  • Thus, the size will be reduced dramatically as only necessary files will be sent through the pipeline by Google Play.
  • If your user later changes the languages and needs other resources, Google Play would dynamically send those files to the device.
  • Each split APK is signed with the same key as the main app bundle. Google Play thus automatically recognizes each APK as the same app.

AABs basically enables developers to not compromise on the features and functions they build. The growing diversity of Android devices in size and performance necessitates the use of AABs.

Contrary to popular belief, AABs don’t supplant APKs from the app development cycle. Instead, AABs create a better framework for APKs to function in. For testing purposes, developers still have to use APK files as they’re the only way to download an app on an Android device. However, the publication of apps on the Google Play Store is now best served with AAB files.

The contents of an AAB file

The contents of an AAB file are not very different from that of an APK file. The main difference comes down to the organization of different resources.

AAB file contents

The following sections discuss the different contents of an AAB file-

  • base/ – The base module is home to various other sub-directories that contain the resources needed to make an app work. Each split APK later gets its own base folder which contains several sub-directories.
  • feature/ – The feature folders contains resources for the various functions of an app which are called upon dynamically. Each split APK has its own set of dynamic features which work within the device configuration it is tailored for.
  • asset_pack/ – Asset packs remain outside the base/ folder in the AAB. They generally contain all the resources which are needed to trigger specific parts of an app. These asset packs are stored with Google Play and dynamically called upon whenever needed.
  • Module Protocol Buffer files – Each .pb file provides meta information about each module to the Google Play Store. Each folder has its own dedicated protocol buffer (.pb) file.
  • BUNDLE-METADATA/ – This file provides important meta information to app stores regarding the contents of the app bundle. This file is not transported to any split APK later.
  • res/ – The res folder contains resources to load an app across device configurations. It contains information about loading the app in different device configurations. These different configurations can include variance in OS versions, screen resolution, and language.
  • lib/ – The lib directory contains a range of resources to load the app on different processors.
  • assets/ – The assets directory contain files for various resources such as sounds, textures, license files, and so on.
  • dex/ – The dex directory contains different dex files for each module of the APK. Unlike APKs, all dex files are stored in this separate directory.
  • manifest/ – In APKs, there was a single manifest file covering all the contents of an APK. An AAB has an entire manifest folder which contains different files detailing the contents of each module.
  • root/ – All the resources in the root directory of your AAB and later sent to the root directory of the base APK.  The root directory cannot include other resources like lib/ or dex/ because they’re kept in separate directories.

How can AABs help those using app builders?

People using app builders are often not familiar with the various technical vagaries of the mobile app world. The entire point of using DIY-app builders is committing to a non-technical path to app development.

This doesn’t mean the app world stops evolving. Despite committing to a non-technical path to app development, the users banking on app builders should respond to technical upgradation which suits their interests.

Leveraging AABs has a lot of advantages. Some of them include –

  • Lower app size – AAB builds are much smaller than APK files. This naturally has a lot of knock on advantages such as reduction in app churn and storage efficiency.
  • Install the essentials – Split APKs created from the main AAB files ensure that users only install the resources they need.
  • App churn management – Low size ensures users do not stop during installation or uninstall the app later because of storage issues.
  • Dynamic support – Some features are called upon dynamically from the Play Store when they’re needed. This reduces load on device storage.

Those using AppMySite to turn WordPress website to Android app don’t have to worry about the process of creating an AAB build. There is an option on the platform to generate AAB builds for Android apps. Thus, AppMySite users don’t have to worry about creating AAB files for submission to Google Play.

In conclusion

AABs are now a key part of the Android ecosystem. From the second half of 2021, all new apps will have to be submitted with AAB builds to the Google Play Store. The future of Android app submission for the foreseeable future lies in AAB files.

This piece provides an in-depth analysis about the various aspects of AAB files. The early sections cover the need for AAB files. The contents of a typical AAB file are covered in detail as well. The final section offers insights to those using an online app builder on the advantages of using AABs for Android app submission.

Related Articles