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/StorageController.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/StorageController.java
|
532ea26c7b66180b09524f96da8bca1110f41197 |
|
18-Mar-2017 |
Dianne Hackborn <hackbod@google.com> |
Add new "storage not low" job scheduler constraint. This allows you to say that your job should run only when device storage is not low. Adds new command line interface to DeviceStorageMonitor to help with driving the tests (modelled after BatteryService). Test: new StorageConstraintTest suite. Change-Id: I96bfb761cd8257b6f68dde43ce9cfb1a3b9d0acb
/frameworks/base/services/core/java/com/android/server/job/controllers/StorageController.java
|