As we inch closer to the stable Android 12 release, Google is making some foundational changes to app delivery and distribution on Android devices. From August 2021, all the new apps on the Play Store will be published in the Android App Bundles (.aab) format instead of the existing APK format. So what are the major differences between an APK and Android App Bundles (AAB)? Can we sideload AABs just like APKs? To answer all your questions, we have come up with this detailed guide on APK vs AAB. So without wasting any time, let’s dive right in.
APK vs AAB (Android App Bundles): A Comprehensive Comparison
Here, we have explained both AAB and APK formats in layman terms so that anyone can understand the concept with ease. We have also detailed how to install AAB files, extract APKs from AABs, and more. You can expand the table below to move to any relevant section quickly.
APK vs AAB: Understanding the Basics
First, we need to grasp some basics to properly understand what are the differences between an APK and an Android App Bundle.
APK has been the go-to distribution app package on Android since its inception. An APK primarily consists of app codes, heavy resources such as image, audio, etc., and an app signing key generated by the developer. Note that Android devices come in various form factors and specifications. For example, the devices can have a varying degree of screen density (320dpi, 480dpi, etc.), processor type (ARM, ARM64, x86), and more. Also, based on the user’s region, the app needs to have a language pack (en, fr, ger, etc.).
In an ideal situation, a developer has to build and upload multiple APKs on the Play Store based on the user’s region, processor type, and screen density. When a user taps on the “Install” button in the Play Store, the correct and most-suited APK is then installed on their device. However, all of this puts an enormous task in the developer’s hands. They not just have to develop apps but also manage multiple APKs to support a boatload of devices.
To avoid this complex and time-intensive work, most developers build a Universal APK that comes with all the resources (language packs, codes, and more) even though you may not require most of it on that specific device. This results in a bulky APK with a larger app size that requires longer installation time and eats up more bandwidth.
Google wants to solve this problem and shoulder most of this burden for developers with Android App Bundles (AAB). That, in turn, will help reduce the app size, installation time, and bandwidth consumption. The company introduced AAB at Google I/O 2018, and now, nearly two years later, Google is mandating that you need to submit new apps in the AAB format on the Play Store.
In comparison to APK, the AAB format is not a completely new distribution package. In fact, AAB is a container that hosts a base APK and multiple split-APKs. Basically, AAB is a publishing format that a developer submits to the Play Store while APK is the packaging format for Android apps that you install on your device.
So what really changes here? Starting August 2021, developers don’t have to handle and manage a whole bunch of APKs for a wide array of devices. With AAB, developers hand over everything to Google – the app code, assets, heavy resources, all language packs, and most importantly, the private app signing key. Now, Google can generate and serve optimized APKs to users based on their device’s configuration. It can create a much smaller AAB bundle, one that’s compact in size, installs in a jiffy, and eats lesser data for low-end devices. That’s the main proposition of AAB vs APK, but there is more to unpack.
The Sharing of Private Signing Key with Google
Looking at what AAB brings to the table, it seems like a great alternative to APK. The AAB format reduces the app size, and developers don’t have to build multiple APKs. However, many developers have expressed concern regarding the sharing of private signing key with Google.
As I mentioned above, the signing key is the most important information to verify the integrity of the APK. Even if you sideload an APK from a third-party source, the Google Play Store checks the signing key to ascertain that nothing has been tampered with.
With AAB, Google mandates that developers must share the private signing key so that Google can generate the app bundle and sign the AAB with the same private key. When users install the app or update to a new version, Play Services will match the signing key, and the installation will take place with no key mismatch or signature failure issues. With that said, developers say that it potentially opens the door for code injection. Google says that all “signing keys are stored on the same infrastructure that Google uses to store its own keys.” So rest assured, all of your private signing keys are guarded with ironclad security.
Moreover, to assuage developers’ concerns, Google announced Code Transparency that allows developers to generate a separate private key that will only be accessible by them. From the separate private key, developers can then create an extra signature that can be used to verify app integrity. However, there is a limitation to this method. Code Transparency only deals with the code and not with assets, resources, or manifest. Also, this is an optional feature that may leave many developers out of the loop.
Is AAB Going to Make Things Harder for Third-party App Stores?
Another issue arising out of sharing the private key with Google is that it might make things harder for third-party app stores. For example, if you install an app from the Play Store but want to update to the latest version from another Play Store alternative (say the Amazon App Store or Aptoide Store), then the installation might fail due to a signature mismatch.
It is because Google is now managing the private signing key, so you can’t use the same key while uploading your app to a third-party Android app store. You will have to use another private key, and that will cause the private key mismatch error. Will this be a problem for Android app support on Windows 11? We will have to wait and find out.
Other than that, the presumption that AAB will hinder developers from uploading APKs to third-party app stores appears incorrect. Google has already made an open-source tool called bundletool that allows developers to create APKs from AAB bundles. The only issue, for now, is the sharing of the private signing key will affect Android power users.
Can We Sideload AABs Just Like APKs?
From what we know, it seems like sideloading AABs on Android devices will be possible, but it will not be as convenient as sideloading APKs. Android’s package installer currently does not support AAB packaging format, meaning on-device AAB installation won’t be possible natively. However, you can use third-party installer apps to install an AAB package on-device.
For example, currently, APKMirror Installer (Free, offers in-app purchase) allows you to install APKM bundles (Base APK + Split APKs) with its installer app. We already have a detailed guide on how to install Android App Bundles on your phone, so check out the linked article.
Apart from that, you won’t be able to adb sideload your way into installing AABs. You will have to use the open-source bundletool to get the correct APK that’s compatible with your device. As AABs become more mainstream, new and convenient methods of sideloading might come up. Keep in mind, just sideloading the Base APK will crash on your device.
APK vs AAB: Advantages and Disadvantages
After going through all the points, you can tell that AABs won’t make much difference in terms of user experience for most users. Yes, it will reduce the app size, which will be helpful for most users. For instance – Airbnb reduced its app size by 22% after switching from APK to AAB, whereas Netflix toned down its app size by 57%. That is a considerable difference in app size. Apart from that, the abandoned Instant app feature will get a new lease of life with AAB on Android devices.
However, for power users who want to sideload AABs, things will become a bit tricky and inconvenient. You may have to use bundletool to extract APKs for your device or use a third-party installer. One thing to note is that AAB will move away from OBB (Opaque binary blob) to download large assets and resources. Instead, it will use Play Asset Delivery or Play Feature Delivery to download heavy resources with a download size of 150MB or higher. We will have to see how that affects sideloading games like Battlegrounds Mobile India, PUBG Mobile, FAU-G, and more.
As for developers most affected by this change, they don’t need to refactor their code, which is great. AABs also bring modularity in tow, meaning they can change a code snippet and merge it with the core base without facing many merging conflicts. One big advantage of AAB is that it brings customization options to developers. They can choose which API level to target or which device type to support. Developers can also decide what all features to deliver on a specific device type or smartphones running on a minimum SDK version.
As for the disadvantages, the heart of the issue is sharing the private key, which will now be managed by Google. Incompatibility with third-party app stores might be another big issue, and the developers will have to go an extra mile to publish and manage APKs (just like the Play Store right now) on other app stores.
APK vs AAB (Android App Bundles): What Do You Think?
For me, the biggest issue with this change is the over-reliance on Google. With this change, the Mountain View giant is making sure that Play Store remains the de-facto app store on Android devices. From hosting apps to managing private keys, Google now controls all aspects of app publishing and distribution on Android. Developers might be happy with the new changes as they no longer have to manage multiple APKs, but how will it fare for the users in the long run? We don’t know yet. With developers handing over control to Google, will it bring about a good change? We will have to wait and see. Anyway, that is all from us. But do tell us what you think about this APK vs AAB debate in the comment section below.
