Call KeyguardViewMediator#hideWithAnimation on the main thread

This CL ensures that we call KeyguardViewMediator#hideWithAnimation on
the main thread when animating an app launch.

This CL also changes how this method operates: it now relies on
 #keyguardDonePending being called beforehand. This ensures that
keyguardDone() is actually called before hiding the keyguard, which was
not the case with the previous implementation.

Bug: 184726377
Test: Click a notification on lockscreen (without security)
Change-Id: Ic391e28066282e059e57cc50c5191e50ca7df06e
This commit is contained in:
Jordan Demeulenaere
2021-06-08 17:31:22 +02:00
parent 20da155df4
commit 6d22064dcd
2 changed files with 14 additions and 4 deletions

View File

@@ -1651,14 +1651,19 @@ public class KeyguardViewMediator extends SystemUI implements Dumpable,
Trace.endSection();
}
/** Hide the keyguard and let {@code runner} handle the animation. */
/**
* Hide the keyguard and let {@code runner} handle the animation.
*
* This method should typically be called after {@link ViewMediatorCallback#keyguardDonePending}
* was called, when we are ready to hide the keyguard.
*/
public void hideWithAnimation(IRemoteAnimationRunner runner) {
if (!mShowing) {
if (!mKeyguardDonePending) {
return;
}
mKeyguardExitAnimationRunner = runner;
hideLocked();
mViewMediatorCallback.readyForKeyguardDone();
}
/**

View File

@@ -2118,7 +2118,12 @@ public class StatusBar extends SystemUI implements DemoMode,
return;
}
mKeyguardViewMediator.hideWithAnimation(runner);
// We post to the main thread for 2 reasons:
// 1. KeyguardViewMediator is not thread-safe.
// 2. To ensure that ViewMediatorCallback#keyguardDonePending is called before
// ViewMediatorCallback#readyForKeyguardDone. The wrong order could occur when doing
// dismissKeyguardThenExecute { hideKeyguardWithAnimation(runner) }.
mMainThreadHandler.post(() -> mKeyguardViewMediator.hideWithAnimation(runner));
}
@Override