summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorJorim Jaggi <jjaggi@google.com>2017-08-28 15:44:43 +0200
committerJorim Jaggi <jjaggi@google.com>2017-08-31 21:05:19 +0000
commitedede6db924362d9884fe14fd14910409369f96c (patch)
tree134ac1b22ea6afa93c17674212d770ecb072c6c3 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent8d1a86ca0f0c2aa10928e47a1bcc6bfab7e741ba (diff)
Fix transition between two occluding activities
This fixes an issue when starting an activity that occldues Keyguard with the window flag from an activity that is already occluding Keyguard. Normally we wait until the transition starts until the next activity had a chance to set its layout flag (FLAG_SHOW_WHEN_LOCKED) with the UnknownVisibilityController. Now, since setAppVisibility(false) was called after immediately starting the activity, we removed the activity immediately from the UnknownVisibilityController waiting list and then unoccluded Keyguard. We fix this by only adding an activity to the unknown visibility list if it's a not a noDisplay activity as it will never add a window in this case, so a relayout will never happen. This regressed from I745e985766a1af97203e1d22b6443dabdd0c0363 because calling setVisible(true) was setting the token's visible to true. Then, setVisible(false) was NOT ignored anymore. Previously it was just ignored because the app wasn't made visible yet from WM perspective. Test: go/wm-smoke Test: android.server.cts.KeyguardTransitionTests#testNewActivityDuringOccluded Test: Launch camera from unlocked Keyguard by swiping from the icon with animation transition scale set to 0.5. (regression test) Change-Id: Idc2a5523f4653ae9788ba145c2d980343ae459f4 Merged-In: Idc2a5523f4653ae9788ba145c2d980343ae459f4 Fixes: 65061212 Bug: 37677242
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions