Is Google Play’s APK Replacement an Unnecessarily Evil?

The Google Play Store underwent a massive transformation in August 2021 when Google replaced the age-old APKs with Android App Bundles or AABs. Regular users may have not noticed this transformation but developers have voiced their concerns about AABs.

So, what’s the buzz around AAB’s security risks, and should you be worried?

Let’s find out by comparing AAB’s perks against its counterpart and reviewing all its downsides. But before we begin, here is a quick introduction to the legacy Android application format — APK.

What is an APK?

APKs have been a constant since the beginning of Android to a point where they are synonymous with the term “Android application.” An APK or Android Package Kit is a way of packing all the necessary data that your smartphone needs to run a program in a single package. Generally speaking, it is not very different from a ZIP or RAR in terms of functionality. APKs are Google’s way of ensuring a consistent app packing format throughout the ecosystem.

Why is that important, you may ask? That’s how Google enforces its uniform security norms across all app installations that take place on any smartphone running any Android version that has ever existed. For this, Google uses a clever technique involving unique app signing and private keys. These private keys are a huge part of all the controversy surrounding AABs.

A major flaw in APK

Android has witnessed enormous growth in the past decade due to its customizability and open-source nature. This massive surge in Android-run smartphones had led to zillions of different combinations of screen resolution, CPU architecture, and preferred languages.

The Google Play Store earlier mandated the app developers on its platform to add tailor-made resources for all significant screen resolution and CPU architecture combinations in a single APK. As you might have guessed, every APK had a substantial chunk of files that had nothing to do with your smartphone.

Instead, every application had a universal APK (for a specific version) that contained files for all the devices to which the manufacturer wanted to cater. As a result, you could share the same APK file to any device with entirely different specifications from your own and could still have the application installed. While the storage issue might not seem like a problem for flagship devices, this can massively clog the storage on low-end devices with little storage.

How is AAB better?

Android App Bundles or AABs are an innovative way of making app packages smaller and lighter on system resources. These app bundles contain resources for all the screen resolution, CPU, and language combinations just like an APK does, but there’s a difference; AABs don’t ever end up on the user’s device.

AABs massively reduce the burden on low-end devices.

Instead, Google uses AABs to deduce the perfect combination of system resources for your device and then combines everything inside a device-specific package. In fact, the final package that ends up on your device after you download an app from the Play Store is still an APK. These device-specific APKs are significantly smaller in size and can massively reduce the burden on system resources on low-end devices. All new apps uploaded after August 2021 on the Play Store need to use Android App Bundles. Older apps, however, have the option to opt for AAB or function as usual.

Moreover, AABs take up less bandwidth while downloading from the Play Store. Google even mandates App Bundles to be smaller than 150 MB no matter how extensive the app is. Android does it through another fabulous Play Store offering, aka the Play Asset Delivery.

If you remember playing any large games on Android, you must be aware of the OBB files. OBBs were the legacy expansion files that allowed developers to push relevant data not stored in the APK file. OBBs generally contained large resources such as media and program assets. Google has now replaced the OBB file system with the new Play Asset Delivery. This latest offering has features like flexible delivery modes, better compression, auto-updates, delta patching, and a lot more.

PAD (Play Asset Delivery) uses asset packs that contain critical assets for an app, such as textures, shaders, sounds, etc. PAD combined with Dynamic Delivery lets developers push customized updates according to three delivery modes; install-time, fast-follow, and on-demand.

So, what’s the criticism about if everything is so perfect with AABs? To answer this, we need to understand how Android app verification works during an installation. You can skip this part if you know how Signatures, App Signing, and Private Keys work.

How does Android app verification work?

Android uses an app’s signature to verify its legitimacy during an installation. Signing an app is compulsory for all app developers before making it available to the users. The signing process needs two elements; the private key and the signature. Every Android developer has a private key that they use to publish any app under their name. Google, however, generates the app signatures using these private keys.

Not to mention, Google uses sophisticated cryptography to ensure these signatures take forever to decrypt. The app signing process helps Google verify the developer’s identity that published the application. It also makes sure that the app has not been tampered with in any way after getting signed.

