Prevent double keyguardGoingAway, and finish cancelled animations.

keyguardGoingAway could be called twice in a row due to race conditions between tryKeyguardDone and hideLocked.
This resulted in the first animation being cancelled. This would normally not be a problem, except that we also
erroneously did not call onAnimationFinished() on the remote animation callback if the animation was cancelled,
which meant WM waited the full 10 seconds before timing out and showing the app/launcher.

Fixes: 208731860
Test: atest SystemUITests
Test: repeatedly UDFPS and wait for a cancelled animation, see that it becomes visible
Change-Id: I6d3401e85df99a2a9be75cb51fca7f7c5ee939d4
This commit is contained in:
Josh Tsuji
2021-12-10 14:32:33 -05:00
parent 45cf23a6a4
commit 9df0055a27

View File

@@ -2090,6 +2090,15 @@ public class KeyguardViewMediator extends SystemUI implements Dumpable,
private final Runnable mKeyguardGoingAwayRunnable = new Runnable() {
@Override
public void run() {
// If the keyguard is already going away, or it's about to because we are going to
// trigger the going-away remote animation to show the surface behind, don't do it
// again. That will cause the current animation to be cancelled unnecessarily.
if (mKeyguardStateController.isKeyguardGoingAway()
|| mSurfaceBehindRemoteAnimationRequested
|| mSurfaceBehindRemoteAnimationRunning) {
return;
}
Trace.beginSection("KeyguardViewMediator.mKeyGuardGoingAwayRunnable");
if (DEBUG) Log.d(TAG, "keyguardGoingAway");
mKeyguardViewControllerLazy.get().keyguardGoingAway();
@@ -2451,9 +2460,7 @@ public class KeyguardViewMediator extends SystemUI implements Dumpable,
if (mSurfaceBehindRemoteAnimationFinishedCallback != null) {
try {
if (!cancelled) {
mSurfaceBehindRemoteAnimationFinishedCallback.onAnimationFinished();
}
mSurfaceBehindRemoteAnimationFinishedCallback.onAnimationFinished();
mSurfaceBehindRemoteAnimationFinishedCallback = null;
} catch (RemoteException e) {
e.printStackTrace();