commit d4b63e9d6080d65ca70b7298eb16a1189d355f32
author Lucas Dupin <dupin@google.com> Wed Sep 19 15:23:54 2018 -0700
committer android-build-team Robot <android-build-team-robot@google.com> Thu Sep 20 22:33:00 2018 +0000
tree 15be6fb1bdfb58bb9cb8b8ef7496a20cbc79a377
parent 3dc78506c66547476204de2ceeff624e7952c4e5

What a horrible fix

setKeyguardFadingAway will only be called again with false when
the scrim animation is over. This means that if AM takes to long
to start the animation, something else might have already tried
to fade out the scrim because the device woke up or changed state.

Change-Id: I46f87a4e72f8a8408365c2852df9d2c58d53fd9a
Fixes: 115332000
Test: unlock with PIP and breakpoints
(cherry picked from commit f0a67e378db69fd4e5154165bb5ffc47ea13720a)

packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java

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 e8389af..3db1456 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/StatusBarKeyguardViewManager.java
@@ -460,6 +460,11 @@
                 boolean staying = mStatusBar.hideKeyguard();
                 if (!staying) {
                     mStatusBarWindowController.setKeyguardFadingAway(true);
+                    // hide() will happen asynchronously and might arrive after the scrims
+                    // were already hidden, this means that the transition callback won't
+                    // be triggered anymore and StatusBarWindowController will be forever in
+                    // the fadingAway state.
+                    mStatusBar.updateScrimController();
                     wakeAndUnlockDejank();
                 } else {
                     mStatusBar.finishKeyguardFadingAway();