What is an AAB file for Android and how is it different from APK?
It looks like AAB is here to stay, with Google doing away with APK files. Beginning August 2021, developers will have to upload new Android apps to the Google Play Store in AAB format. Since the launch of Android over a decade ago, APK files have been THE universal format for apps. Whether developers or users, whether it is on the Google Play Store, APKMirror, or EFNet - it was always APKs that were offered. For developers, AABs will now become mandatory and for Android users, APKs will become a more complicated affair. AABs will become mandatory for all new apps starting August 2021. Updates for existing apps can still be uploaded by developers in APK format, so nothing will change in this department for now. "AAB" stands for Android App Bundle. The AAB file contains the entire program code of the Android app. As soon as development is complete, the developer uploads the app to the Google Play Store in AAB format, with the user (you) downloading it from there to your smartphone as usual. At first glance, nothing changes. In fact, upon closer inspection, it really does seem as though there is no difference at all. This is because when you click "Install" in the Google Play Store, your smartphone will still download an APK file. AAB files are custom-made  The difference between APK and AAB files lies in what we call resources. In an app, resources are everything else that is not programming code, such as images, language files, or music. If you select the "Install" button for an app in the Play Store, Google will then send you an APK file tailored from the AAB file for your device with the necessary resources required. In the future (right), the downloaded APK file will only contain resources that the respective device needs. Then you'll receive an APK without 4K material. You probably won't need the Swahili language pack. By the way, with the help of Google's bundletool tool, AAB files can also be locally converted into APKs. Signing by Google instead of the developer  Another big difference is in the signing of the apps. Previously, it was always the developer of an app who signed it with their developer key. This key can be used when installing the app on a smartphone to check whether it has been compromised and, for instance, contains malware, or whether it has been unlocked for features that would otherwise have required payment. This is how it used to work: the developer signed the app with their key, uploaded the app, and Google delivered it. Now the key is held by Google /  Google  In the future, it will not be the developer who signs the APKs, but Google - namely when generating APK files from the AABs. Logically, the keys will no longer be held by the developers, but by Google. Smaller file sizes than APKs  The first major advantage of AAB files is therefore obvious: The APKs generated in this manner are smaller. On average, you should be able to see a 35 percent reduction in this manner, based on what Google wrote in October 2018. That doesn't sound like much at first glance, but when one includes the numerous updates for apps, it could add up at some point. Better protection for apps  Another benefit that developers will find useful would be increased security. It will probably be more difficult to modify apps in the future, and the mod scene might not be very happy about that. Who knows, maybe this will reduce the number of cheaters at AmongUs, even if I don't really believe that it is commonplace so far. By the way, with the AABs, the Lite and Pro app versions in the Play Store should no longer exist. It used to be possible to install a paid Pro version over the Lite version after a purchase thanks to the same signature, so to speak, as an update. With AABs and Google signing, that's no longer possible. Instead, developers will have to switch to in-app purchases. Depending on the device, Google includes only the necessary components in the APK file. Due to the lack of x86 architecture, the Pixel 2 XL can do without the corresponding modules. /  Google  Easier updates & development  If the APKs are individually assembled depending on the user or its hardware, this brings additional advantages for the developers. As NDTV reported, thanks to the AAB format, updates can be pushed out to specific devices at specific times. This is an advantage, especially with the enormous fragmentation of Android and could prevent broken updates in the future or mitigate their effects. The development process itself will also become easier. In the past, many developers uploaded multiple APK versions for their app to the Play Store, which have been adapted to different regions, languages, or processor architectures. In the future, developers will only need to upload a single, universal AAB file. AAB files and the sideloading confusion  However, there are downsides to AABs, especially due to the previously mentioned signatures. Forget about it, because APKMirror uses a different signature here than the Google Play Store. Sideloading apps across different third-party app stores could be a nightmare in the future. Hello, Windows 11 with APK and no AAB support. Sure, you can just uninstall the app and reinstall it on your smartphone from another source. But then you'll have to - with more or less effort, depending on the app - back up all your data and then re-install it. Microsoft has just announced APK support for Windows 11 /  Microsoft  AAB gives more power to Google  The fact that in future the signatures will be stored by Google can also be viewed through a critical lens. If the servers were to be hacked, all apps would end up compromised in one fell swoop. And as XDA-Developers explained: Google also has the power to change apps on its own through the developer keys. Theoretically, if a government were to place pressure on Google, they could build a backdoor into an otherwise secure instant messaging app without the developers' knowledge. Yes, Google cares enormously about security. And yes, Google would rather pull out of a market than bow to the morally dubious wishes of governments. But this remains a fact: Google simply obtains more power with the introduction of AAB files. There's also an interesting discussion on this topic on StackOverFlow which you can follow if you are interested in knowing more. Bug fixing becomes more difficult  Another disadvantage concerns the app developers themselves and the fixing of bugs, as developer Mark Murphy wrote at Commonsware. If a single user has problems with an app that is not reproducible for the developer, there used to be a simple remedy: modify the app, send it to the user, let the user update the app and hope that the error is removed. But that was only possible because developers could sign the apps themselves. On Medium.com, by the way, Android Developer Advocate Wojtek Kaliciski commented on many of the above criticisms and more. The bottom line is, mandatory AAB files shouldn't change much for most users, otherwise, we would have noticed something about it already. After all, a large portion of the top 1,000 apps in the Google Play Store are already uploaded as AAB by their developers even though there has been no requirement to do so at all. But for geeks, hobbyists, and the odd developer, the AAB format might spoil the fun of Android. After all, Google isn't Apple, and it's still possible to certify apps outside of the Play Store. Google has not yet put a stop to sideloading (for now). It does seem that Mountain View is working hard to cement the monopolistic position of the Google Play Store though.