When building Android apps, you’ll be facing a myriad of different file formats and terminology. Particularly when exporting the final version of your app, you’ll be seeing two main output formats. In this article, we’ll compare Android App Bundle versus APK, which are composed of DEX files. But what do all these acronyms mean?
Acronym meaning
Before digging deeper into the topics, it’s important to get the definition of each of the above-mentioned formats:
- AAB: Android App Bundle
- APK: Android App Package
- DEX: Dalvik EXecutable
APK: Android Application Package
Let’s begin by reviewing this format as it’s the one that’s most known and has been around for the longest time. As mentioned above, APK stands for Android App Package. An APK is basically a file that’s ready to be installed on a user’s device.
APKs have all of the app’s files and code inside. You can think of it as a .zip file but with its own particular extension. Just as you can find compressed files with extensions in .rar or .zip, you can have .apk. It’s mainly understood by the Android platform, but other platforms could support it if they had the same underlying architecture as Android does.
The APK is already signed with the app’s certificate, which is a file that identifies every app in the Play Store. This file has to be kept by the developers throughout the life of the app, as it’s not possible to generate it again.
AAB: Android Application Bundle
AAB, which stands for Android Application Bundle, is a more recent format for Android distribution. Android’s official documentation gives the following definition:
“An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.”
These application bundles are fairly new — they were introduced in Google I/O 2018. They’re about to get two years old. But ever since, they’ve become the official format for publishing Android apps.
Just as APK is an extension, AAB files also have the extension .aab. The Android documentation provides an image explaining how AABs are composed.
If you had an APK, you’d only have the orange part of the app, which will have inside of itself all the assets, meaning you can only have one pack of them and no dynamic features.
Asset Packs
Asset packs are groups of files targeted to a group of devices. When using a traditional APK, the app will receive all of the assets and just choose and use the ones that are necessary for that specific device.
On the other hand, when using AAB, the Play Store selects the assets that’ll be needed when the user downloads the app.
Dynamic Features
These features are modules that may not be needed on the first install of the app. You can either download them when the user requests to add that functionality or download the app and then start downloading them in the background to give the user a head start on using your app.
To install dynamic features, we have the SplitInstallManager that’ll be managed by the Play Core Library, which communicates directly to the Play Store.
Advantages of Android App Bundle vs. APK
Android stresses several disadvantages of using APKs:
- Lower conversion rates
- Slower downloads
- Higher uninstalls
- Lower update rates
Size
The first advantage is the size reduction. With asset packs and dynamic features, apps become, in average, 35% smaller. But some apps have gotten a decrease in size of around 50%.
After the introduction of AABs, the maximum size of an app is 150 MB. By using an APK, you can easily surpass this requirement.
Uncompressed native libraries
For some reason, when you have an APK, the app gets a copy of all the native libraries that are needed in a compressed format. After the download, the device decompresses those libraries by creating a copy because it can’t use them without decompression. In the end, you’ll have two copies of the library.
When comparing Android App Bundle versus the APK, you’ll notice the AAB gets uncompressed native libraries by default, which will help you avoid having two copies in the end.
You might be wondering why the APK keeps both a copy of the compressed version and another for the uncompressed. This, as the above-mentioned identifies, is because the libraries are sometimes device-specific. You may need a different one for each device, which the Play Store can send to the device on download time if you’re providing an AAB.
What About DEX Files?
Both APKs and AABs contain DEX files inside. Those files are the key to executing the code. These files are Dalvik EXecutable because inside the core of Android, there’s something called the Dalvik Virtual Machine. In simpler words, this VM executes the code of the apps in Android to make them available to you.
Pro tip: Error with DEX files
There’s a common error in Android Studio when building your project. This error is easy to fix but can be frustrating if you don’t know what it’s talking about. When trying to run the app, you’ll get a message like the following:
Cannot fit requested classes in a single dex file
If you’re also getting this error, go to build.gradle(Module: app), and inside the brackets of defaultConfig, add the following line:
multiDexEnabled true
Android Studio will request to sync the project, as it does every time you do a change in Gradle files. Do the Gradle sync, and run the app.
Conclusion
As you can see, comparing an Android App Bundle with an APK isn’t that complicated. App bundles have been around for almost two years, and they’re very useful to give users a better experience — so why not give them a try? I hope you add this to your next project.
Until next time!
