summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJosh Tsuji <tsuji@google.com>2022-08-02 21:15:03 -0400
committerAndroid Build Coastguard Worker <android-build-coastguard-worker@google.com>2022-08-05 02:47:41 +0000
commit3bf0c31539ad819ea19aaaeb8f143b444f068fb3 (patch)
tree71302b74d3c295b231374ee304d69a040dc86c46
parent6fbda8c7bced6fd3756c13c47f9df0855166d9f2 (diff)
downloadbase-3bf0c31539ad819ea19aaaeb8f143b444f068fb3.tar.gz
Don't reset the keyguard on occlusion if it's going away.
The reset() call only executes if the keyguard is visible, and causes it to reset the visible views (it can not show/hide the keyguard). However, if the keyguard is going away because of a launching occluding activity, and was previously insecure, this will cause us to decide that the views should be in SHADE state rather than KEYGUARD state, and re-render them accordingly. This causes the shade to flicker under the launching activity. This reset is not needed, as the status bar state change will change to SHADE after the launch animation occurs (or will be forced back to KEYGUARD if the unlock animation is cancelled). Fixes: 238294986 Test: launch controls from LS affordance with/without face unlock, with/without AOD Change-Id: Ib0622655ef6f51e1bcc9a98a5ce8f4e7feacb2fe (cherry picked from commit fac6505c97b2cc1f8fb02b3fba04131d240e181f) Merged-In: Ib0622655ef6f51e1bcc9a98a5ce8f4e7feacb2fe
-rw-r--r--packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java6
1 files changed, 4 insertions, 2 deletions
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java b/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java
index fdc344f01a0f..038beba03957 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java
@@ -733,8 +733,10 @@ public class StatusBarKeyguardViewManager implements RemoteInputController.Callb
}
mNotificationShadeWindowController.setKeyguardOccluded(mOccluded);
- // setDozing(false) will call reset once we stop dozing.
- if (!mDozing) {
+ // setDozing(false) will call reset once we stop dozing. Also, if we're going away, there's
+ // no need to reset the keyguard views as we'll be gone shortly. Resetting now could cause
+ // unexpected visible behavior if the keyguard is still visible as we're animating unlocked.
+ if (!mDozing && !mKeyguardStateController.isKeyguardGoingAway()) {
// If Keyguard is reshown, don't hide the bouncer as it might just have been requested
// by a FLAG_DISMISS_KEYGUARD_ACTIVITY.
reset(isOccluding /* hideBouncerWhenShowing*/);