In 2018, Google introduced the Android App Bundle also known as AAB, which is a new publishing app format, delivers more enhanced benefits over another current most popular Android app format – APK (Android Application Package). The AAB offers a smaller app size, high installation rate, easy switching, customizable features, and so on.
Simultaneously, it allows adding multiple feature modules in the app project with the benefits of Play Feature Delivery (PFD). Furthermore, game developers with app bundle formate can use Play Asset Delivery to delivering large amounts of game assets with flexible delivery orders and high performance.
The Android AAB supported in Android Studio version 3.2 or above, Unity 2018.3, 2017.4.17, and Cocos Creator version 2.0.9 or above.
Google is Replacing APK with AAB:
By June 2021, Google made its mind to make AAB the default app package in place of Android Package or APK application format for the Android Apps on Google Play Store. Google believes that this change will bring more efficient working capabilities and faster-operating speed in applications and data delivery.
It means that starting in August of this year, all new and existing apps on Google Play Store must have the AAB format. Meanwhile, it’s not mandatory for the present apps with APK formate at the moment.
What’s changing in August 2021
If we talk about what changes are Google bringing in August 2021, we should look into the following:
- The APK format is replacing with the AAB on Google Play
- The Expansion files (OBBs) will replace with Play Asset Delivery (PAD) and Play Feature Delivery (PFD)
- The AAB will require the Instant app Zip for instant experience
These changes will be applied to the apps or files launching in the future. While the existing apps will remain the same as they before. After August 2021, the files with more than 150MB size can take the benefit of PAD & PFD with AAB format.
Android App Bundle: Benefit from a smaller App
It modifies the serve APKs and optimized them for different device configurations, which results in the smaller app sizes average of about 10% and 15% for universal APK.
Users will only download the used codes in the app with need resources and requirements for an individual device that made the faster downloading speeds with most installed and fewer uninstalls.
Manage releases more efficiently:
The AAB creates a single artifact that consists of all compiled codes, resources, and native libraries for a particular app. Thus, eliminates the need to build, sign, upload, and manage version codes for multiple APKs.
Play Asset Delivery:
This AAB exclusive feature reduces user waiting time and transmits large assets dynamically also reducing delivery costs. Games with Play Asset Delivery can have the benefits of texture compression format targeting. It allows a user to only get required assets suitable for their devices.
Customize Feature Delivery: Faster Build Times
It allows the Android Studio to build systems using Gradle, which are optimized for modular apps so they are significantly faster to build than large solid apps. It reduces the waiting, so developers can give more time to designing, coding, and testing the app.
Using the feature modules, improve build speed, engineering velocity and extensively customize app delivery with reduced app size. However, there are some constraints and edge cases we have to follow when using feature modules.
Google Play Instance Experience:
The AAB offers the Google Play Instant experience, and the bundle is known as an instant-enabled app bundle. This bundle presents the app set up, configure, build, test, and publish guides.
Issues with AAB: Google will have the most control
As I mentioned earlier, the AAB has about 15% reduced sizes than Apks, but as Google is just starting to initiate this, it has two major known issues. The first one is related to the app versions in different channels and the second one is related to the signing key.
The developers who are planning to launch their apps on other platforms or stores such as Amazon App Store and Huawei AppGallery have to manually transmit the APK version of that particular app. However, it’s not heavy work for a developer.
If a developer wants to submit his application on the Play Store only, it’s a good choice to have the AAB. But those end users who still want the APKs, have to look for alternative stores or do struggle in exporting AABs and it won’t support others for now.
This is the most concerning one as the developers have to provide the signing key of their apps to Google in order to export AAB files as an APK. Certainly, this action will give Google the supreme powers to access the core of the app.
Speaking of the app signing key, it works as authoritative power for a specific developer, which denotes the creation of a particular app. If someone else has the signing key, he can use it to command the app and gain the benefits as some developers aren’t sharp enough to manage the AAB format yet.
Most frequent queries about the Android App Bundles:
1 What are the working requirement to use and AAB comparing with APK?
Ans- The AAB is an open-source app format and provides supports for various development engines like Android Studio, Gradle, Bazel, Buck, Cocos Creator, Unity, Unreal Engine, and others. Furthermore, Play Core Native, Play Core Java, and Kotlin SDKs offer advanced app bundle features regardless of your selected coding conditions.
2 Why the OBBs don’t support AABs? Why the gaming apps use Play Asset Delivery?
Ans- The OBBs files are required for the additional features but they are saved in an app’s outer storage, which makes them insecure.
Furthermore, if you want a smoother publishing process and flexible delivery modes for your gaming apps, which are larger than 150 MB, you can publish them in AAB format on the Play Store, it’ll enable the Play Asset Delivery.
PAD provides more advantages than legacy augmentation files with the optimized delta patching helps in reducing the storage space in the device in comparison with OBBs.
Apparently, you’ll get higher install rates, texture compression format on ASTC supported devices, and can aim for the most extensive Android device range with comprehensive use of hardware and device storage.
3 Does AAB supports different app publishes platforms?
Ans- No, the AAB doesn’t support different publishing platforms. However, if a developer wants to submit his application to other platforms than Google Play Store there are many ways to do so.
The developer can use only one signing key on each platform or can use a unique one for each channel, including a different app signing key for Google Play Store.
The developer can use many approaches like he can either build artifacts for all distribution channels locally, can sign in for the artifact, and can download distribution APKs from Google Play to use it on other platforms.
The notable thing is, the distribution APKs can be downloaded from the app bundle explorer available in Play Console or using the Play Developer API. But they have to sign with the same app key in the Play App Signing.
4 Can I decide app signing key for my new app?
Ans- Yes, the Play Console offers to decide the app signing key. In addition, you can select any key recommended by Google as the app signing key. It helps in keeping a copy of your singing key provincially.
To be more clear, you can create signed versions for other distribution channels using the same key as the Play version. Furthermore, the Play Console is working to release an additional app, proving you the ability to chain the app signing key in case you made any mistake, but support it as long as you do it before you publish to an open track the first time.
5 How can I assures that my app has been delivered in the way I want?
Ans- The AAB offers you to download or inspect artifacts from the Play Store using the app bundle explorer anytime you want. You can use the Play Console or the Play Developer API to check or verify your app.
Furthermore, the code transparency for app bundles is a new feature used to examine running code on a device and verify it with the code basically built and signed by the developer. It’s an additional feature.
6 Can I use the Play App Signing key for my previously published app on the Play store even without granting the exciting app signing key copy?
Ans- At present, if you want to use the Play App Signing, you must provide a copy of your actual app signing key to Google Play, to sign and release updates to the present users. An estimated 1M apps are using play App Signing in production to date.
In the future, Google will also provide an extra feature in the existing apps Play App Signing by sending an update. This option will allow the Play App Signing to use the new and unique key for the upcoming installs and their further updates.
However, to enjoy this feature you have provided your actual APK signed key with your previous APK signed key while uploading an app bundle. It will allow Google Play to keep the updates regular for the present users.
7 Does the App signing key is changeable?
Ans- Yes, the app signing key is changeable and some apps can apply for a new app signing key in Play Console. Then Google Play will use your new key to sign new installs and upgrades. And the legacy app signing key will be used for signing up for users updates who have been already installed that application.
In addition, Google is working to add an APK Signature Scheme v3 key circumrotation feature in Play Consol forthwith. Afterward, the key upgrade can become a possible option for more apps and help apps signed with upgraded keys, which can be available for numerous users.
Future of AAB:
According to Android officials, over 1 million applications with top 1000 apps on Google Play Store such as Twitter, Netflix, Gameloft titles, Adobe, and Duolingo are using AABs. Google expects that this app distribution extension will grow more in the future.
All the new Android apps on the Google Play Store will need to be in AABs in the future. It’s assuredly a turning chapter for Android APKs, it’s bringing the advantages and disadvantages for the developers, but we have to wait for the implementation before reaching a conclusion.