WorkManager's OneTimeWorkRequest stays in enqueued state indefinitely. [123329850]

Fixed

Bug

Status Update

No update yet.

Description

ar...@gmail.com

created issue #1

Jan 24, 2019 11:23AM

Component used: WorkManager
Version used: 1.0.0-beta02
Devices/Android versions reproduced on: Pixel/Pie, Pixel2/Pie, Pixel3/Pie, Motorola Moto-G/Lollipop

Steps to reproduce:
Create a OneTimeWorkRequest like below, while it's running, close the app from app drawer. The first assumption that the enqueued task will run in background even when the app is closed is not true (Task is not started again even after an hour). Also the enqueued OneTimeWorkRequest won't start again on next app launch and stays in ENQUEUED state indefinitely.

private void startTestWork() {
Constraints testConstraints = new Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresBatteryNotLow(true)
.build();
isMyWorkerRunning(TEST_WORKER_TAG);
OneTimeWorkRequest testOneTimeWorkRequest = new OneTimeWorkRequest
.Builder(TestWorker.class)
.addTag(TEST_WORKER_TAG)
.setInitialDelay(0, TimeUnit.SECONDS)
.setConstraints(testConstraints)
.build();
WorkManager.getInstance().enqueueUniqueWork(TEST_WORKER_TAG, ExistingWorkPolicy.KEEP,
testOneTimeWorkRequest);
}

Comments

ra...@google.com <ra...@google.com> #2Jan 24, 2019 06:09PM

Status: Duplicate of

123211993

We are Facing this same issue after updating to compose 1.3.0 and also only on Android 9 Devices.

ra...@google.com <ra...@google.com> #3Jan 24, 2019 06:09PM

Note: Some of the latest comments from

b/212982463

could be relevant to this issue

ar...@gmail.com <ar...@gmail.com> #4Jan 25, 2019 08:03AM

Hi, Is there any update on this. Any temp workaround would be helpful as well. Currently we have 10s of thousand users per day getting affected by this.

ra...@google.com <ra...@google.com> #5Jan 25, 2019 06:24PM

Project: platform/frameworks/support
Branch: androidx-main

commit e3164fbf4137f9cf60da424aef4b1d9ea5202b6c
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Thu Dec 15 18:00:23 2022

Make our fake Views we use as graphic layer to save nothing as the View's saved instance state.

Because the Views were attached to the hierarchy and had an id their state was saved polluting the state Activity saves in Bundle. Such views have no real state as they are not used as real views.

Test: ComposeViewSavedStateSizeTest
Bug: 260322832
Change-Id: I0b755a3d6a164b6c26aa592e13e206dc45cd5dd9

A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/platform/ComposeViewSavedStateSizeTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt

https://android-review.googlesource.com/2359699

en...@gmail.com <en...@gmail.com> #6Jan 28, 2019 09:17AM

Project: platform/frameworks/support
Branch: androidx-main

commit 326b394002e0f899fdc0bffc622761bc67bca21b
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Thu Dec 15 16:16:31 2022

Destroy layers added on the nodes when the node is removed

Currently the layer objects are not being removed from the AndroidComposeView in this situation, which means we are not reusing the layers and we keep them attached until the whole AndroidComposeView is not garbage collected.

Test: new test in MeasureAndLayoutDelegateTest
Bug: 260322832
Change-Id: Iaeee5662b4646230cebdafd2484c691df657edda

M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/Helpers.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/MeasureAndLayoutDelegateTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/NodeCoordinator.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/NodeKind.kt

https://android-review.googlesource.com/2359119

ra...@google.com <ra...@google.com> #7Jan 29, 2019 01:04AM

Great. Thank you very much for fixing this. Really appreciate the quick response. Could you share which version this fix will be released?

en...@gmail.com <en...@gmail.com> #8Jan 29, 2019 01:05PM

Hi there! Most likely next release of Compose UI, by mid January. Cheers.

ra...@google.com <ra...@google.com> #9Jan 29, 2019 06:34PM

Assigned to ra...@google.com.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.ui:ui:1.3.3
androidx.compose.ui:ui:1.4.0-alpha04

ra...@google.com <ra...@google.com> #10Jan 29, 2019 06:44PM

Issue is still existing with the same rate in 1.3.3 and similar reproduction steps. Since this ticket is already set as fixed, should we file a new bug?

en...@gmail.com <en...@gmail.com> #11Jan 30, 2019 09:07AM

Hey. Please check that you can reproduce the same issue with the latest 1.4 release and if yes please file a new bug. Thanks

log-workmanager-repro-verbose-3.txt

22 KB

View

Download

ra...@google.com <ra...@google.com> #12Jan 30, 2019 06:13PM

Thanks for providing more information.. This is in line with a fix that I am working on. This should be fixed in the next beta.

https://android-review.googlesource.com/c/platform/frameworks/support/+/889837

ap...@google.com <ap...@google.com> #13Jan 30, 2019 07:05PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit ebb4f87d732f66d01d1a4cf362bb11a815e80b74
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Tue Jan 29 16:16:17 2019

Correctly retry work on process death when using AlarmManager based implementation.

* AlarmManager now schedules a Worker unless the WorkSpec#isFinished() is true.
* When AlarmManager gets worken up by ActivityManager to resume processing, we
correctly execute the Worker after a backoff period.
* We now correctly handle rescheduling in DelayMetCommandHandler. Previously the
only reason why this worked before was the call to Schedulers.schedule() in
WorkerWrapper inside the onWorkFinished() method.
* When delaying execution of Workers in WorkerWrapper we always reschedule givem
SystemJobScheduler does not schedule jobs where JobScheduler is already aware
of the jobId.
* Added a lot more logging in GreedyScheduler, SystemJobScheduler and SystemAlarmScheduler
to make debugging easier.
* Ran a lot of integration tests on API 22, 23 (double scheduling) and 28.
Look at

https://paste.googleplex.com/5709211287683072?raw
for more information. I also ran integration tests that cancel
workers to sanity check.

Fixes:

b/123329850

Test: Added additional test cases in SystemAlarmDispatcherTest.

Change-Id: I1bcff1ebf5f60928a02e3e94e2e6ccaed0de47b1

M work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/MainActivity.java
A work/integration-tests/testapp/src/main/java/androidx/work/integration/testapp/RetryWorker.java
M work/integration-tests/testapp/src/main/res/layout/activity_main.xml
M work/integration-tests/testapp/src/main/res/values/strings.xml
M work/workmanager/src/androidTest/java/androidx/work/impl/WorkerWrapperTest.java
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/WorkerWrapper.java
M work/workmanager/src/main/java/androidx/work/impl/background/greedy/GreedyScheduler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/CommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemjob/SystemJobScheduler.java

https://android-review.googlesource.com/889837

https://goto.google.com/android-sha1/ebb4f87d732f66d01d1a4cf362bb11a815e80b74