tree aae8983e62d1417a6e60944a4103023792b4c139
parent 4a306894145340a4fe08b70b569eaa31641b38e6
author Dianne Hackborn <hackbod@google.com> 1491351455 -0700
committer Dianne Hackborn <hackbod@google.com> 1491944235 -0700

Add new "work queue" feature to JobScheduler.

This gives semantics similar to the start command
queue of services.

The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.

This includes a first step of adjusting/fixing locking
within JobSchedulerService.  The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler.  However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.

The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL).  Right now we have
the locking, but still also the handler.  But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.

Test: new tests added

Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03