Android Instant Apps, Part 3

Finally, we will now discuss how to build your Instant App, or modify your Installable application to support this feature. This will not be a step by step tutorial, but a short clarification regarding the process and how best to approach this.

The entire project must be modular. We have 4 basic modules:

• App module
• Instant App module
• Feature module
• Base feature module

App Module

For an Installable app’s main module, here is everything you do not want to provide for an Instant App. If you have only two screens provided for the Instant App feature and you have 15 in your full app, you will not put them into feature modules. Instead, you will place them here. This manifest is practically empty, containing only screens, class, database, and anything that does not make sense to provide in an Instant App.

Instant App module

The Instant App module contains nothing but a build.gradle file. We give no resources or classes here. Therefore, when you build an Instant App APK, it takes all the features and bundles them together.

Base Feature Module

The Base Feature Module is the most basic module for Instant Apps. It contains all shared classes, layouts, activities, and fragments, as well as the main manifest with all the elements, permissions, and other items. All screens are available through multiple features provided by Instant App or some utils, location services, rest providers, etc ..

In the Gradle, we also need to set the apply plugin: com.android.feature header and change the build of your app. It must contain using android basefeature: true, and we need to inject all Feature Modules to these dependencies- which will be accessed from the outside.

Feature Module

The Feature Module should be known as the one which preserves activity with a fragment or model. Principally, when you access an Instant App in part, you only download one feature module that is defined, and a base feature module. This module contains only classes of fragment activity, or a view model, and manifests an intent filter with App Links. All resources should be in the base feature.

APK for both builds on background

An Instant App is like the zip of module APK’s stored by Google Play. Each Feature Module is built as a separate standing APK, which means, all Feature Modules need to have their own package name postfix. Once you source an Instant App by hyperlink, Google Play provides only one Feature Module APK to your device.

Installable apps, on the other hand, take all the feature modules (in *.aar format) and produce the final APK for Google Play.

How to convert apps for this feature

So far, we’ve been talking about how to implement Instant Apps when you are creating a new application. But what may be even more important, is how to improve an existing application to support this new feature.

To begin with, it would be a great idea to first review your project and assess if it can be modified with this feature, and decide whether you will need to start from scratch due to the current architecture.

Subsequently, you need to analyse all use-cases and screens for the Instant App feature. It is most important to examine the side entry points in all screens, the whole flow of access and data obtainment, and if you have a restrictive login flow.

Now comes the hard part. You will need to split the application sources into modules and features. Each feature module will have its own gradle file, manifest with Intent-filter for module screen, as well as sources about the screens.

You will then need to do a massive refactoring of the sources due to the project’s modularity and clean architecture. Once you have completed that, you will have to implement and chain through the Android App Links between the application and the server so that all modules and screens will work together.

And finally, we are all here just hoping that it won’t blow up the universe when we turn it on.