Fixed
Status Update
No update yet.
Comments
ra...@google.com
ra...@google.com
ap...@google.com
In SystemJobService, it can expect null, and able to tolerance null from WorkManagerImpl.getInstance, due to auto-backup reason.
@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
if (mWorkManagerImpl == null) {
// This can occur if...
// 1. The app is performing an auto-backup. Prior to O, JobScheduler could erroneously
// try to send commands to JobService in this state (
// Application#onCreate nor ContentProviders have run, WorkManager won't be
// initialized. In this case, we should ignore all JobScheduler commands and tell it
// to retry.
But, current WorkManagerImpl.getInstance(Context context) implementation is that, it will never return null but throw IllegalStateException.
Isn't there's conflict among these 2 SystemJobService.onCreate logic, and WorkManagerImpl.getInstance logic?
@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
if (mWorkManagerImpl == null) {
// This can occur if...
// 1. The app is performing an auto-backup. Prior to O, JobScheduler could erroneously
// try to send commands to JobService in this state (
// Application#onCreate nor ContentProviders have run, WorkManager won't be
// initialized. In this case, we should ignore all JobScheduler commands and tell it
// to retry.
But, current WorkManagerImpl.getInstance(Context context) implementation is that, it will never return null but throw IllegalStateException.
Isn't there's conflict among these 2 SystemJobService.onCreate logic, and WorkManagerImpl.getInstance logic?
Description
Component used: WorkManager
Version used: 2.4.0
Devices/Android versions reproduced on: Pixel 3a
Sample project:https://github.com/npike/android-workmanager-fromStates
It seems that when I have a Worker running with a constraint of RequiredNetworkType(NetworkType.CONNECTED), and disable my device's WiFi, that Worker is correctly cancelled, but the LiveData returned by the following code does not update to reflect the change in state from RUNNING to ENQUEUED.
The LiveData returned by the following code (observing a single tag for the same Worker above) updates as expected to reflect the new ENQUEUED state of my Worker.
This logic can be found in MainViewModel of the sample project linked in this ticket.