Beta testing Dynamic Features with Firebase App Distribution

I will explain how we are using bundletool with the aim to deliver and test dynamic features with FAD (Firebase App Distribution).

If you want to know how to configure them, you can read this article written by my teammate Andrés Micó.

Context

In our Super App business model in Jeff, we require a scalable way to offer different services to our users. The dynamic features fit like a glove with our verticals model (laundry, beauty, fit, relax…) due to the fact that they are on top of the core application.

What’s the challenge?

Release tracking on Play Console allows upload bundles. The issue is that we are using FAD for our internal beta testing distribution (migrated from formerly Fabric Beta) and it does not allow upload bundles yet (required for dynamic features). If you compile a common apk, the dynamic features will not be included in the package and it will not work on runtime.

Steps

1. Include the Dynamic Feature

First of all, we have to set that the dynamic feature will always be available. By the way, for now, we cannot enjoy the option to download on-demand, but our code will be ready once FAD supports bundle distribution.

We go to the AndroidManifest.xml of the dynamic module, and we set something like this:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:dist="http://schemas.android.com/apk/distribution"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.example.foo">
    <dist:module
        dist:instant="false"
        dist:title="@string/dynamic_feature_title_foo">
        <dist:delivery>
            <dist:install-time/>
        </dist:delivery>
        <dist:fusing dist:include="true"/>
    </dist:module>
</manifest>

2. Compile the Bundle

Execute the bundle Gradle task related to the build variant we want to test.

We are going to use the release build type to simplify, but we can use product flavors and extrapolate this example to any build variant.

Thus, we execute bundleRelease.

Once the compilation finishes, we will get an *.aab file (Android App Bundle).

3. Download Bundletool

It is a *.jar, a java executable file we can use to convert a bundle in a *.apks, a file that contents a compilation of *.apk files that a specific device distribution requires.

We can find it here. Download it, because we are going to use it in the next step. 😉

4. Generate the Universal *.apks

From the bundle, we generate the universal *.apks file. It will have all possible configurations, so the dynamic features will be included too. For getting further information about how bundletool works, see the official documentation.

It is noteworthy that it is not the same an *apk file than an *apks one. The *apks can store many *apk files within it.

Now, we generate the *apks file executing this command console:

java -jar bundletool.jar build-apks

Followed by these options :

• -bundle=<bundle-name>.aab
• -output=<out-name>.apks
• -mode=universal ← This does the trick
• -ks=<key-name>.jks
• -ks-key-alias=<alias>

Applying the universal mode, we store all the *.apk in the container. By the way, the dynamic modules will be included too.

For example:

java -jar bundletool.jar build-apks --bundle=app-release.aab --output=app-release.apks --mode=universal --ks=<key-name>.jks --ks-key-alias=<alias>

Take into account, you have to change <key-name> and <alias> with your own values. 😅

The terminal will request us the keystore password and password.

After we enter both credentials, the app-release.apks is generated.

5. Extract Universal *.apk

The following step is pretty easy. Simply, extract the content of app-release.apks (in the end, it is just a zip file).

Run this command:

unzip app-release.apks

At this point, a couple of files appear: toc.pb and universal.apk. The second one is our desired file. We will upload it to FAD to distribute our app with dynamic features for internal testing.

Conclusion

The dynamic features are a very interesting option Google gives us in order to…

• Leverage the size of the download installation. It can make the difference to the user helping her / his in the decision of installing our app or not
• Reduce the space on mobile disk, very valuable in low range devices
• Follow good practice in our project for decoupling different verticals as each one does not have to know anything about the others
• In your project you can unload the dynamic feature modules you are not working on without thinking too much, reducing the build times. By the way, using them can be a game-changer for your business

Consequently, it is very interesting to include them in our projects although we are using FAD.

If you liked this article, visit my website.

Enjoy!

Next steps

Although this process is not very complicated, doing those steps each time we want to release a beta can be very repetitive and absolutely tedious. It smells strong and it must be automated… For sure! You can use your preferred CD (Continuous Delivery) tool to do the work.

We use Jenkins to solve this. In the next article, I will show you how to automate this process with this tool.

Meanwhile, if you want to move forward, you can read this article written by my also teammate, Eliseo Juan Quintanilla, where he explains very good tips to automate very interesting common actions we do in our day-to-day.