| 6466c1cc5efc4ff05fabdd670cf78a6a7ca45afb |
|
13-Jun-2017 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #62390590: SecurityException in JobIntentService$...
...JobServiceEngineImpl$WrapperWorkItem.complete
When a job is in the process of stopping a job, we should no
longer allow new work to be dispatched for it.
Also there was an issue with how we determine wether a caller
is valid for the current job -- this was only based on the uid
of the currently running job, but of course that context could
be re-used for a new job of the same uid. Instead, we now create
a different callback binder for each client, so we can identify
the exact client each time it calls back. (This also allows us
to hang information about why the job last stopped on that
client state, so we can always report it.)
Finally make a bunch of classes final that should have been.
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I1b00dd2da710414dd2898c4d39a5c528d54b95ea
/frameworks/base/services/core/java/com/android/server/job/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.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/controllers/DeviceIdleJobsController.java
|