When 2 notifications were posted as the summary of the same
group, then the system would eventually crash.
Bug: 23676310
Change-Id: Ia8f95e624f3f43d1b55169dd8102e3c89427dc76
Previously the notification effects were not correctly cleared in certain
cases and the user could end up in a state where the notification light would
always blink.
Bug: 22931139
Change-Id: I9a71e56cf4479354a9d773b5b6f0edd7693f2b05
b/23431496. This change will not launch the Intent if the target app of
this Intent is already running in the foreground.
Change-Id: Ic8c99cf3312a2ead12dbdb94825181aed934e9f0
When telling window manager that Keyguard window is in the correct
state for a fp-touch-to-wake sequence, it takes more than 1 frame at
the moment because the signal that WM is waiting for the next draw
is delayed by one frame because it is posted at the end of the
runnable queue.
To correctly fix this, we should post it at the beginning at the
queue, but this is way too risky this late. Instead, add a isolated
SysUI hack to report it faster.
Bug: 23401557
Change-Id: Icf64101e27611c7c01d108123021b22186f1e70c
The GestureLaunchService now informs systemUI that a launch
has been requested and the systemUI, depending on its state
will launch the Camera in the correct mode, including
animations.
Bug: 22957192
Bug: 22958025
Change-Id: I815437c8bd33638245ac61a750f64af74fe3e1e3
If the given app name is too long for the permissions dialog, then
it can push the warning that the application will be able to record
the screen below the fold, letting the app basically set its own
dialog message in a way that a user would be difficult to detect as
fraudulant.
Bug: 23345192
Change-Id: If5881ca75d5c155ef5174351d245dbc3abdaa584
- When wake-and-unlocking, make sure to skip the light status bar
transition.
- Fix race condition with window manager when unlocking when device
is interactive for supplying the timings for the light status bar
transition.
- Fix media artwork when wake-and-unlocking while pulsing.
Bug: 23365544
Change-Id: I209ca1e6684811f5f313354ca1614a0ebd49388c
Split off from I0af11da1b7cd7c8d837bc5ba3a62ef2ffca74b1b.
The initial value did not matter previously because
a SystemUI crash triggered the boot logic and forced
a manual entry before fingerprint works.
Long term the timeout logic should be moved to StrongAuthTracker
so it can be shared with the trust agent implementation (currently
implemented by the trust agents themeselfes)
Bug: 22846469
Bug: 22115393
Change-Id: I0af11da1b7cd7c8d837bc5ba3a62ef2ffca74b1b
There is jank at the beginning of the transition when the heads-up
disappears when clicking, because a lot of stuff is going on. In
order to make it consistent with other notification clicks in the
shade, introduce a delay for the disappear animation.
Bug: 23365512
Change-Id: Ib7c5db552d6803f96374198c2af38cf8236769cd
- Scrims: When dismissing Keyguard, don't wait until the next frame
to start the animation. Saves 16ms
- Scrims: Skip first frame, because it's completely black anyways.
Saves 16ms.
- Don't wait with navigation bar to show until the screen has turned
on. Window manager is blocked on DisplayPowerController anyways, so
the animation will exactly be started when the screen turns on. Fixes
some jank as well.
- Window manager: Don't wait for the window below Keyguard for draw
completion until turning on screen. Saves a lot of time depending on
how the app is behaving.
Bug: 23401557
Change-Id: I9734f9a12143f0e3c0647e9aa066831a29a6de63
- Don't hide keyguard after the animation is done, because this
would cause a measure in the middle of the fade animation.
- Don't use a layer for the notification panel in this case - we
don't need it and it only adds latency.
- Speed up the whole thing a bit because the animation is now
smoother.
Bug: 23225107
Change-Id: Ie8264c4d0e62bd6a78227e04b9900b4348ddd649
- Move all fingerprint related to logic in on central class in
SystemUI that knows all the state of the UI so there is exactly ONE
place in which we decide what to do when we acquire a fingerprint.
- When pulsing and we get a valid finger, we fade the contents of the
Keyguard out and fade the scrim out almost the same way as we would do
in a normal wake-and-unlock sequence.
- Hide shadows while dozing, so we don't see the artifacts when we fade
the dozed Keyguard out.
Bug: 23225107
Change-Id: I82f78e61f2530cf7d507ade80f6f0a340c082567
When the unbind request came in before the service was actually
bound, we dropped the unbind request because mPrewarmBound was still
false. Fix that by tracking whether a bind is pending and if a unbind
event comes in during that time, set another flag to unbind it
directly again when the service is actually bound. In addition, don't
allow binding again if any of the previous events are still pending.
Bug: 23143748
Change-Id: I2b8ace86e35479a9848668a3462a2ce687835413
When pulse was about to turn on and at the same time we were starting
a wake-and-unlock sequence, there was jank because the scrim handling
was not correct anymore. Now, abort the pulse when we are wake-and-
unlocking so we don't see flickering with the scrims anymore.
Bug: 23217476
Change-Id: I331f513b68fb1832b4372d3e2e518b31b556a43c
In PowerNotificationWarnings, where it dispatches notifications
with UserHandle.ALL:
mNoMan.notifyAsUser(TAG_NOTIFICATION, R.id.notification_power, n, UserHandle.ALL);
The fix is to have RingtonePlayer check the incoming userId argument to playAsync(),
and change USER_ALL to USER_OWNER.
BUG=22516181
BUG=22992637
Change-Id: Ia3f8aaa2bee7fb15c24542e2331b2bc5a877e715
