Search code examples
androidandroidxandroid-workmanager

WorkManager - Should we remove the default initializer, when we use both Default initialization and Custom initialization?


I'm getting the following new error, when I upgrade WorkManager from "2.2.0" to "2.3.0-rc01"

The error occurs when I'm exporting APK.

C:\app: Error: Remove androidx.work.impl.WorkManagerInitializer from your AndroidManifest.xml when using on-demand initialization. [RemoveWorkManagerInitializer]

   Explanation for issues of type "RemoveWorkManagerInitializer":
   If an android.app.Application implements
   androidx.work.Configuration.Provider,
   the default androidx.work.impl.WorkManagerInitializer needs to be removed
   from the
   AndroidManifest.xml file.

I'm not sure why I didn't get such error in 2.2.0, as "On-Demand Initialization" is introduced since 2.1.0.

According to https://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration#remove-default

I'm not kinna sure, whether it is a right thing to include the following in my AndroidManifest.xml.

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

Currently, the following is my Application class.

MyApplication class

public class MyApplication extends MultiDexApplication implements Configuration.Provider {
    private static MyApplication me;

    @Override
    public void onCreate() {
        super.onCreate();

        me = this;
    }

    public static MyApplication instance() {
        return me;
    }

    @NonNull
    @Override
    public Configuration getWorkManagerConfiguration() {
        return new Configuration.Builder()
                .build();
    }
}

How I construct WorkManager

public static WorkManager getWorkManager() {
    MyApplication myApplication = MyApplication.instance();
    if (myApplication == null) {
        // Very rare edge case. Not sure how it happens. But, it happens :)
        return WorkManager.getInstance();
    } else {
        return WorkManager.getInstance(myApplication);
    }
}

It seems that there is rare chance that "Default initialization" (WorkManager.getInstance()) is being executed too, when the Application class is null.

I can easily eliminate error during APK exporting, by including the following provider. But, is that a right thing to to so?

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

Solution

  • We introduced this lint rule in WorkManager 2.3.0-*. The problem we are trying to address with this Lint rule is that if you have both the WorkManagerInitializer ContentProvider and your Application subtype implements Configuration.Provider (for on-demand initialization) - the ContentProvider will always take precedence.

    This might be unexpected, especially when you have additional Configuration which will not take effect because the ContentProvider always uses the default configuration.

    All you really need to do is to remove the default provider. That way initialization will no longer be eager, but be on-demand.