What you need to know about Android App Bundles

Publish date: 2023-05-27

Back in 2018, Google introduced a new way to upload apps into Google Play: the Android App Bundle. Fast forward to August 2021, and it's now a requirement that all new applications submitted to Google use the format.

Unless you're a developer, you probably won't see any changes. We'll talk about how everything works and discuss the pros and cons of the move, but really there is nothing lost or gained for most users of the best Android phones. "Most" being the key word here — if you're on a data plan with a low cap or have a very slow connection, you will have slightly smaller downloads when you install an app.

Smaller downloads and shorter download times are great when they make a difference, so that's good to hear. Let's take a look at everything you need to know about Android App bundles.

What is the .aab format?

The extension .aab stands for (you guessed it) Android App Bundle and is much shorter to type and read, so we'll be referencing them using this name.

If you like to monkey around with the system files on your phone or sideload apps from outside the Google Play store, you probably already know that Android apps use the .apk file format. They still do, but it might not have been uploaded that way if you installed the app through the Play store. Back in May of 2018 Google introduced the .aab format, and thousands of very popular apps are already using it, including major developers like Adobe and Gameloft.

App Bundles are designed to give you what you need to run an Android app and not anything extra.

APK files are designed to bundle everything a device needs to run an app into one package that you can install. If you look inside an .apk file, though, you'll find that there is often a lot of stuff you don't need to run the app in there, too. For example, an English speaker installing an app on a smartphone needs different app assets than a Spanish speaker installing the same app on a tablet. But a typical .apk file has both sets of assets (and a lot more) inside of it anyway because it had no idea what parts you'll need when it was created.

That's what the .abb file format solves, at least on the surface. Once a developer is finished writing and testing their app, they can package it up into a big file that contains everything needed to run on every device in every region the developer supports. This file is then uploaded to Google Play, where Google can turn it into an app that only has the assets and files you need to run the app on your device. Of course, this app is still in the "regular" .apk format, and you would never know there was anything different about the way it was uploaded if you didn't read about it on the internet.

App Bundles save on bandwidth costs for users and Google itself.

This can shave hundreds of Mb off of the file size. Of course, a hundred Mb here or there doesn't make much of a difference for most of us because our phone plans give us a lot of data and are very fast, or we're using Wi-Fi to install apps. It can matter greatly for those limited data plans however, and either way, saving download time is never a bad thing.

For Google, which serves a lot of apps to a lot of users every day, it makes a huge difference. Multiply 150Mb times 1,000,000 users, then multiply that number by 365. That amount of bandwidth makes a difference to any company — even Google.

The move to the .aab format doesn't hurt the end-user and saves Google a ton of money. But there are a couple of other things that need to be mentioned that aren't so good about it.

Built in the cloud

For an app to run on your Android phone, it needs to have been digitally signed by the developer who created it. This signature is checked whenever you run the app or when you try to update the app, and if things don't check out, you can't run it or update it.

Because .abb packages are turned into installable .apk files in the cloud, the signing is done by Google. That means the Developer needs to let Google assign a key when the app is created through developer software, or the developer needs to provide Google with their signing key.

Signing keys are a critical piece of app security, and before the idea of .abb packages arose, developers were told to never let them out of their possession because it could allow someone else to impersonate them as far as the app was concerned. So if you have my signing key, you can make a malicious update to my app, and nobody would be the wiser.

The possibility that some rogue actor can breach the Play store and sign malware using the right keys is very unlikely, but it does give Google a little more control than it had before. Developers, however, are rightfully concerned about this. Google's response has been to provide a code transparency system where a developer can include some code in their app, which is later used to check that the app generated by Google matches what they uploaded.

People are also concerned that only Google Play supports apps in the .abb format and third-party app stores face another uphill battle when it comes to adoption. To fix this, Google has made it so that a developer can download an .apk of their app signed with the correct key through the Google Play Developer Console at any time, even if the app is unpublished.

We should be concerned about the amount of control Google has over Android. However, the fact remains that most users are completely happy with it.

While we should be concerned about the amount of control Google has over Android, the fact remains that most users are completely happy with it. The move to the Android App Bundle does give Google a bit more control, but it also makes for smaller downloads that save all parties both time and money. Other companies are able to adopt the .abb file format, and Amazon has done just that (opens in new tab).

Unless you're a developer, there's really not anything to be concerned about outside of Google getting a slight advantage over its Android competition in the end.

ncG1vNJzZmivp6x7orrDq6ainJOau7W%2BwKVlnKedZMSprdNmsKitXaOyprCMpKWor12Wr7DB02aYp5yipLalecCpp2aapaOxrbHS