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:
In most cases, the default initialization is all you need.
For more precise control of WorkManager, you can specify your own configuration.
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();
}
}