diff options
| author | Riddle Hsu <riddlehsu@google.com> | 2020-05-26 18:32:18 +0800 |
|---|---|---|
| committer | Riddle Hsu <riddlehsu@google.com> | 2020-05-27 22:53:26 +0800 |
| commit | 08bc4ed31ba602c26bc7ebc6db3e28cd7f562555 (patch) | |
| tree | 8d90eb9feba92785c0242f00d269bebf705699ad /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 148fb0e8c2f7c03fed889d06fbc714c75849436f (diff) | |
Do not force seamless rotation with animating rotated recents
The animating recents activity (e.g. home) is set as fixed-rotation-
launching-app to reduce extra enable/disable transform because it may
be the real top activity later (e.g. swipe to home or enter overview).
The actual state is only known when finishing the recents animation.
So during animating, it is not really the top activity that will change
the rotation of display.
If auto-rotate is disabled, there will have a rotation button when
device is rotated. And if the device is using gesture navigation, the
touch region of button may overlap with the navigation bar. Then when
pressing the button while device is in landscape, the recents activity
may also be triggered with fixed rotation in portrait, that causes
the rotation type is forced to be seamless. But the actual foreground
app is not rotated and does not declare to use seamless, therefore
the screen looks flickering by updating configuration directly.
Fixes: 157208761
Test: DisplayContentTests#testRotateSeamlesslyWithFixedRotation
Change-Id: If512ad14420ed7956fe888a0ce9f5d5006eb43a8
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions