This change merges debug.hwui.profiling and profiling_visualize.
Now only the first property exists and accepts the values true, false
and visual. This enables setting the property from Settings.
Change-Id: I16a11fe23ac1a6bb907a1a826e418d6b3994b56c
When profiling is enabled with debug.hwui.profile set to true,
setting debug.hwui.profile_visualizer to true will display the
profiling data directly on screen.
Change-Id: I3d5fe3f0347090815087b1cbfce66b8e76d9347b
Bug #7728929
The uninitialized variable was taken into account to compute
the hash of gradient cache entries, thus causing cache corruptions
and sometimes infinite loops (it would also cause the cache to fill
up.)
Change-Id: Ic807a9bf901888b121a6a781a81dafc33075ed2a
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
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
