PeriodicWork was rescheduled when the app cold start [79660657]

Fixed

Bug

Status Update

No update yet.

Description

ke...@gmail.com

created issue #1

May 14, 2018 07:12AM

Component used: WorkManager
Version used: 1.0.0-alpha
Devices/Android versions reproduced on: Emulator API 27

PeriodicWork is rescheduled each time cold start.
So JobService will be registered as many times as cold start.

- Sample project to trigger the issue.

https://github.com/ken-kentan/WorkManagerSample

- Reproduction
1. Launch WorkManagerSample app
2. Push [SCHEDULE] button. (will scheduled the 15min interval Worker)
3. Exit app and Clear app history(from the ■ button)
4. Launch WorkManagerSample app again(cold start)

- Result of [>>adb shell dumpsys jobscheduler]. (scheduled 2 jobs...)
JOB #u0a80/4: c32b177 com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
u0a80 tag=*job*/com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
Source: uid=u0a80 user=0 pkg=com.example.workmanagersample
JobInfo:
Service: com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
PERIODIC: interval=+15m0s0ms flex=+15m0s0ms
PERSISTED
Requires: charging=false batteryNotLow=false deviceIdle=false
Extras: {EXTRA_WORK_SPEC_ID=c46ef83e-13b1-4595-888e-b80a4c8a72cf, EXTRA_IS_PERIODIC=true}
Backoff: policy=1 initial=+30s0ms
Has early constraint
Has late constraint
Required constraints: TIMING_DELAY DEADLINE
Satisfied constraints: APP_NOT_IDLE DEVICE_NOT_DOZING
Unsatisfied constraints: TIMING_DELAY DEADLINE
Tracking: TIME
Enqueue time: -4m46s595ms
Run time: earliest=+10m7s569ms, latest=+25m7s569ms
Last successful run: 2018-05-14 04:49:01
Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)
JOB #u0a80/5: 93cf1f3 com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
u0a80 tag=*job*/com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
Source: uid=u0a80 user=0 pkg=com.example.workmanagersample
JobInfo:
Service: com.example.workmanagersample/androidx.work.impl.background.systemjob.SystemJobService
PERIODIC: interval=+15m0s0ms flex=+15m0s0ms
PERSISTED
Requires: charging=false batteryNotLow=false deviceIdle=false
Extras: {EXTRA_WORK_SPEC_ID=c46ef83e-13b1-4595-888e-b80a4c8a72cf, EXTRA_IS_PERIODIC=true}
Backoff: policy=1 initial=+30s0ms
Has early constraint
Has late constraint
Required constraints: TIMING_DELAY DEADLINE
Satisfied constraints: APP_NOT_IDLE DEVICE_NOT_DOZING
Unsatisfied constraints: TIMING_DELAY DEADLINE
Tracking: TIME
Enqueue time: -2m12s405ms
Run time: earliest=+12m29s338ms, latest=+27m29s338ms
Last successful run: 2018-05-14 04:51:35
Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)

Comments

ra...@google.com <ra...@google.com> May 14, 2018 07:45PM

Assigned to ra...@google.com.

ra...@google.com <ra...@google.com> May 21, 2018 08:47PM

Marked as fixed.

at...@bloomberg.net <at...@bloomberg.net> #2Sep 10, 2018 02:56PM

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

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019

Change the way to detect mismatch between POJO and query

This fixes cursor mismatch warnings with expandProjection.

Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

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

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

su...@google.com <su...@google.com> #3Sep 10, 2018 05:38PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

at...@bloomberg.net <at...@bloomberg.net> #4Sep 11, 2018 12:55PM

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

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020

Re-factor how errors are dismissed when query is re-written

This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (

b/140759491

).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.

This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.

Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

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

su...@google.com <su...@google.com> #5Sep 11, 2018 06:46PM

I believe what you're seeing is intended. You are enqueuing N periodic jobs. There is nothing unique about them (did you mean to use enqueueUniqueWork?). So there are N periodic jobs running in parallel.

The reason they run when the app is launched is that you are effectively force-stopping your app by using Android Studio relaunches. You aren't just launching the app, you are force-stopping it (and possibly replacing the APK) and then launching it. After WorkManager figures out it's been force-stopped, it makes sure to re-enqueue the tasks. This means periodic work will run again.

Issue 79660657