Change theme
Help
Press space for more information.
Show links for this issue (Shortcut: i, l)
Copy issue ID
Previous Issue (Shortcut: k)
Next Issue (Shortcut: j)
Sign in to use full features.
Vote: I am impacted
Notification menu
Refresh (Shortcut: Shift+r)
Go home (Shortcut: u)
Pending code changes (auto-populated)
View issue level access limits(Press Alt + Right arrow for more information)
Unintended behavior
View staffing
Description
Developers of 3rd party libraries that want to use WorkManager run into the following constraints:
work-multiprocess
)work-multiprocess
, WorkManager should be initialized and configured withConfiguration.Builder.setDefaultProcessName
in all processes that use it (otherwise the process running a RemoteWorkerService will reschedule all work on startup, leading to canceling work that was just started and running it later)There are a few ways all these constraints could be addressed. One approach might be to provide a
isInitialized()
API as well asgetConfiguration()
orgetDefaultProcessName()
.However, I'm not sure that's the best path forward. Multi process is tricky, especially for libraries, because app developers tend to do things in
Application.onCreate()
without realizing that a library will start a new process and trigger that code in it. Ideally libraries wouldn't have to deal with init / configuration at all, or they would be able to use WorkManager in isolation with a separate configuration from the app configuration (i.e. maybe get a different WorkManager instance that operates differently from the main singleton).