| 24ab3aafe2482cb70ed0b5e0d653c2edeb5af8d3 |
|
06-Oct-2016 |
Chris Tate <ctate@android.com> |
Merge "Fix job scheduler crash due to uninstall race" into nyc-mr1-dev
|
| e39a8a46d92ead0bdc8a2ceabe510cf6e89b8fbc |
|
06-Oct-2016 |
Nancy Zheng <nzheng@google.com> |
Change DEFAULT_BG_LOW_JOB_COUNT to 1 in JobSchedulerService.
Bug: 31601136
Change-Id: I595f192698b97dc6472a67dc1a1eebd60533efa7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 652c5ad5167b36735bd04b38b9b904d7bdf8033e |
|
05-Oct-2016 |
Christopher Tate <ctate@google.com> |
Fix job scheduler crash due to uninstall race
It's possible to get a PACKAGE_CHANGED broadcast well after the
package has actually been uninstalled outright because of broadcast
delivery latencies. Understand the exception that might be thrown
when asking for package info in such cases, so we don't crash the
Android runtime.
Bug 31865735
Change-Id: I69b2678f0f724fc731aa48fed7af58ce60d3c21c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| eafb535072698b0559d8919db4b18618359c11b9 |
|
05-Oct-2016 |
Christopher Tate <ctate@google.com> |
Eliminate unnecessary object churn in job scheduler updating
The arbitrary-caller "what job is currently running?" state inspector
returns a clone of the JobStatus record for it, not a live reference
to the scheduler's active state. That's appropriate for most cases
but when doing its own internal bookkeeping, the object churn in cloning
(especially, an unneeded clone just for purposes of comparing to some
other job!) is merely a huge waste of CPU and GC load.
So now we don't do that unnecessarily, and everything is much leaner.
Bug 31751985
Change-Id: Idacb52e9e5ca17b9e12b7ccd2fc2e1ec8b3547f6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ee7805be22756970568334961daa23d0b5856846 |
|
16-Jul-2016 |
Christopher Tate <ctate@google.com> |
Remove scheduled jobs when an app is force-stopped
Bug 30100499
Change-Id: Id98a2fe68c07aa9e4557685d3653954d02b71d0a
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 785f494e8752ca3bcffe1d648ecf05b0734df31c |
|
14-Jul-2016 |
Jeff Sharkey <jsharkey@android.com> |
Require permission for FLAG_WILL_BE_FOREGROUND.
We caught scheduleAsPackage(), but not schedule(), oops.
Bug: 28998999
Change-Id: I0642c2265ff61eead8747cc6b4d0f852f1ca3ef2
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7ab4025474d3ce80b00fbc96962a585f918a0be1 |
|
16-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29371078: Foreground jobs should not count...
...as active for idle maintenance
Nor jobs of whitelisted apps.
Now they don't.
Also remove the no longer used "active download" tracking code.
Change-Id: I553197801f6eabaf15716f3201dd65257a0d4e94
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 34618b586996dfbfd87a3b7f0d18f26d4d1ebb51 |
|
01-Jun-2016 |
Jeff Sharkey <jsharkey@android.com> |
Skip cancelling jobs with FLAG_WILL_BE_FOREGROUND.
When FLAG_WILL_BE_FOREGROUND is set on a job (such as a download), we
need to treat the job as if it had a foreground service running so
it can continue making forward progress. We already ignore the device
idle state when offering to start the job, so this just avoids the
hiccup of stopping the job only to restart it a minute later.
Bug: 26571724
Change-Id: I348903dd3a7dd7104b0c1bf4310e2a48655d2588
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 970e3f412d34cbeae3706de5cb1de0b3ca741f87 |
|
01-Jun-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #29069028 NYC: device boot failure: NPE in AppIdleController
Make sure the core parts of JobSchedulerService are initialized
before we start creating the controllers.
Change-Id: I497df12f7e6fbd93581291ec691c4b45104d67d0
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| e9a988caca733d2f292991a52a0047685a69812f |
|
28-May-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #28942589: Tune job scheduler
We now have a new settings key that provides all of the existing
tuning parameters, plus some newly redone ones for dealing with
different memory levels.
Changed the minimum batching for overall jobs from 2 to 1, so
we will never get in the way of immediately scheduling jobs
when the developer asks for this. We should now be able to rely
on the doze modes to do better batching of jobs for us when it
is really important.
Also work on issue #28981330: Excessive JobScheduler wakeup alarms.
Use a work source with scheduled alarms to blame them on the app
whose job they are being scheduled for, and add a check for whether
a job's timing constraint has been satisfied before considering it
a possible candidate for the next alarm. (If it is satisified,
the time is in the past, so we should not schedule an alarm for it.)
Finally clean up a bunch of the dumpsys output to make it easier
to understand.
Change-Id: I06cf2c1310448f47cf386f393e9b267335fabaeb
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b5c0788d3686351cfe594c6b680d2857f89e4a63 |
|
27-May-2016 |
Christopher Tate <ctate@google.com> |
Purge an app's scheduled jobs when the whole package is disabled
Bug 28979894
Change-Id: If8a99489eaaa219274289fdf2e90be8bdecb3bfa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 564915c58e30a1849386f1a77559a461b9f681f4 |
|
04-May-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Check permission for FLAG_WILL_BE_FOREGROUND." into nyc-dev
|
| 4f10040f6b37f4d3c11487d452d3eb86c858a756 |
|
04-May-2016 |
Jeff Sharkey <jsharkey@android.com> |
Check permission for FLAG_WILL_BE_FOREGROUND.
This flag is only designed to be used by platform internals, such as
DownloadManager, so require that callers hold a nice strong
permission.
Bug: 26571724
Change-Id: Ie5ec55399e2e3a64b2837ef2c0a7a8a79bd1e49f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ef3aa6ee53c5e4f1c50dd5a9b5821c54e449d4b3 |
|
30-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #28477006: Add small event log to job scheduler
Added. Also fixed dumpsys output when filtering, to apply the
filter to (almost) all of the output.
Change-Id: Iafb446599ad8fddbe8a766784deff618a6cfdbb7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| f07c7b9fd0a640bff4bf7690373613da217fe69b |
|
22-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
API changes for DownloadManager and JobScheduler.
To support moving DownloadManager, add new JobScheduler network type
constraint that matches "any network except roaming." Also add an
API to get a specific JobInfo by ID.
Since the default network can be different on a per-app basis, and
individual apps may be blocked due to app standby, evaluate job
connectivity constraints on a per-UID basis. To implement this
cleanly, add NetworkInfo.isMetered() to match the isRoaming() API.
Add new DownloadManager APIs to support charging and device idle
constraints, which are plumbed through to JobScheduler under the
hood when scheduled.
Add filtering to JobScheduler dumpsys to omit noisy details for
packages the caller isn't interested in.
Bug: 28098882, 26571724, 19821935
Change-Id: I09ca7184ef7ce6adba399f579d415a5fb2ea6110
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8db0fc15b85c6501a0418b17edee2d9c447b408a |
|
12-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #26390151: Add new JobScheduler API...
...for monitoring content providers
We now have some delays before reporting URI changes, to allow
them to batch together.
Also clean up debug output, and fix some issues with how we
were managing the content observer state.
And while I am here, fix the device idle and app idle controllers
to no longer maintain their own list of jobs, but just directly
iterate over the JobStore.
Change-Id: If3fdff23c00c2f1b99901a9be096d851562d3439
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 807de78c072c5a40be7b12c656d641d9e73741d2 |
|
08-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #28035090: Disallow abuse of JobScheduler
We now keep track of how long each app has been running a job
for, in 30 minute batches. If it is running jobs frequently,
we will bump down the priority its jobs run at to allow other
jobs to run before it.
Currently we count both pending and active as the job running,
which means that an app that has jobs waiting in the pending
queue will count against its abuse prevention. This could
allow starvation -- if we bump down the priority of an app's
jobs and the system is so busy continually that they sit
in the pending queue a lot -- it could never recover. But I
think that is okay... if we are really in a state where we
are continually running as many jobs as possible, we probably
have other larger issues.
Change-Id: I838aa4b5840e91df49a1e17b53188d6e4a66a6d1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 141f11c82a2dbf042833f75aeae6f028e8ae2084 |
|
06-Apr-2016 |
Dianne Hackborn <hackbod@google.com> |
More work on issue #26390151: Add new JobScheduler API...
...for monitoring content providers
- Improve media provider change reporting so that observers can
avoid spurious reports of the top-level content directory changing.
- Fix a bug where collected content changes while a job was running
were not being properly propagated to the next job.
Change-Id: I29e3c2960e6fec75b16ee3ee6588d47342bf8c75
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4eb64fdbcf899a81d0a6a04dc3658d03d9df8247 |
|
21-Mar-2016 |
Joe Onorato <joeo@google.com> |
Refactor ProcessStats.
- Pull most of the inner classes out into their own files.
- Move everything to a new android.app.procstats package.
- Move all of the code that was manipulating the big list
of longs to use the new SparseMappingTable class rather
than doing everything by hand. The logic is unchanged.
- Add a sequence number check to SparseMappingTable so
when the big list of longs and the individual tables are
reset, which happens somewhat independently, we can
assert when one of them doesn't get reset.
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| cb926fcec46b111d69059874d63c4cbebb5903c4 |
|
15-Mar-2016 |
Amith Yamasani <yamasani@google.com> |
Move device idle logic into a job StateController
Move most of device idle (doze) logic from JobSchedulerService
to DeviceIdleJobsController.
Allow whitelisted apps to run during device idle by adding
a new constraint DEVICE_NOT_DOZING. Using the word DOZE to
disambiguate from IDLE because the latter is used to mean
that the job wants to run in idle-maintenance period.
Bug: 26851107
Change-Id: I97f5286bd4d5ca18fbc46c2037c310fd369e18bf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2fefbcf0d1b91f37684387971721c90112a9ac89 |
|
18-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #27653326: Sync doesn't work in doze maintenance
Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| a0a58a2fd5cbc1bb8056227bb04f276b364c6e96 |
|
17-Mar-2016 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Refactoring FBE APIs based on council feedback." into nyc-dev
|
| 8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback.
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b1c1f9a7a9808c21c3354a8a9df6c4426634d0ff |
|
17-Mar-2016 |
Christopher Tate <ctate@google.com> |
Fix job duplication bug
Lookup of an existing obsoleted job was not done within the same
lock lifetime as scheduling its replacement, which means that callers
could race scheduling "the same" job and wind up creating duplicates.
Bug 27589164
Change-Id: I572b01092964b82316961de601bb7f1afedf18de
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.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/JobSchedulerService.java
|
| 5d346051bd6da471203fed94357f58491822a4eb |
|
08-Mar-2016 |
Christopher Tate <ctate@google.com> |
Add 'shell cmd jobscheduler run ....' to run a job immediately
During development one needs to be able to test changes conveniently,
and when the jobs would normally have hard-to-simulate constraints
like idle-time or long minimum latencies, testing becomes difficult.
This CL introduces the ability to run a specific job immediately
from the adb shell.
Without the "-f"/"--force" flag, the job still won't run if it has
unmet "functional" requirements such as being connected via an
unmetered network. With that flag, the job will be run immediately
regardless of its declared constraints (so it may not work properly
due to lack of network connectivity or similar).
Bug 27501783
Change-Id: Icc046f53f8846690c8234e60066e85c283d325ce
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 0213ace0140376b90d6824caad3f4035ee25651e |
|
24-Feb-2016 |
Christopher Tate <ctate@google.com> |
Reintroduce per-app scheduled job limits
There was a period of interim deployments during which sync-manager jobs
were not properly attributed to the package whose sync operations were
being driven. This situation is now corrected when it is encountered.
Bug 27335118
Change-Id: Iafc40c80093499447b2e62a4888e3ece0371bfcb
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 77ca74d941eb4addd7051c747362bace0746b7a7 |
|
26-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Merge "Work on issue #26390161: Throttle syncs/jobs when system is low on RAM" into nyc-dev
|
| 12c0da418958c4d8267aa1a5d265d464f78d5465 |
|
26-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Accept non-EA jobs while user is locked.
We'll keep them around in the pending queue until the user is
unlocked, at which point we'll consider running them.
Bug: 27358148
Change-Id: I2eb538a89206d4caac620b3b4e989b011b309201
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 970510b9c5299d480b3ec7f8403afd8265456f87 |
|
25-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Work on issue #26390161: Throttle syncs/jobs when system is low on RAM
We now have a fixed array of job service contexts, which doesn't
vary by build configuration. Instead, we keep track of the maximum
number of concurrent jobs we want to allow to run, and don't
make use of a context if it would put us over that limit.
The available contexts is now 8 (the largest used to be 6), although
the maximum we will normally schedule is still 6. We have the other
two around only for use by the current foreground app, to allow it
to schedule work while the user is in it, even if we have reached
our normal limit on the number of concurrent jobs.
The maximum number of concurrent jobs varies based on the memory
state of the device, from 6 (if memory is normal) down to 1
(if memory is critical). We aren't yet trying to stop all jobs
if memory gets lower than critical.
Instead of just keeping track of whether a uid is in the foreground,
we now track whether it is the top as well. Only the top uid
can schedule additional jobs above the current limit.
Also improved some of the dumpsys output.
Change-Id: Icc95e42231a806f0bfa3e2f99ccc2b85cefac320
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 019f6d9caa7de3c3ebd42ca7fd1a229d74c86e7e |
|
25-Feb-2016 |
Jeff Sharkey <jsharkey@google.com> |
Merge "Fix JobSchedulerService FBE regression." into nyc-dev
|
| 822cbd130fb6c5016c328a9e85b27eb024aef229 |
|
25-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Fix JobSchedulerService FBE regression.
Internally isReadyToBeExecutedLocked() needs to check if the target
service is actually present and runnable. For example, when an FBE
device is locked, we need to keep any encryption-unaware jobs
pending until the device is later unlocked.
Bug: 26279465
Change-Id: I53ff4a2243ebe8a199d0e8dcf87dc3f5b06a2686
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| dabdf6f1bd99529e7b00ad888d2ef5012936f6bf |
|
24-Feb-2016 |
Christopher Tate <ctate@google.com> |
Disable per-app scheduled job limits
Bug 27335118
Change-Id: I6ec92498c1e90e63a650db2a676cfd75dd91aced
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1085ff6ee531931ef7f55cbadbc83616f619b292 |
|
24-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Work towards issue #26390161: Throttle syncs/jobs when system is low on RAM
First, we need to make the job scheduler prioritize jobs for
foreground apps over background apps (so we will degrade well
when we are limiting the number of concurrent jobs).
So now the job scheduler keeps track of the process state of
each uid, and uses that to bump up the priority of jobs
associated with foreground uids. Added constants for priorities
since we have different places specifying priorities.
Also cleaned up a bit of the reporting of "wrapped" jobs from
the sync manager -- there is a new tag argument that can be supplied,
to have the name and tag used in various places be based on that
instead of the useless internal class name.
Change-Id: I8781750ddfac1472a98e1873fc38c014425db3d6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2f36fd6fc94b62b8ccd03cdcea89826d05414f93 |
|
19-Feb-2016 |
Christopher Tate <ctate@google.com> |
Limit scheduled jobs to 100 per app
Packages that are entitled to schedule jobs on behalf of other uids
are not subject to the limit. Also break the JobStore's monolithic
set of jobs into per-uid slices for efficiency and orthogonality.
Bug 27150350
Change-Id: I8f5f718bf200d55f9977a6fc53b7f617e7652ad9
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b0001f6fb1383d9824c2733896b0b348e7f77240 |
|
16-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Remove internal locking from JobStatus.
Now all state of JobStatus is implicitly protected by the lock
of whoever is using it -- in this case the global lock for the
JobSchedulerService. This allows us to remove all of the atomic
variables and just replace those with a simple bit field.
The required constraints for a job are now statically defined
once a JobStatus is created, and don't change. (They wouldn't
change before, but now this is absolutely specified to be the
case.) This required tweaking the constructors a bit so that
the earliest and latest run times are computed as part of the
core class initialization.
Also clarified methods on StateController that are called with
the lock held, and took advantage of that in the various
controllers to not now redundantly re-acquire the lock.
Change-Id: I595c5e7d1bff1bd2ff906d612581af82878a25ee
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 33d31c5b70c7d056e799e34bb6eccbe6939714ea |
|
16-Feb-2016 |
Dianne Hackborn <hackbod@google.com> |
Simplify job scheduler service locking.
Unify all locks to just one lock protecting the entire service.
There is really no need for more complicated locking -- there is
nothing in the code that can take a long time to complete. And
having a single lock will allow various parts of the code to be
much simpler and easier to maintain.
This is just the first step of the change, switching all of the
locking to use one lock. With this done, we can now start
simplifying the code. For example, JobStatus no longer needs
to do any locking (or have atomic variables and such), it can
just rely on its callers holding the global service lock.
Change-Id: I502916ed7f2994b601750c67a59a96b1a4e95c6d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8e64e2e6a4d2964b6a4147f5cccd03de934c86cd |
|
12-Feb-2016 |
Shreyas Basarge <snb@google.com> |
Fixes JobScheduler not persisting flex and sourcePackage
There was a bug with persisteing and restoring flex and
sourcePackage. Fixed it and added tests.
Change-Id: Ie8e4714b4727ecef4254773fd4339b28f4a47c01
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 73f1025f2d01490ca580312cae28279cf614c85e |
|
11-Feb-2016 |
Shreyas Basarge <snb@google.com> |
Fix for JobScheduler dropping periodic jobs
Skip writing to disk when a periodic job is
removed from jobStore after it completes
execution.
Change-Id: Ib4f2cf18554bf9c87138c1984c96cc62f8dbf7e2
Bug: 27147454
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| c7bacab20fa8a0e603726f4f8ebafd3a96babeb1 |
|
09-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
More encryption-aware triaging.
Most of these callers are okay having results omitted when a package
is uninstalled or encryption unaware. For example, jobs and
notifications can only be enqueued by already running apps.
When clearing zen rules, keep around rules inserted by apps on
ejected external storage devices.
Make ServiceWatcher stricter by requiring that the matching package
be in the system image.
Bug: 26471205, 27105254
Change-Id: Ie41ea8042ac1a54e9cbe0c35cec89e70521e9bed
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8c834c07675052c984728cbf79f7c2e0d8246e43 |
|
07-Jan-2016 |
Shreyas Basarge <snb@google.com> |
SyncManager on JobScheduler
SyncManager now uses JobScheduler for scheduling
and persistence purposes.
Change-Id: I38c92aedbf4d891ca297644d0b706835aaedfcd6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1a30bd9b13fd127d9bbfdc5fd4cb2f80ab7ece21 |
|
11-Jan-2016 |
Dianne Hackborn <hackbod@google.com> |
Add and implement JobScheduler content observer APIs.
Allows one to schedule jobs to run when content URIs
change, and find out what changed when the job executes.
This required adding a new API to StateController to
tell it when we are about to start executing a job, so
we can transfer the currently collected changes out of
its internal state to fill it in to the JobParameters.
Also some additional dumpsys debug output to help
understand what is going on in the job scheduler.
Change-Id: I91f51b226ff4add7a271a8333beffa5e86c7bf18
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 3dbb412c94b91a2f8f130c32417621d138c3f7ec |
|
19-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Merge "Fix for possible NPE in JobScheduler"
|
| 968ac75c2048214a28e9eac3d0e2e0d23776f887 |
|
12-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Adds sourcePackageName field to JobStatus
Platform apps can schedule a job on behalf of
some other package. Battery stats and appIdleState
will be computed using sourcePackageName.
Change-Id: If52f6e1db3a563ef0854d1f59fbc6088a0c29ad1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 347c2780aab9dbacb7e0336d3585890647187bf4 |
|
15-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Fix for possible NPE in JobScheduler
Fixes a possible NPE in JobScheduler
Change-Id: I4faa414ea92ab65326001f83de4624834b5ed955
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 17971e383f97db0d398b86ae537448605f70894e |
|
15-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Merge "Added priority to JobScheduler scheduling"
|
| 5db09084c8e4efc6311754243c39962fc8e7a766 |
|
07-Jan-2016 |
Shreyas Basarge <snb@google.com> |
Added priority to JobScheduler scheduling
Priority can be assigned to jobs. Higher priority
jobs can preempt lower priority ones. Reason for
calling onStopJob (timeout, preempt, etc.) is set
on the JobParameters object.
Reference:
https://docs.google.com/document/d/1fuVO5rBCkODx8wjk6uulFCP1Uzfx7IVsw2EyKKrGqVA
Change-Id: Ic36016514cec076984d44086316d8d00d896b3aa
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 89ee618280ea05e193afab38f9d2bf99b8274a92 |
|
17-Dec-2015 |
Shreyas Basarge <snb@google.com> |
Flex time for periodic jobs in JobScheduler
A periodic job will start only within time
satisfying period - flex < time % period < period.
Bug: 26254850
Change-Id: I97a840446e5592e5151d784800855d909f1790b8
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2f3e35376ada0327b34a71d7c45ac6e6d955d7dc |
|
21-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
More work towards triaging missing app behavior.
Many places across the platform query package details without
gracefully handling packages or components that go missing for
various reasons. This can cause annoying user data loss, such as
resetting back to built-in apps or dropping of accounts, etc.
This change verifies that system callers have thought about these
edge cases by logging if they use default matching behaviors without
explicitly marking themselves as being "triaged." (The logging is
currently disabled by default.)
Also creates explicit definitions of supported flags for various
incoming PackageManager calls, and defines a clear distinction
between flag types:
-- GET-style flags are used to request additional data that may have
been elided to save wire space.
-- MATCH-style flags are used to include components or packages that
would have otherwise been omitted from a result set by current system
state.
There are a handful of existing GET flags that better fit under the
MATCH definition, so this change clones them to new constants and
marks the old ones as deprecated.
Fixes bug in JobSchedulerService to consider jobs from apps on
external storage. Revert some dialer behavior back to being
untriaged.
Change-Id: I9b6ab0968241e3479bddbd78de0c51e3b9917318
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5217cacbd9f382068bb9e176cd5a0b15388a335c |
|
20-Dec-2015 |
Jeff Sharkey <jsharkey@android.com> |
Make JobSchedulerService encryption aware.
When a user is started, but a persisted job component doesn't appear
in the normal resolution list, we avoid enqueuing the job. Later
when the user is unlocked, we take another pass over the pending
jobs to see if they became available.
Load keyboard layouts from XML metadata regardless of crypto status,
since we don't need to spin up any remote code.
Add MATCH_SYSTEM_ONLY to make system logic easier to write when
looking for trusted components.
Sprinkle more annotations on ArrayUtils methods.
Bug: 26279465
Change-Id: Iec28e0bb46862b07d740b12a79f6360de68dab0f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4cff8ac60ddc6f3838e51c61ee13e67d5aacdf7a |
|
10-Dec-2015 |
Shreyas Basarge <snb@google.com> |
Scheduling fix for JobScheduler
All ready jobs are now queued for execution when
a job completes execution or when a job becomes ready
and some other job is being executed.
Also fixes reporting of idle state.
Bug: 26131545
Change-Id: Ibadd95a31869e610c63fc147f9b10866a7439ac6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| bef28feba57be7fd6a4d14a85a8229154338b2ed |
|
30-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial stab at background check.
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 627dfa1ddafc96b912ae938677a48a16f7ab255c |
|
12-Nov-2015 |
Dianne Hackborn <hackbod@google.com> |
Be smarter about determining when we can stop idle maintenance.
The device idle service now knows when the system is actively
doing significant things (syncs, jobs, alarms, downloads). It
uses this, when in an idle maintenance window, to determine when
it can end that window early -- when such work is no longer
happening.
For now this just allows us to shorten the windows. In the future
we should use this to allow us to expand the windows to a longer
potential time, adjusting future windows to shorter durations if
earlier ones use more time. This will allow us to batch occasional
long operations (such as downloads) into one window, making up
for that with much shorter later windows.
Change-Id: Ie482abd50bc43be9a8917a769a5175851eee4ec4
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ccbf4e421189f60f94edbc6957a3ef125fb5e0b4 |
|
20-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Initial implementation of light-weight idle mode."
|
| 08c47a5dece977a55d250d98bda9e2a8df8b6ed0 |
|
15-Oct-2015 |
Dianne Hackborn <hackbod@google.com> |
Initial implementation of light-weight idle mode.
This mode turns on after the screen has been off for 15 minutes,
and then cycles through 15 minutes of idle and 1 minute of
maintenance, ragardless of whether the device is moving around.
It currently only impacts network access and sync/job scheduling.
It does not remove access to wake locks or alarms for any apps.
It also doesn't report in the public API that the device is in
idle mode (since it isn't modifying the behavior of the power
manager) -- this is probably what we desire, since we don't want
stuff like GCM to be reporting these frequent changes.
We'll probably at least want to have the alarm manager do some
kind of more aggressive batching of alarms in this most (not allowing
more than one wakeup every minute?). That's for the future.
Also updated batterystats to include this new information, which
means the format of some of the data has changed -- device_idle
is no longer a flag, but an enum of (off, light, full), and there
is no information about time spent in light modes.
Also added new data about the maximum duration spent in both light
and full idle modes, to get a better understanding of how those
are behaving.
And did a little cleanup of DeviceIdleController, removing the
sensing alarm which was redundant with the regular alarm.
Change-Id: Ibeea6659577dc02deff58f048f97fcd9b0223307
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| aa9843198dec910a581bdc509d3937a9ea6ceca9 |
|
16-Oct-2015 |
Matthew Williams <mjwilliams@google.com> |
Change scheduling logic to run network jobs sooner
BUG: 24385082
BUG: 23144425
BUG: 18117279
Run jobs with connectivity constraints as soon as the developer-allotted
delay has expired, rather than waiting for the override deadline. This
is more in tune with what developers expect, although it reduces the
amount of batching the scheduler can theoretically do.
This will also have the side effect of fixing several failing cts
tests that started breaking b/c the signal to 'run connectivity
jobs early' was removed in M and nothing was put in to replace it.
Change-Id: I7e63c2b62f2882ee906f748445bbf10c32e19c5f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 1bde39ad1424008917e1191565f81e0b4617f2fa |
|
07-Oct-2015 |
Matthew Williams <mjwilliams@google.com> |
Correctly reschedule failed periodic
BUG: 24341715
Failed jobs are rescheduled with no override deadline to avoid
running a failed job with unsatisfied constraints.
A periodic job always has an override deadline and the periodic
rescheduling code assumes this.
Hence a periodic that failed until eventual success would be
rescheduled in a bad state.
Change-Id: Id110b3522df2003506a9efdde4e719e1b9932106
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| b0ff32245cb6b51e43dd3ee40b86d683c62de2b9 |
|
04-Mar-2015 |
Amith Yamasani <yamasani@google.com> |
Throttle jobs for idle apps
First pass at delaying jobs from apps that are idle.
TODO: Throttle syncs
TODO: Provide a periodic point at which apps are checked for idleness.
Apps that switch to foreground process state are tracked by UsageStats
as an INTERACTION event that affects the last-used timestamp.
JobScheduler's logic for when an app is ready is trumped by the idleness
of the app, and only if the battery is not charging. When charging state
changes, we update the idle state of all the tracked jobs.
android package is whitelisted.
Bug: 20066058
Change-Id: I0a0acb517b100a5c7b11e3f435f4141375f3451f
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 2bf51f47d9e1b8563b58ce5ebde2f609d728fbf3 |
|
24-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix loop index.
Change-Id: Ib6827d58b3fec59f757f1051fb9a353da0c90c30
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 88e98dfa59e68a860d8c3b462ec03bc0b06d6b5c |
|
23-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
More work on device idle mode.
- There is now an API for people to find out about
its state.
- Moved DeviceIdleController to be closer to the
power manager implementation, since they are
closely related.
- Job scheduler now knows about idle state and doesn't
run jobs while the device is idle.
- Battery stats now keeps track of "idling" vs "idle mode".
Idling is when we consider the device to be idle,
independent of whether we are actually in deep idle mode.
This allows us to keep track of longer-term changes
independently of cycling in and out of idle mode.
- Battery stats also now keeps track of package changes in
its daily stats.
- Small optimization to network policy manager service to
not touch uids that do not have the NETWORK permission.
Change-Id: I0b3304fb3722c78cdfdd0c1eada7369ece7cbcf9
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 8ad2af7e5b28f71e7bdfc1bb097937c6c1d22b18 |
|
18-Mar-2015 |
Dianne Hackborn <hackbod@google.com> |
First stab at device idle mode.
Introduce a new device idle controller service that
monitor's the device state and determines when to go
in to idle mode. When in idle mode, all we do right
now is turn off network access the same as we do for
power save mode. Many more things should come in the
future -- stopping the alarm manager from scheduling
(most) alarms, telling GmsCore for it to stop doing
stuff, etc.
Battery stats now has state tracking for devie idle
mode, as well as events for the reasons we can come
out of idle mode (significant motion or the device
becoming active). Also added new events noting when
packages are installed.
Renamed the "low power" event in battery stats to
"power save" because the former was just way too
confusing.
Finally, fix buffer size reading kernel wake locks.
(Stupidly, just increasing the buffer size. Ideally
we should try to be smarter and grow our buffer to
fit the data available, but I'll leave that for
another time.)
Change-Id: I0be2062466c83ee9d890c6cf5a228d9cc4090eca
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| aad67a3e48ad1dc9a917e036f98021c6e4d1f748 |
|
21-Oct-2014 |
Christopher Tate <ctate@google.com> |
Don't cancel scheduled jobs when packages are updated
Only cancel the app's jobs when it is fully uninstalled, not when
it's being updated to a newer version.
Bug 18059252
Change-Id: I6cf617013ec8e9e9abd90e366d7a6ab0711790de
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 326f230ceba67a9b72d2606f7c503bef6f938ddd |
|
08-Oct-2014 |
Georgi Nikolov <geonik@google.com> |
BUG 17887323: Need to turn off DEBUG log spam in Job Scheduler
Change-Id: Ida7af915c5b616216692493434b63c521398dfb0
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 48a30db75dd0eedf8e065c89825b2af86a381b62 |
|
23-Sep-2014 |
Matthew Williams <mjwilliams@google.com> |
Fix lock ordering in JobScheduler
BUG: 17625667
Two part clean-up.
1) Don't try to lock in onControllerStateChanged. Do it in the handleMessage
instead where the rest of the locking is. This is sufficient to fix this bug.
2) The other side of the deadlock came b/c we lock when cancelling and calling
stopTrackingJob. Controllers handle their own locking so this isn't
necessary. B/c of a potential race from the controller side, added an explicit
check for the JSS to only run an expired job if it still exists.
Change-Id: Iaeebbc19437eb5b73e3ced3168f1fc13e564a4be
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 75fc5258b73b4b9b079a9383420a1d6b88575d72 |
|
03-Sep-2014 |
Matthew Williams <mjwilliams@google.com> |
Add timeout when waiting to bind to JobService
BUG: 17322886
bindService() to an invalid service might never actually result in
onServiceConnected being called , for e.g. if the client service doesn't
actually implement JobService. This wastes an execution slot as we end
up waiting forever.
Also made the javadocs clearer for the JobScheduler class.
Change-Id: Ie15ebbe18c0b7579f2ab77dd46428d354ef632c3
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| f973a7b17135535528ae6e792d38d4bf081b44c4 |
|
29-Aug-2014 |
Christopher Tate <ctate@google.com> |
Expand job scheduler dumpsys a bit
Now it actually says what jobs are active.
Bug 17322886
Change-Id: I1a0fe0bf8d4cb2988cc89a11793981037157ee07
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| d1c06753d045ad10e00e7aba53ee2adba0712ccc |
|
22-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
Implement API review feedback for JobScheduler
BUG: 17005336
Took the opportunity to clean up some back-off logic
Change-Id: Ibc8ae34d1d44dd064ba071e4cbad17872f7e38cf
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 9ae3dbeefcd6bc139c74bfe3d51de823e3be4b4b |
|
21-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler only run jobs for started users.
BUG: 12876556
Minor changes to test app to make persisting an option.
Change-Id: I1b40347878ec5ca44cd717ebfeb544f6c58473b5
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| bafeeb98135a7580cbcdd657818cd78f7bda35d8 |
|
08-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler needs to flush queue on charging
Also make it illegal to schedule a job with no constraints.
BUG: 16877705
Change-Id: Iae57286bc4f73163a7e3c9d2d531623fd50f1f72
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| be0c4175398ff5d7e13209e833b3037cdd0207d7 |
|
07-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
JobScheduler idle mode not being properly triggered
Issue with how the pending intent was being created -
the component name being explicitly set on the intent somehow
caused the intent to not be delivered.
Fix: no longer set the component name on the intent.
BUG: 16798118
Change-Id: I86b08b2a47067dc9b8da8b85450bc338e0826aca
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| ee410da42b6b8352213f03f7725fd041f703b035 |
|
25-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
remove possible JobScheduler race in cancel()
Client can jobFinished() before getting a cancel msg.
1) Do better clean up of JobServiceContext after client jobFinished()
to remove superfluous MSG_CANCELs
2) When processing MSG_CANCEL check whether the context is still active
3) Do JobServiceContext cleanup before calling back to JobSchedulerService
Client can get a cancel msg even after calling jobFinished() (opposite to above)
1) explicitly check whether there are any MSG_CALLBACKs in the queue before
processing a MSG_CANCEL. If there are we can throw away the cancel.
Bug: 16547638
Change-Id: I90644586c7895a9ce97de752a5d657faf7f74b78
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 01ac45b6ff2334925c8d24b5278b44e5e30f5622 |
|
23-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
Fix JobScheduler race condition
The loading of jobs from disk is now done sychronously.
Bug: 16372824
Change-Id: Ica0592d6de51e89662c9e49ed1eb59209b64356c
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 4a79daeaf72fe0c47f9d0605d6efe0c61885fe94 |
|
19-Jul-2014 |
Christopher Tate <ctate@google.com> |
Fix which index goes where
Change-Id: If4cf7efd4d7962eb5c10b487482653d86d92d2c6
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| fdb1956ff71ff57fcdaafaaeb7f42c19de3d7c2f |
|
12-Jul-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #15681802: Missing RESET:TIME in complete battery histories
But wait, there's more!
- Keep track of sync durations in the aggregated stats.
- Add events for users that are running and in the foreground.
- Rework the activity manager's tracking of stuff using
battery in the background to be based on proc stats, which
allows it to be better about determing when it should reset
its tracking of background work.
- Also add tracking of scheduled job execution, like we are
doing for syncs.
- And once I started hooking battery stats in to
JobSchedulerService, I found a few things I couldn't stop myself
from changing: (1) make it very explicit that it doesn't start
scheduling jobs until we have reached the point in system boot
where third party apps are allowed to run, and (2) adjust
the various for loops to not use iterators.
Change-Id: I69d812e27bcfee9e58a614f0f6b1c7545d7530b1
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 900c67fc51fc2672458dd1c9641250f2ecc01a31 |
|
09-Jul-2014 |
Matthew Williams <mjwilliams@google.com> |
Add job persistance as a setter in the API
Bug: 15936795
Change-Id: I11e5a722bab5838dc151670256ed09dfaa7fdaa7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 5568f54e14e213ac100cacbbf57689faa6dd3d59 |
|
18-Jun-2014 |
Christopher Tate <ctate@google.com> |
Fix job service validation in secondary users
Bug 15714663
Change-Id: I101bcc979f30062bec36f462522227b857b58054
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|
| 7060b04f6d92351b67222e636ab378a0273bf3e7 |
|
10-Jun-2014 |
Christopher Tate <ctate@google.com> |
Out with the old; in with the new
Switch to the official "JobScheduler" etc naming.
Bug 14997851
Change-Id: I73a61aaa9af0740c114d08188bd97c52f3ac86b7
/frameworks/base/services/core/java/com/android/server/job/JobSchedulerService.java
|