Digging Into Android App Startup API

While working on my multi-module project, I faced one challenge. The challenge is that I want to keep my Application class as clean as possible and avoid doing any heavy work there. My Application class resides in the app module.

In this project, I used a coil library for image loading. Documentation of the coil says that we need a global image loader for loading images and caching purposes. For this, we need to implement an SingletonImageLoader.Factory interface where we need to override a newImageLoader method that describes image loader properties and returns their instance.

[embed]

Now I want to move this image loader initialization part to another place. But where?

So, I’m starting r&d how we initialize something during App startup. Then I found an android api named AppStartup Api . This Api called before Application.onCreate(). So this is what I am looking for.

How to Use?

There are two ways to use this api:

1. Automatic Initialization
2. Manual Initialization
3. Automatic Initialization

Step 1: Declare this dependency in the project.

dependencies {    
implementation "androidx.startup:startup-runtime:1.2.0"
}

Step 2: Create a class that extends the Initializer<T> abstract class.

This is a generic class, where T represents what instance we need to create, e.g. WorkManager.

[embed]

So in my case, I don’t need to create any instance but just call the initialization method SingletonImageLoader.setSafe(this) in the onCreate method above.

In this class, we need to override two methods:

1. onCreate()

Where we do the initialization part and return the instance. Like, Initializing WorkManager:

override fun create(context: Context): WorkManager {
// Some initialization Logic
        return WorkManager.getInstance(context)
    }

2. dependencies()

Where do we describe that our current initializer depends on another initializer for initialization purposes or not? If yes, then we need to pass that class in the list and return. This guarantees that the dependency initializer is executed first, after which our initializer runs.

override fun dependencies(): List<Class<out Initializer<*>>> {

        return list(Initializer2::class.java , Initializer3::class.java)// Here we defined or pass which initializer we need to defined first.
    }

Step 3: Add this initializer to the AndroidManifest.xml file.

  <provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="merge">
            <meta-data
                android:name="com.aditya.example.CoilInitializer" // Our initializer.
                android:value="androidx.startup" />
        </provider>

So, when our app starts. Android os just sees our provider in the AndroidManifest file and initializes our component.

There is one more point: if our initializer depends on another initializer, then we don’t need to add that initializer in the manifest because Android OS runs that initializer first, then it moves to our initializer.

Let’s see manual Initialization.

2. Manual Initialization.

Steps 1 and 2 are the same as above. But step 3 differs.

Step 3: We need to use the node:” remove” property in the manifest file. So that our initializer is removed during merging the Manifest.

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data android:name="com.aditya.example.CoilInitializer"
              tools:node="remove" />
</provider>

This node property used above when you have many initializers, and you want to initialize some manually. And don’t remove the provider itself because the AppInitializer class depends on it. We here just disable the Automatic Initialization, not remove.

Then we need to use the AppInitializer class to initialize our Initializer. Call it where you need to initialize.

AppInitializer.getInstance(context)
    .initializeComponent(CoilInitializer::class.java)

Why did we use the App Startup Api in our project?

Before App Startup Api:

There are some library that wants to initialize their components during app startup time. And they also want to make sure that until initialization, no one can access their code. But at that time, there was no way to do these things. Android also does not support this use case.

But the library found a way to do it by using a content provider. Because content providers need to be initialized first during app startup, so that the app can use that provider for their use case.

The library uses the content provider below way:

class LibraryInitProvider : ContentProvider() {

    override fun onCreate(): Boolean {
        val context = context ?: return false

        // ⚠️ Runs BEFORE Application.onCreate()
        LibrarySdk.init(context)

        return true
    }

    override fun query(...) = null
    override fun insert(...) = null
    override fun delete(...) = 0
    override fun update(...) = 0
    override fun getType(...) = null
}

And add an entry in the manifest file :

<provider
    android:name="com.lib.LibraryInitProvider"
    android:authorities="${applicationId}.lib-init"
    android:exported="false"
    android:initOrder="100" />

However, the problem is that you have used many libraries in your project, and if some of these libraries require early initialization, then they create their own content provider. As the number of providers increases, it affects our app's startup time.

And one more thing, the content provider does not make for this type of use case.

So taggle this issue, Android launches its own Api for this use case named App Startup Api.

This API uses a single InitializationProvider ContentProvider. Multiple initializers are registered and executed through this one provider. As a result, app startup time is reduced, and overall app performance improves.

In this article, we explored how and why to use the Android App Startup API. In the next article, we’ll look at another important Android API.