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/GrantedUriPermissions.java
|
342e6037109a53830277d8de6ecf0e39578c143c |
|
14-Apr-2017 |
Dianne Hackborn <hackbod@google.com> |
Finish impl of job queue: handle URI permissions. The job queue now handles URI permissions associated with the Intent of each job. Just (kind-of) like Service! Also do the second pass of locking in job scheduler, getting rid of all the async dispatching on a handler, and just executing calls right in line with simple locking. This probably fixes a few other race issues, and allows us to make sure that we always finish a job correctly when dequeuing the last work (we will always atomically dequeue and finish, so no new work can slip in between). And fix a little debug output in IntentFilter. Test: ran CtsJobSchedulerTestCases, added new test for URI perms. Change-Id: I52f700ef0cd5be3ff70050f9c0f5fe3e8a5ccac1
/frameworks/base/services/core/java/com/android/server/job/GrantedUriPermissions.java
|