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.
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();
}
}
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" />
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.