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
Also clear identity when measuring ASEC sizes to relax a second
permission requirement.
Bug: 23600574
Change-Id: Ib3a104426758e0e8f35dff0e504fe874bed7311f
If you tap the enter key twice on the keyguard PIN entry
screen, the second tap can sometimes register because keyguard
hasn't been dismissed yet. The fix is to ignore a second attempt
after the PIN has already been verified.
Fixes bug 19216025
Change-Id: I73a004e91e43f3da65ec84f90de6943e717d737f
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
When calling cancel() on the cancellation signal, it doesn't happen
immediately. Now, because of a state messup during boot, we go
through the sequence
startListeningForFingerprint
stopListeningForFingerprint
startListeningForFingerprint
However, the cancellation callback from stopListeningForFingeprint
happened AFTER the second startListeningForFingerprint, so we assumed
that fingerprint detection was not running anymore but in reality it
was - leading to weird states and all kinds of small state messups.
Introduce a state machine to track when we we called cancel but
waiting for the confirmation of FingerprintService in order to track
this properly.
Bug: 23380500
Change-Id: I403479fb749cf7c22b73611b69698e8b771777d0
- 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
After gettin a callback onAuthenticationSucceded we set the
fingerprint listening state to false. However, when waking up, we
immediately started listening again because the state was false.
Protect against that by only calling authenticate only once, except
when the unlock doesn't go through because unlocking with fingerprint
is not allowed.
Also fixes some animation "jank" because of the state messup.
Bug: 23304421
Change-Id: Ic83ac0f1590dd4f8017bb55dca9e19a60cfdf99f