The app signing process is crucial from a developer’s point of view, as well as it ensures that only the developer can publish apps under their name. As you might have guessed till now, private keys play a crucial role in app verification and must not get leaked under any circumstances.

The App Signing Process in the APK era

Signing an app in the APK era was significantly different from what exists today. As mentioned above, the private keys remained safe with the developers, and Google created app signatures, aka public keys, using the private keys. The developers needed to manually sign each application (using the Android Studio) before uploading it to the Play Store.

The bottom line here is that Google did not store any private keys in the APK era, and the developers were entitled to create their own signatures. The only place that needed blind trust was the signature creation process. A developer had no say in the cryptography behind creating the signatures.

The App Signing Process in the AAB era

As mentioned above, Google creates different APKs from the same AAB file and distributes them to users according to their device type. Certainly, Google creates numerous APKs for all the different screen, CPU, and language combinations, and all of them require signing. One way of doing this could be returning the newly created APKs to the developers and asking them to sign them for themselves. While this would certainly need some labor from the developers, manually signing an app would have been a major trust builder.

Google, however, uses a different route; it either asks the developers for their private keys or creates a new key itself. It is the first time when the tech giant has shown the intention of storing the developer’s private keys or taking control of the app signing process. A noteworthy feature of the new signing method is that developers can now recover their private keys if they are lost. Recovering your private keys was impossible in the previous signing process as Google did not store the private keys in its database.

AAB’s criticism

Android App Bundles have some fantastic features, but they are a massive change to the previous system. Let’s check out a few points that AAB critics point out and know if they actually hold true.

AABs stop sideloading

Sideloading apps was simple in the APK era; you could Google search the apps name, click on the first link you find, and install the application. The app should almost certainly get installed unless it is tampered with by a third party. In the AAB era, developers upload AABs to Google Play, and Google then handles the process of creating APKs using it.

Third-party app stores won’t have access to the developer’s public keys, and hence they won’t be able to create APKs for you but, that’s not the entire story. Third-party app hostings can still let you download their versions of the app bundles. For instance, APKMirror pushes .apkm files on your device when you download an application using Android App Bundles. You can still install these .apkm files using a third-party APKM installer. The bottom line here is that you can still sideload apps but with some extra hackery.

AABs would restrict other App Stores

Critics were initially skeptical about the downfall of third-party app stores with the advent of AAB. They believed that developers might need to create separate private keys for each app store other than the Play Store. This could have led to private key mismatch errors, but this was a complete hoax. After witnessing AABs for quite some time, it is safe to say that third-party app stores have had no problems coping with the new system.

Google even offers an open-source tool, viz. bundletool, that lets developers create APKs from the AAB files. Developers can then upload these APKs to third-party stores and functions usually.

Scope for Code Injection

It’s the first time Google stores and uses the developer’s private keys to sign the applications. Critics go on to say that the tech giant may use these app signatures and tamper with the code for some popular apps. While the idea looks pretty tempting as Google can gain outrageously large data points on its users injecting their adware into apps, this idea is yet another hoax.

Code injection is indeed a possibility with AABs, but Google will land into serious trouble if it tampers any app on its Play Store. Developers can always download, inspect the APK version that Google pushes onto its users and look for any code alterations using the Code Transparency feature. For those who don’t know, Google’s Code Transparency feature lets developers monitor the code inside the split APKs and check for any alterations. The developer needs to create a separate key to perform the verification, and the feature is currently optional.

Facing immense scrutiny worldwide, Google would not want to book any more problems doing something as unethical as adding adware behind the curtains. You may argue that the APK system was still better as it had no scope for code injection. Code injection may sound theoretically sound, but tampering with code seems like a farfetched idea even when it is possible with AABs.

Sharing Private Keys with Google seems spooky

Google requires all developers using AABs to share their private keys with Google. In the APK era, developers were solely responsible for handling their private keys and keeping them confidential at all costs. These private keys were never stored on any database in mass numbers, but that’s not the case with AABs.

