Fixed
Status Update
Comments
e....@gmail.com <e....@gmail.com> #2
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 ( b/32180780 ). Since neither
// 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?
ra...@google.com <ra...@google.com>
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit e14104eb7008f82edd50b37e16bd119b307e0554
Author: Sumir Kataria <sumir@google.com>
Date: Mon Jun 24 10:50:57 2019
Fix for JobScheduler calls when backup is in progress.
The original fix (ag/Ia1604b7c4b98f6b31869e1161a0c1efce7fe46f2) relied
on a null-check, but the new version of WorkManager.getInstance(Context)
with the Context param doesn't return null; it throws an Exception. This
CL updates the three places where we explicitly check for the return value
internally:
1. SystemJobService (the main place where this would manifest)
2. RescheduleReceiver
3. WorkManagerTestInitHelper (for consistency)
Fixes: 135858602
Test: Ran existing tests
Change-Id: Ia232869712d0c78fd80e91d0a863b8c50a080400
M work/workmanager-testing/src/main/java/androidx/work/testing/WorkManagerTestInitHelper.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/RescheduleReceiver.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java
https://android-review.googlesource.com/988026
https://goto.google.com/android-sha1/e14104eb7008f82edd50b37e16bd119b307e0554
Branch: androidx-master-dev
commit e14104eb7008f82edd50b37e16bd119b307e0554
Author: Sumir Kataria <sumir@google.com>
Date: Mon Jun 24 10:50:57 2019
Fix for JobScheduler calls when backup is in progress.
The original fix (ag/Ia1604b7c4b98f6b31869e1161a0c1efce7fe46f2) relied
on a null-check, but the new version of WorkManager.getInstance(Context)
with the Context param doesn't return null; it throws an Exception. This
CL updates the three places where we explicitly check for the return value
internally:
1. SystemJobService (the main place where this would manifest)
2. RescheduleReceiver
3. WorkManagerTestInitHelper (for consistency)
Fixes: 135858602
Test: Ran existing tests
Change-Id: Ia232869712d0c78fd80e91d0a863b8c50a080400
M work/workmanager-testing/src/main/java/androidx/work/testing/WorkManagerTestInitHelper.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/RescheduleReceiver.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobService.java
Description
Component used: WorkManager Multiprocess
Version used: 2.5.0-alpha02
Devices/Android versions reproduced on: N/A
Default process name shouldn't be
Context.getPackageName()
butContext.getApplicationInfo().processName
:Current androidx.work.impl.utils.ProcessUtils:
Suggested fix: