WorkManager系列（十）Custom WorkManager Configuration and Initialization

By default, WorkManager configures itself automatically when your app starts, using reasonable options that are suitable for most apps. If you require more control of how WorkManager manages and schedules work, you can customize the WorkManager configuration by initializing WorkManager yourself.

There are three initialization options:

Default initialization

In most cases, the default initialization is all you need.

Custom initialization

For more precise control of WorkManager, you can specify your own configuration.

On-demand initialization

Beginning with WorkManager 2.1.0-alpha01, you can initialize the WorkManager when you first need it, instead of initializing it at app startup. This approach may help your app launch faster. On-demand initialization is the preferred approach beginning with 2.1.0-alpha01.

Default initialization

WorkManager uses a custom ContentProvider to initialize itself when your app starts. This code lives in the internal class androidx.work.impl.WorkManagerInitializer, and uses the default Configuration. The default initializer is automatically used unless you explicitly disable it. The default initializer is suitable for most apps

 

Custom initialization

If you want to control the initialization process, you must disable the default initializer, then define your own custom configuration.

Disabling the default initializer

To provide your own configuration, you must first remove the default initializer.

To do so, update AndroidManifest.xml using the merge rule tools:node="remove":

 

<provider
    android:name="androidx.work.impl.WorkManagerInitializer"
    android:authorities="${applicationId}.workmanager-init"
    tools:node="remove" />

To learn more about using merge rules in your manifest, see the documentation on merging multiple manifest files.

 

Adding a custom configuration

Once the default initializer is removed, you can manually initialize WorkManager:

// provide custom configuration
Configuration myConfig = new Configuration.Builder()
    .setMinimumLoggingLevel(android.util.Log.INFO)
    .build();

//initialize WorkManager
WorkManager.initialize(this, myConfig);

the WorkManager singleton. Make sure the initialization runs either in Application.onCreate() or in a ContentProvider.onCreate().

For the complete list of customizations available, see the Configuration.Builder() reference documentation.

On-demand initialization

Note: On-demand initialization is available in WorkManager 2.1.0-alpha01 and higher.

The most flexible way to provide a custom initialization for WorkManager is to use on-demand initialization. On-demand initialization lets you initialize WorkManager only when that component is needed, instead of every time the app starts up. Doing so moves WorkManager off your critical startup path, improving app startup performance.

 

To use on-demand initialization:

Edit AndroidManifest.xml and disable the default initializer.

Have your Application class implement the Configuration.Provider interface, and providing your own implementation of Configuration.Provider.getWorkManagerConfiguration()

When you need to use WorkManager, call the method WorkManager.getInstance(Context). WorkManager calls your app's custom getWorkManagerConfiguration() method to discover its Configuration. (You do not need to call WorkManager.initialize() yourself.)

Note: If you call the deprecated no-parameter WorkManager.getInstance() method before WorkManager has been initialized, the method throws an exception. You should always use the WorkManager.getInstance(Context) method, even if you're not customizing WorkManager.

 

Here's an example of a custom getWorkManagerConfiguration() implementation:

class MyApplication extends Application implements Configuration.Provider {
    @Override
    public Configuration getWorkManagerConfiguration() {
        return Configuration.Builder()
                .setMinimumLoggingLevel(android.util.Log.INFO)
                .build();
    }
}