How to protect Android App Bundles with DexProtector

A defining characteristic of the modern consumer is impatience. We don’t like to wait very long for things these days.

It’s as if a decade or so using social media and the smartphone has recalibrated our brains.

A few years ago, commentators were writing about a desire for instant gratification. But nowadays this is more of an expectation than a desire.

After all, you can listen to that album you’ve just read about right away on Spotify. You can binge an entire season of your favorite show in a single weekend on Netflix. You can even find a date in seconds by swiping a few times on a screen.

And more often than not, this expectation is realized. That’s largely thanks to the Play Feature Delivery service enabled by Android App Bundles (AAB). This feature delivers optimized code and resources tailored to an individual user’s request and specific to their device configuration.

In other words, the end user receives on-demand modules. If there are parts of an app that aren’t relevant to their device, then these won’t be present on it. This in turn reduces the size of the download.

In this article we’ll explore how it works from a developer’s point of view. And we’ll explain how to use DexProtector to keep your AABs safe from bad actors.

Speaking of the Play Feature Delivery, app publishers will be required to use it to deliver assets or features that exceed a download size of 150MB from August of this year. They’ll also have to use Android App Bundles format from the same month to upload any new apps and games.

So, with a little over half a year remaining until this deadline, it seems like a good time to step back and understand what led Google to decide to launch Android App Bundles in the first place.

Well, firstly they saw how larger-sized apps tended to be disadvantaged. They had lower conversion rates, they suffered from slower downloads, people uninstalled them more frequently (often to save space on their phones), and they had lower update rates.

Coming up with a way to reduce the size of apps, then, had some pretty clear benefits. As did delivering an app people expected. An app that worked well and had good UX.

Of the millions of Android devices in the world, there’s huge variety in manufacturers, vendors, and OS in use. Delivering unique-to-device (or OS) APK files meant that the app would be optimized. Publishers would be able to cover all bases.

If you had a Samsung S11 running the latest version of Android, there was an APK for you. But there was also one for someone with a Huawei phone made several years earlier and running a much older version of Android.

Before Android App Bundles arrived, developers would achieve this by using a splits block to create APKs for specific device processor architectures, screen resolutions, and so on. But this was a complex process. And it didn’t provide a uniform way to solve the problem of Android’s massive fragmentation.

AABs provide a solution to this complexity. Compared to the split-APK process, it’s a much more streamlined process.

They come with all of Google’s knowledge about the architecture, libraries, and screen size of specific devices. That means that developers can be sure that the AAB will quickly deliver the most optimized version of an app to their end user.

It even enables end users to get an app even more quickly if they’re only interested in using one specific feature of that app.

Another benefit of AABs relates to Google Play signing. Instead of having to sign each individual APK, you only have to sign the bundle before it’s uploaded to the store.

But what about other protection aside from signing?

You can secure Android App Bundles by using the protection mechanisms available in both DexProtector Standard and DexProtector Enterprise.

You just need to have DexProtector Enterprise or DexProtector Standard activated - with either a full license or a trial license.

The other requirements are to have Android Studio 3.2 or higher and Android Gradle Plugin 3.2.0 or higher.

So, how does it work?

The protection process for AABs is similar to that used for APKs. In fact, if you already have settings (a configuration file) for your APKs, you can go ahead and use the same ones.

The first step is to prepare and build your Android Application Bundle (AAB, .aab) if you use CLI in DexProtector. Then set up DexProtector's configuration as suggested in the documentation. Or, alternatively, just use the existing configuration you’ve created for your APK.

You’ll then be ready to launch the protection process via the CLI.

For example:

Via Gradle, you can generate and protect both the APK and AAB:

Or you can only generate and protect the AAB:

If you’d like to test the protected AAB without publishing it on Google Play, you can use the latest version of the bundletool. You can find it at https://github.com/google/bundletool/releases.

To publish an AAB that’s protected by DexProtector, all you need to do is upload it to Google Play Console.

To generate APKs from the bundle, use the following command (the APK will be built for a connected device):

The bundletool can install the APKs that are produced, too:

When you publish your AAB to Google Play, you’ll need to set the fingerprint of your app signing certificate in your configuration file. There are more details about this at Google Play App Signing. You also need to use your upload certificate for signing your AABs.

Or, put another way, you need to set the following tags in your DexProtector configuration file:

Don’t forget to use your upload keystore: