| 325768c9b2e936d3018240a1209bb8fb01b06d98 |
|
08-Mar-2018 |
Christopher Tate <ctate@google.com> |
Track last job execution in heartbeat time, not strictly real time
We need to be able to handle instrumented / externally driven job
scheduling time, so we need to decouple that from "real" time. One
other effect is getting a cross-call to the usage stats module out
of the hot path of job runnability evaluation.
Bug: 73664387
Bug: 70297229
Test: atest CtsJobSchedulerTestCases
Change-Id: I0dce8af6e7fc50ce736b13572482b2db33e42b02
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| 55c84552cc0cab34f13084c219a0f4c4487e512b |
|
26-Jan-2018 |
Chris Tate <ctate@android.com> |
Merge "Let the job scheduler know when the user interacts with an app"
|
| 0e694a6383ec33e6229b95f23c4fe542322900f8 |
|
26-Jan-2018 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Calc job standby runnability based on last job execution..."
|
| 1a7bc24fd89d43b50555f3ec71d9ead29a044d20 |
|
28-Dec-2017 |
Kweku Adams <kwekua@google.com> |
Removing JobStorePersistStats STOPSHIP comment.
The linked bug is fixed.
Bug: 64536115
Test: N/A
Change-Id: Ic89b2d9b24b88459058c304e08f3f5c8de974081
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| 435c2f4820cb92e771a5083678bf3be5d3e6508e |
|
18-Jan-2018 |
Christopher Tate <ctate@google.com> |
Calc job standby runnability based on last job execution...
...not unilaterally on the current time of day. In practice, the point
is that we should let an app run new jobs immediately if it's been a long
time since it ran any, even if it's in a less-active standby bucket,
because it's being a good citizen.
Jobs for apps in the NEVER bucket (e.g. sync jobs inflated at boot time)
are also treated as immediately runnable. They won't be run at all until
the app is brought out of standby, so we just treat such apps as good
citizens.
Bug: 63527785
Test: atest CtsJobSchedulerTestCases
Change-Id: If5e3dc18757caf96ba80835f098b48614dda1d9d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| e2369a4dcfef385c64cb70d9b71df429ed3b975e |
|
19-Jan-2018 |
Robert Berry <robertberry@google.com> |
Revert "Calc job standby runnability based on last job execution..."
This reverts commit f0ce10155244b8e7361dc61640a2d0beac22471b.
Reason for revert: broken master
Test: manual
Bug: 72207660
Change-Id: Ib760dadfd51c4457744b0688f714de8f61570f50
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| f0ce10155244b8e7361dc61640a2d0beac22471b |
|
18-Jan-2018 |
Christopher Tate <ctate@google.com> |
Calc job standby runnability based on last job execution...
...not unilaterally on the current time of day. In practice, the point
is that we should let an app run new jobs immediately if it's been a long
time since it ran any, even if it's in a less-active standby bucket,
because it's being a good citizen.
Bug: 63527785
Test: atest CtsJobSchedulerTestCases
Change-Id: I1521c82f23341246484efa733c43f983a5e9e568
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| d117b293aec3fc2de0f6508cb8975af4dbd6a6a3 |
|
06-Jan-2018 |
Christopher Tate <ctate@google.com> |
Let the job scheduler know when the user interacts with an app
Bug: 70297451
Test: manual
Change-Id: I095d86f17a589d8b6531fb71018cfd4276989ba4
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| 1d99c391ecd30c27be2e8f61aa9ec64546d15d4b |
|
08-Dec-2017 |
Christopher Tate <ctate@google.com> |
Cancel alarms & jobs when an app's data is cleared
In the same bit of code, fix a system restore issue: in the
course of setup + restore, we reestablish permission grants and
notification state up front for the to-be-restored app, and
then bring in its data. However, a data wipe is part of the
prologue for that data delivery -- so we were inadvertently
unwinding the permission grants and notification state restore
that we'd just performed. Now, we distinguish the restore flow
from other clear-data operations so we don't unwind that operation.
Finally take the opportunity to elide a lot of copypasta code into
a single predicate-driven implementation.
Bug: 67508896
Bug: 69538432
Test: atest android.app.cts.AlarmManagerTest
Change-Id: I15c912c3c99645599ae9bd6fb7337fa86b4e5757
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| a732f014c5743af0dbb7eb2e63474a7147576f9d |
|
27-Oct-2017 |
Christopher Tate <ctate@google.com> |
The job scheduler now backs off jobs based on standby bucketing
The default parameters here translate to roughly this rate limiting:
ACTIVE: run jobs whenever
WORKING: ~ hourly
FREQUENT: ~ every 6 hours
RARE: ~ daily
Bug: 63527785
Test: cts & manual (WIP)
atest CtsJobSchedulerTestCases
Change-Id: I58f8e53e5bdf40601823e5a10a9f2383a6f67ae5
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| e7b029807042a2e49f91a958229624fa4f38b813 |
|
24-Aug-2017 |
Makoto Onuki <omakoto@google.com> |
SyncManager: Log # of jobs loaded, and saved most recently.
Also moved the "wtf for cancelAll for the system UID" code to catch
other entry points.
Bug: 64536115
Test: Manual
Change-Id: I55ff515ad70263d6f953f18d6be02f6292742efa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| dd4b14f70ddd806c11e9b0dcbd2101bd167fda12 |
|
17-Aug-2017 |
Makoto Onuki <omakoto@google.com> |
SyncManager: detect suspicious periodic sync removal.
- Also disallow and detect JobScheduler.cancelAll() for the system UID.
- Also wtf() if jobs.xml can't be read.
Bug: 64536115
Test: boot, add & remove google accounts
Change-Id: I953c12f70b479cf5f71a81a3787c103599f243c8
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| f9bac16d61db0fceb15484587ecf876c2b802c37 |
|
21-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #32180780: Sync adapters inappropriately being run...
...during full-data backup/restore
The activity manager now tells job scheduler service about the
current backup that is running (only if it is a full backup), it
there is a new condition where we won't consider jobs associated
with the current backup to be ready to run.
Also... just a little optimization here. :) The focus is on
scheduling jobs with a 0 deadline, meaning they should run right
away. Now the timing controller does a quick check for a new
job to see if its constraints are already satisifed, and doesn't
do anything further if that is the case (doesn't add to the list,
doesn't re-evaluate alarms, etc). And in the path to scheduling
a job, we do a check to see if the new job is already ready and if
so then just directly add it to the pending list and schedule it.
Doing this required removing what I think is the last bit of code
relying on handler serializing for thread safety, so now everything
in the job scheduler is protected by our global lock and we can
do whatever we want with the lock held and be assured the state
remains consistent.
Also did some small optimizations to many of the other controllers,
mostly switching from an ArrayList to an ArraySet for their tracked
jobs, since one of the things we do frequently is add/remove jobs.
Finally, added some nullability annotations to the JobScheduler
APIs.
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I533fad94ba59468a52fe3d077a0ceab3427f0012
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|
| cbf5ae92e70ed49f18b9e7454dc28d489b3d33a4 |
|
08-Mar-2016 |
Shreyas Basarge <snb@google.com> |
Remove SyncManager's local job cache
SyncManager maintains a local copy of all
scheduled syncs. This was done so that we
don't have to query JobScheduler every time
we need to go through the syncs to reschedule
them, etc. Keeping JobScheduler's job list and
the SyncManager's copy in sync is messy. Not
keeping a copy with SyncManager would also
allow JobScheduler to drop jobs based on an
app being uninstalled or other external events.
Here, a function to query all pending jobs
scheduled by the system process is exposed
from JobScheduler and SyncManager uses it
instead of maintaining a copy of its own.
Change-Id: I723dbb3835a0f9c7e8844483004e7b0f7f340daf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerInternal.java
|