| 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/IdleController.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/IdleController.java
|
| 7234fc6fef781e33842bc598a6e9e04bbff4f898 |
|
04-Apr-2017 |
Christopher Tate <ctate@google.com> |
Track pending job latency
Timestamp jobs being marked 'pending' and 'active,' so we can then report their
pending latency in dumpsys.
Bug 35385393
Test: N/A
Change-Id: I3d981fbc7fbe6abdf30da3f86d88d3733b797f51
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.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/IdleController.java
|
| 27d92e4e397728d56f4f951dd4ce99668c7c447b |
|
06-May-2016 |
Christopher Tate <ctate@google.com> |
Move the 'pretend idle jobs can run now' broadcast into AMS
It's a protected broadcast, so sending it directly from 'am' is
no longer an option. This is needed for CTS as well as being
generally useful during app development.
Bug 28406044
Change-Id: I101915a8c6f19454330a8db2079a75023c112582
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.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/IdleController.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/IdleController.java
|
| 0529dac587b1361eac359737a5f10972bce5fd0d |
|
15-Mar-2016 |
Shreyas Basarge <snb@google.com> |
Fix for JobScheduler jobs not running
If the device is powered off when a job is
supposed to run, its delay and deadline both
are set to 0 on boot. If the deadlineExpired alarm
runs first, the job is discarded from
TimeController's tracked jobs list. The delay
constraint is never set to true and the job
would never be executed. This behavior is fixed
here.
Dump modified to print jobId and uId instead of
hash to make it more meaningful.
Bug: 27619643
Change-Id: If03e3d6f194f15fe43b697dcb4198137fa7ed646
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.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/controllers/IdleController.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/controllers/IdleController.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/controllers/IdleController.java
|
| ca5edbb6b5300e07a5f7bfbec36f08df65d8f6e7 |
|
13-Jan-2016 |
Yao Chen <yaochen@google.com> |
Changes in DeviceIdlecontroller and JobScheduler to support Auto GarageMode.
Changes made in the cl:
1. Let DeviceIdleController take listeners on whether background
maintanence services are active. This currently includes JobScheduler,
SyncManager, DownloadService. Note this is the last known
states reported by these services.
2. In JobScheduler, make the idle threshold and alarm window configurable.
So in the car case, we don't need to wait 71 mins after screen off
to kick off any jobs that require device idle.
-------------------------------------------------------------------
* We are not going to suppress JobScheduler, DownloadService, SyncManager
entirely while user is driving. Because apps may not be working properly if
these services are suspended.
* The jobs that we don't allow to run while driving are the
jobs submitted to JobScheduler that require device idle.
And this is already taken care of, because
screen is ON and JobScheduler will not consider the device to be idle
while driving (unless user turns off the head unit).
* We will need to give the JobScheduler a chance to run the device idle
jobs when car is turned off. This is the scope of GarageMode. If
DownloadService and SyncManager want to run, we will allow them to run
too.
* The headunit is treated as wall power device, so it's always charging.
The charging state will not toggle.
Change-Id: I55b92cf92efd61c48dd6c9b8197c2b68078a4439
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.java
|
| e20725889b01ede46b15a1070ceb2040e2e26865 |
|
04-Aug-2015 |
Matthew Williams <mjwilliams@google.com> |
am b3448bf1: am 608ad140: Merge "Idle Job Start During SCREEN_ON or DREAMING_STOPPED"
* commit 'b3448bf1379b7c13125973cdcc33173741baeaae':
Idle Job Start During SCREEN_ON or DREAMING_STOPPED
|
| ccfe87356fb961a4e85e4fce7cc5e0fac410f131 |
|
30-Jun-2015 |
Kevin Zhu <kzh@amazon.com> |
Idle Job Start During SCREEN_ON or DREAMING_STOPPED
When the screen goes off or dreaming start, an alarm will be
scheduled and idle state will be true when the alarm expired.
If the screen goes on or dreaming stop happens before
the alarm expired, the alarm isn't cancelled and idle state is
set to be true when the device is in SCREEN_ON or DREADING_STOPPED
state. There is also a case that Idle alarm triggered when
the screen on or dreaming stop just start to be processed.
ACTION_TRIGGER_IDLE will set mIdle to true during screen on
or dreaming stop.
In this patch, the alarm will be cancelled when the screen goes
on or dreaming stop and screen-on flag will be set. So the idle
state can only be set when screen is off or dreaming started.
Change-Id: I06ae4b7fd77901f9570ce0459d2299bbfd4b46b4
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.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/controllers/IdleController.java
|
| 5eeb59cceb1f95813c548c1c5937f161c1ed3571 |
|
22-Jul-2014 |
Christopher Tate <ctate@google.com> |
Schedule full backups
Initial policy: at most daily; backups only run when the
device is idle + charging + on an unmetered network.
Bug 16485874
Change-Id: I5665d890a943bac765adcef14be79d7dba6ce078
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.java
|
| b9583c9d93bd1d2c9d506dffae87a5ca2b7f7307 |
|
25-Jul-2014 |
Christopher Tate <ctate@google.com> |
Turn on debugging override of idle time
'adb shell am idle-maintenance' has traditionally been used to force
the system to consider itself to be in an "idle" state. Unfortunately
the new Job Manager hadn't yet been aware of this. Rectify the situation.
Also fixes a bug in debug logging that would cause a system server
crash under certain race circumstances.
Change-Id: I8a29bd7757924f8e464865235c344233fc03d8c3
/frameworks/base/services/core/java/com/android/server/job/controllers/IdleController.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/controllers/IdleController.java
|