Status Update
No update yet.
Comments
se...@google.com
Rahul, should we add initOrder to startup's content provider?
ra...@google.com
We can, although i would rather they move from multiple content providers to a single one and that way they avoid this problem altogether.
initOrder just defines a priority and other providers can claim to be of the same or a higher priority.
je...@gmail.com
If by "they" you mean the person using your library... as long as there are >0 content providers, there's a chance that the App Startup provider won't be the first initialized. Maybe I didn't understand you.
- Fix the error message so it at least does not mislead people. A more appropriate error message might be "Work Manager accessed before it was initialized.".
- initOrder is infrequently used. You could avoid 99.999% of this problem by setting a higher than default value.
Another solution might be, if it's possible, allow the user to re-define / merge the App Startup provider definition and set the init order themselves. Then it's just a matter of documenting this problem and how to solve it.
se...@google.com
We can, although i would rather they move from multiple content providers to a single one and that way they avoid this problem altogether.
Yeah I don't really think it is feasible given one of these content providers is ours App Startup's provider.
ra...@google.com
Yeah we could rely on initOrder here, but that won't fix it 100% of the time given the developer could be using a similar trick. We should also document this bit so its clear what might be going on.
Description
Component used: androidx.work:work-runtime Version used: 2.7.1 Devices/Android versions reproduced on: Clover POS / Android 10
To reproduce, install (but do not start any component):https://github.com/farble1670/WorkManagerNotInitialized
Ensure process is not running:
From command line:
See in logs:
Work Manager uses App Startup to initialize itself (by default). App Startup relies on a quirk of Android that content providers are / can be initialized before the application class. I think the idea is that Work Manager can exploit this to be full initialized before anything that would otherwise be kicked off in by the application class.
The problem is the assumption that App Startup is the only content provider. If there are multiple content providers there's no guarantee that App Startup's content provider will run before others. In our case we have a code path where a content provider was causing WorkManager#getInstance to be called before the App Startup content provider initialized Work Manager.
The work around is to use on-demand initialization.
The error message in this case is very misleading: "You have explicitly disabled WorkManagerInitializer in your manifest". This is not true obviously.