Google stores the developer’s private keys in its own databases and uses them to sign applications. Not to mention, the database must be a highly secure one with numerous security norms in place. Even with the best security in place, no database is utterly immune to intruders. In the previous system, any hacker had to gain the private keys from a developer and then use them to modify the codes of that specific application. Modifying apps on a large scale was almost impossible as the private keys were kept at discrete locations and with different levels of security depending on the developer.

Google has now brought each of these private keys to one place and stored it in a digital vault. This vault will certainly attract hackers worldwide as the private keys inside it can spread mayhem if unleashed. For starters, hackers can modify the contents of any popular apps used by millions of people around the world and create a digital emergency.

On the flip side, developers do have the privilege of retrieving their private keys if they are anyhow lost. Losing the private keys was the end of the discussion in the previous system, and developers had to start from scratch.

So, is sharing private keys and letting Google create a database a good idea? The answer to this question depends on how much you trust the tech giant. Google may have an extremely secure vault to store private keys, but it has had data breaches in the past, and the Google+ data breach still remains fresh in the memories of its users. On the other hand, retrieving your private keys is a massive perk too. We suggest our readers weigh these points and decide what’s better for them.

AAB from a developer’s perspective

Uploading an AAB file is not very different than uploading an APK file, given you are a new developer trying to upload a newly made application. Budding developers should not have any problems using AABs, and the critical retrieval features make AABs even more tempting. Being able to use the Play Asset Delivery for customizable updates is another good reason to like AABs.

However, the story is slightly different for seasoned developers using APKs for a while. Google doesn’t mandate existing developers to use AABs, and some developers have chosen to stick with the APK system of app delivery. On the flip side, developers like Netflix have slashed their app sizes by 57% after making the switch. Moreover, using modern features like Play Asset Delivery is only possible using AABs.

How to sideload AABs on your Android Devices?

As mentioned above, AAB is a collection of all the resources, and Google creates a split APK tailored for your device. Directly installing AABs needs finding your way around a few problems; you will have to download the AAB file, which is not available readily, you will then have to find an installer that supports AABs.

To tackle the first problem, we need to find a source for AAB files. Currently, there is no centralized repository for AABs; hence third-party hosting sites like APK Mirror are the only rescue. Note that APK Mirror uses a different file format for app bundles, i.e., APKM.

Once you download an app bundle from APK Mirror, you have two ways of installing an application. You can use the APKM Installer from APK Mirror, which will automatically create an APK for your smartphone and install it without asking for additional information. The other way involves using Split APK Installer that lets you customize APKs from the app bundles.

Method 1: Using APKM Installer

APK Mirror offers its own APKM Installer that lets you install .apkm with ease. Follow the steps below to install the .apkm file:

• Once you have got your APKM file downloaded to your device, you can proceed with the installation. Open the APKM Installer application.
• Select the “Browse Files” option and select the app bundle you want to install.
• Click the “Install App” option present at the bottom of the screen.
• APKM Installer will redirect you to the Android Package Installer UI. Press the Install option. Your application should get Installed on your device.

Method 2: Using Split APK Installer (SAI)

The Split APK Installer lets you install multiple app formats like .xapk, .apks, and .apkm. Follow the steps below to install app bundles through SAI:

• Install the Split APK installer from the Play Store.
• Open the app and browse the app bundle you want to install.
• SAI should automatically detect the best app version for your device. You can, however, choose the customize the APK as per your wish.
• Finally, click “Install” when you are satisfied with the APK settings.
• SAI will redirect you to the Android Package Installer. Click “Install” in the Package Installer. Your application should get installed on your device.

Conclusion

It is evident that the APK system of app delivery had some flaws, and AABs seems to be a gracious replacement. The above article looks at various benefits and points of criticism of the AAB system. While AAB’s benefits are undoubtedly attention-grabbing, you cannot deny the potential privacy risks involved in storing numerous private keys in a database.

The entire AAB system could be better off if Google just asked developers to sign the split APKs themselves and reupload them, but that’s not the case. However, with all its direct and indirect benefits, AAB seems like the most logical step forward in the app distribution business.

---

To read more from our blog, click here.

You can keep up with all that’s happening within the app world by following us on Twitter, Instagram, Linkedin, and Facebook.