AndroidX: App Startup

AndroidX App Startup is a new addition to the Jetpack suite of libraries. This article takes an initial look at it, and focuses on 3 things: Why it was created, what it is, and how you can get started using it.

Why AndroidX App Startup?

It isn’t uncommon for libraries to run some initialization logic on app startup. Libraries such as WorkManager and Lifecycle run this initialization code on app startup using a ContentProvider, which allows to automatically run the initialization once the app goes through a cold start before Application.onCreate() is invoked.

Users expect apps to be fast to load, an app that’s slow to start provides a bad user experience. Having multiple ContentProviders run on the app startup slows down the load time of the app. Hence the AndroidX App Startup library!

What Is AndroidX App Startup?

AndroidX App Startup is a recent addition to the Android Jetpack suite of libraries. It provides a performant* way to initialize components at app startup by avoiding the use of a separate ContentProvider for each library, thus eliminating the setup cost that comes with each of them. AndroidX App Startup uses a single ContentProvider to run the initialization of all the dependencies.

LibraryA, LibraryB, and LibraryC initialized using their own ContentProviders

LibraryA, LibraryB, and LibraryC initialized by AndroidX Startup

How To Use AndroidX App Startup?

Dependency Import

Add the following dependency to your build.gradle file.

Component Initialization

To initialize a component, implement Initializer.

When defining your Initializer, you’ll have to implement 2 methods:

• create(Context): Provides the application Context, and is expected to return an instance of MyDependency, which represents the class this Initializer is setting up.
• dependencies(): Returns a list of dependencies required to be initialized before the current dependency can be initialized. This sets the order the Initializers are run at app startup. If InitializerA depends on InitializerB, and InitializerB depends on InitializerC, then InitializerC is run first, followed by InitializerB and finally InitializerA.

Let’s see an example of this. Assume you’re building a face detection app, where the user sees a camera preview, and boxes are drawn around detected faces. Your Initializers may look like this.

The CameraInitializer sets up the camera. If you’re using the CameraX library for instance, this can include setting up a custom camera configuration using CameraXConfig.

The FaceDetectorInitializer sets up the face detector, and requires the camera to have been initialized first. This may be because the face detector requires some information about the device’s camera characteristics to properly initialize.

When the app first loads, App Startup initializes CameraInitializer before FaceDetectorInitializer.

Component Automatic Initialization

For a component to be automatically initialized at app startup, declare its Initializer in the manifest file in a <meta-data> entry.

App Startup is able to automatically detect components to initialize once the app loads by reading the <meta-data> entries under the InitializationProvider manifest entry.

Only high-level Initializers have to be declared this way for automatic initialization. If InitializerA depends on InitializerB, only declaring a <meta-data> entry for InitializerA in the manifest in enough to automatically initialize both components.

Going back to the face detection app example from the previous section, you’d only need to declare FaceDetectorInitializer in your app’s manifest file for both FaceDetectorInitializer and CameraInitializer to automatically be run on app startup.

Component Lazy Initialization

Lazy initialization is useful in scenarios where a component’s initialization doesn’t have to necessarily run on app startup, for example when the component isn’t necessary. A social media app that requires users to verify their identity by taking a selfie doesn’t necessarily need to initialize the camera on app startup since the camera isn’t used frequently on the app.

Another reason to disable automatic initialization is when the initialization cost is too expensive and might significantly increase the app startup time. In this scenario, initializing the component the first time it’s needed would make for a better user experience.

To prevent App Startup from automatically initializing a component, you can abstain from adding its Initializer’s <meta-data> manifest entry (or removing it if you’ve already added it).

You can also use tools:node="remove" to make sure the manifest merger tool removes it from all other merged manifest files. This can be used for instance to disable automatic initialization for a component in one of the dependencies of your app (which actually seems like a risky thing to do).

To manually initialize a component (and its dependencies), use AppInitializer.

Once a component is initialized, manually initializing it again by calling AppInitializer.initializeComponent() doesn’t run the initialization logic again.

Conclusion

In summary:

• App Startup is a Jetpack library that provides a way to initialize components at app startup using a single ContentProvider.
• App Startup automatically initializes components (and their dependencies) declared in the manifest file under the InitializationProvider entry.
• App Startup allows controlling the order in which components are initialized.
• App Startup provides a way to lazily initialize components.

Want to learn more about app startup in Android? Check out:

• AndroidX App Startup sample app
• AndroidX App Startup official documentation
• App Startup time

For more on Java, Kotlin and Android, follow me to get notified when I write new posts or let’s connect on Github and Twitter!