diff options
| author | 2022-09-16 00:15:37 +0000 | |
|---|---|---|
| committer | 2022-09-20 11:12:06 -0700 | |
| commit | 957496a9fcf83aead6858ed1cdfc0c072094f610 (patch) | |
| tree | 672f4a7cd13b34511c7e4c783abd44d8bc17be30 /libs/input/SpriteController.cpp | |
| parent | 3493f307ba6045431edb32e41954d2633d704cd7 (diff) | |
Don't assume exiting non-app windows are animating in transition
If a non-app window exits itself (via relayout), even if that
window is in a transition subtree, don't mark it as mAnimatingExit.
We don't actually have any situations (yet) where shell-transitions
animate non-app/wallpaper windows so if WM isn't animating
that window (via winAnimator.applyAnimationLocked), then it has
no WM-side animation and thus it can't be mAnimatingExit. This
matches legacy app-transitions which, also, do not animate non-app
windows.
For context, NotificationShade was closing itself during a display
change. This meant that inTransition() was true (because everything
is in the display). However, this was after the animation already
started and nothing ever collected the NotificationShade's Token
(since the animation is done in client -- as is the case with all
of these non-app windows currently).
Bug: 247005789
Test: toggle desktop-mode from notification shade and verify that
its surface goes away.
Change-Id: Ib4f6924a1e6517d192abd3f77e4eccdd9da13004
Diffstat (limited to 'libs/input/SpriteController.cpp')
0 files changed, 0 insertions, 0 deletions