Previously the crunch command would work on a full res folder
and output a full res folder (with only the drawables). This
was only used in the SDK.
The incremental logic is moved to the SDK build system so we
change the crunch command (or rather add a new one) to only
crunch a single file.
(cherry picked from commit b1f6ad82dd8d1702617a757a88430604b3131fac)
Change-Id: I3653f67ee321eac37cb8a6d228b1ef6d104ff0be
They previously duplicated the full logic of getString(key) and
getCharSequence(key) independently. Now they both use the no-default
version internally, resulting both in a single point of implementation
for test & isolation purposes and in a (small) decrease in code size.
Change-Id: If1b1e1fa4a549a0ec4cf221e54998f4fd438f3a2
systemReady() was returning before the LocationManagerService was
actually ready. Applications making LocationManager transactions
during their startup could possibly hit a race condition with the
yet-uninitialised LocationManagerService.
To guarantee that LocationManagerService is actually ready before
returning from systemReady(), we simply do the startup work on the
thread that called systemReady(), rather than spin up a secondary
thread to do the work asynchronously.
LocationWorkerHandler still needs a thread to do its work on, so
rather than have it run on the secondary thread that was
previously used for systemReady()'s work, we create a HandlerThread
for it.
Additionally, LocationManagerService.init() really needed to grab
lock for some of the things it was doing. I moved all of the code
that could benefit from mutex protection to a single section of
systemReady() and wrapped it up with a lock while I was at it.
Bug: 7723944
Change-Id: I51d480e2781622c3a14769c3a2019a2407dcfd8a
The remote control stack in AudioService is responsible for handling
which application receives media button events. When an application
"registers" its media button receiver, it gets placed at the top
of the remote control stack. If the app also has audio focus (is
at top of focus stack), this will also cause the information of
the attached remote control client (RCC) to be displayed on the
lockscreen.
If an app doesn't re-register its button receiver when it wants
to receive the button events, it might have lost its place at the
top of the remote control stack, and would not show up in the
lockscreen anymore.
This change consists in using the playstate reported by the RCC
to change the remote control stack. If an RCC reports a "playing"
state (e.g. playing, fast forwarding), it is safe to assume the
application is actively being used, and should be the one that
receives the transport control buttons. This CL uses the reported
playstate to conditionally move the corresponding stack entry
to the top of the stack.
Bug 7311023
Change-Id: I1505f01664c16e108b22d33e3f47f0056343676e
Iterate of remote control stack entries from the top of the stack
for cases where the condition being checked is more likely at
the top of the stack, as opposed to the bottom, which is first
accessed when using an iterator.
Change-Id: I625bee59021c2d652e9d6355b48dc0c11e36093f
Previously the crunch command would work on a full res folder
and output a full res folder (with only the drawables). This
was only used in the SDK.
The incremental logic is moved to the SDK build system so we
change the crunch command (or rather add a new one) to only
crunch a single file.
Change-Id: I635ee3e871d035b9db2fb593802d914e48241abf
Iterate over the remote control stack from top to bottom
when (un)registering a remote control client (RCC).
When unregistering an RCC, stop traversing the stack when
match found. If match was at top of the stack, update
the remote control display (RCD).
Change-Id: If64acf102bdf328085d707f9e0f7e86cf4d4001a
