One of the things that’s long set Android apart from iOS is that while both Google and Apple maintain app stores, Google makes it fairly easy for users to install apps downloaded from sources other than the Google Play Store. It’s a process commonly known as sideloading.
But starting later this summer, sideloading some apps could get a little more complicated.
Up until a few years ago, when App Bundles were first introduced, installing an Android application meant downloading and installing a single APK (or .apk) file that contained all the code submitted by a developer… including code that you might not actually need for your device.
For example, if a developer’s app is designed to run on devices with ARM or x86 processors, you don’t necessarily need all the x86 code if you’re only installing it on your ARM-based phone. But it was probably included in the APK installer file anyway.
App Bundles are basically designed to let the Google Play Store separate out the components of an Android application into a set of “split APK” files, only delivering the ones you need for your device when you click the install button. That way you don’t end up downloading unnecessary code for display types, languages, or processor architecture.
The end result is generally a good thing for most Android users – you get smaller, faster downloads when installing apps through the Play Store.
But if you encounter an .aab file in the wild, you cannot just sideload it to your Android device using the same steps you’d use with an APK file. You can still install APK files, assuming the developer continues to provide complete APKs for their apps even after Google begins enforcing adoption of .aab for the Google Play Store.
But if developers only release .aab files moving forward, then there’s a chance that when you encounter APK files floating around the web, they may only contain some of the code necessary to install the full app on your device. They might not have support for your processor, language, or display for example if the APK was part of a larger bundle.
There are some third-party solutions that could make installation of App Bundles found outside the Play Store easier though.
While you can download APK files directly from APK Mirror and sideload them onto an Android phone, tablet, or other device, the team also has an app called APKMirror Installer that allows you to install regular APK files as well as app bundles packaged in the .apkm, .xapk, or .apks formats.
So you may need an app to sideload some Android apps moving forward. But not necessarily all Android apps.
Google is only requiring developers to use the new .aab format for new apps submitted to Google play starting in August, 2021. Developers with older apps have a choice of adopting the new format when delivering updates, or sticking with old school APK files. And many apps that may never have been available in the Play Store in the first place will likely continue to be available from other sources such as APKMirror and F-Droid as APK installers.
That said, Android App Bundles have been around since 2018, and Google says more than a million apps in the Google Play Store already use app bundles, including “the majority of the top 1,000 apps and games on Google Play.” So it seems likely that app bundles are here to stay.
If you only install apps from the Play Store, that’s probably not a bad thing. If you’re a regular sideloader, then you may want to check out APKMirror Installer or other third-party solutions that will help you install app bundles if and when you encounter them.
But there is one other issue related to Google’s push for .aab files to become the new standard for apps distributed via Google Play that is causing concern among some security experts: the way apps are signed (so that you can trust that the app you’re installing is the same as the one the developer distributed).
When a developer uploads an App Bundle to Google Play, Google will automatically generate the split APK files that will eventually be downloaded to user devices — and those APK files are signed by Google rather than by the developers who created them. And that means that there’s essentially a single point of failure – if Google’s servers are breached then it’s hypothetically possible that an attacker could obtain the private keys used to sign thousands of even millions of Android apps… which would allow them to pass off fake versions of those apps that look to Android devices as if they were authentic.
Sure, Google has a pretty strong vested interest in preventing data breaches. But as we’ve learned time and time again, no company is 100% immune.