Fix Slog.wtf to not acquire the activity manager lock in its code
path, so that it can never deadlock. This was the original intention
of it, but part was missed.
Now we can put back in the code to detect when strict mode data is
getting large (a little more targeted now to the actual problem),
and use Slog.wtf to report it. And as a bonus, when this happens
we will now clear all of the collected violations, to avoid getting
in to the bad case where IPCs start failing. So this should be
good enough for L to fix the problem, with wtf reports for us to
see if the underlying issue is still happening.
Finally, switch a butch of stuff in the system process from Log.wtf
to Slog.wtf, since many of those are deadlocks waiting to happen.
Oh and fix a crash in the settings provider I noticed in APR.
Change-Id: I307d51b7a4db238fd1e5fe2f3f9bf1b9c6f1c041
Some system apps doing hotword training need low-level access to
audio hardware, beyond what the existing HAL offers. For now, give
them the audio GID.
Bug: 17763721
Change-Id: I8025c3abacae13a6ffec4e10e4976a67ab505bdf
+ adjusting spot and ambient shadow opacity constants to achieve desired appearance
+ reducing ambient scale ratio back to 1.0 to address over-lightening at higher elevations
+ partially revert ag/546290
Change-Id: I9d7f664f73a7b9b83df73b739103c97054bd4f6e
There was a path through idle where we could clear mBooting but not set
mBooted, so we would no longer start activities. This is probably happening
because if you start a user or userdebug build with the device plugged in
to adb, the system early on starts the USB security dialog, before home is
started. If that goes idle first, we will end up in the case where we
clear booting (because something went idle) but not set booted (because it
was not home that went idle).
Change this so that we always set booted when clearing booting.
Change-Id: I40053710eefa939315aeb9475ecdd2e8a87351ff
Accessibility introspection APIs are meant to query only the state of
the current user. There are command line tools that run as the shell
user and want to be able to intropspect the screen. When resolving
the calling user we were using the calling user id instead of the
special constant for the current user.
Now when resolving the calling user for intrspection we are using
the current user constant and consequentially only the current
user or a profile of the current user or the root or the shell or
the system or an app with cross user permission can introspect the
screen.
bug:17674631
Change-Id: I36d1d7b65441d04c3b4204123c4b6d036ff032c0
Added a new SLEEP_TIMEOUT setting which governs how long the device will
remain awake or dreaming without user activity. By default this
value is set to -1 which maintains today's existing behavior.
We basically represent the time we are allowed to be dreaming as a new
kind of user activity summary state called DREAM, similar to BRIGHT
and DIM. When the sleep timeout expires, the state is cleared and
the dream ends.
Bug: 17665809
Change-Id: I59aa7648dcec215f1285464fc1134934a09230e5
Avoid waking up the device on hw vol key presses during a doze
pulse. Instead, behave as if the screen was off for these keys,
namely forwarding them over to the session manager.
Bug:17672775
Change-Id: I566b93f0bdea79253ac3eca41d3876b271c61306
- Fix regression with launching an affiliated task due to clipping changes (Bug 17755902)
- Tweaking previous changes to home transition
- Disable the debug mode option
Bug: 17578553
Games seem to be doing this to prevent destruction of their
GL contexts, and they assume it works even if it doesn't. However,
GLSurfaceView is clunky here, so while the app is doing something
questionable we don't really offer a better way. For now revert
back to kitkat behavior.
Change-Id: Icfa9e496279b9cfa47f9bc7f6848d9313caed0d5
Previously if an activity requested to keep running behind
translucent activities (Activity.requestVisibleBehind()) and then
converted itself to opaque (Activity.convertFromTranslucent()), we
would clear the visible-behind activity. This change tests to see
if the top activity is the visible-behind activity and does not
clear it in that case.
This change also clears the visible-behind activity whenever it
comes back to the front. That forces the activity to call
requestVisibleBehind() each time it is resumed.
Fixes bug 17648436.
Change-Id: Id0fc4d7e2a2b907675305d98bad1b08cb610919e
Allow events through if configured, and use a switch
for separating mode-specific logic.
Bug:17580878
Change-Id: Id7b5d8b50173015d6a78568ed0a90e0bccf98549
