Don't delay frame scheduling
Doing so will lead to state inconsistencies. setExpansionAffectsAlpha
won't enque opacity requrests because mUpdatePending won't be true yet,
causing sudden opacity changes.
The much longer mAnimationDelay will already take care of waiting for
a while before starting the scrim animation.
Test: manual, with fp sensor
Fixes: 158955776
Change-Id: I9f7342f01de36576ba0108edfecbfc97448c8756
(cherry picked from commit d38fed16c8248eac08d7961798c1dec1c5f7bc23)
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/phone/ScrimController.java b/packages/SystemUI/src/com/android/systemui/statusbar/phone/ScrimController.java
index 60fc17d..686b871 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/ScrimController.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/ScrimController.java
@@ -348,10 +348,8 @@
}
if (mKeyguardUpdateMonitor.needsSlowUnlockTransition() && mState == ScrimState.UNLOCKED) {
- // In case the user isn't unlocked, make sure to delay a bit because the system is hosed
- // with too many things at this case, in order to not skip the initial frames.
- mScrimInFront.postOnAnimationDelayed(this::scheduleUpdate, 16);
mAnimationDelay = StatusBar.FADE_KEYGUARD_START_DELAY;
+ scheduleUpdate();
} else if ((!mDozeParameters.getAlwaysOn() && oldState == ScrimState.AOD)
|| (mState == ScrimState.AOD && !mDozeParameters.getDisplayNeedsBlanking())) {
// Scheduling a frame isn't enough when:
