Otherwise its WidowManager.LayoutParams#windowAnimations is 0, then
it won't play animation (TransitionAnimation#loadAnimationAttr
returns null) so the the surface of closing app may be updated to
invisible at random timing that causes the test flaky.
Use darker gray as window background color to make it easier to
distinguish the visual result between home, starting window (gray)
and app content (orange).
Bug: 216297992
Bug: 213852103
Test: com.android.server.wm.flicker.launch.OpenAppColdTest
Change-Id: I3bb073dfa52484a63168b3aeb6e7f5f43bd02aac
In addition, remove the overlay layout and include it in the dialog
layout as the background of the top-level layout (renamed as dimmer).
Test: N/A
Bug: 207010227
Change-Id: I658e85378ec266c4260b520b5fcdddbfb66b35c6
This super class will hold common logic and be used for the letterbox
education window manager in a follow up cl.
Bug: 207010227
Test: atest WMShellUnitTests:CompatUILayoutTest
Test: atest WMShellUnitTests:CompatUIWindowManagerTest
Test: atest WMShellUnitTests:CompatUIControllerTest
Change-Id: If6a1a5d1325e1fd4245b138e255000fa71273472
When a bubble is suppressed it should be removed from the stack and
expanded view.
Previously we were updating the visibility of the suppressed bubble.
This kept it in the expanded view.
Updating the suppression logic to remove the suppressed bubble view
temporarily, while it is suppressed.
When it should be visible again, adding it back.
Bug: 214090876
Test: atest BubbleDataTest BubblesTest
Test: manual, created a single bubble, checked it is hidden when
associated activity is opened and shown again after activity closes
Test: manual, created multiple bubbles, checked bubble is hidden when
associated activity is opened and shown again after activity closes
Test: manual, checked that suppressed bubble is not shown in expanded
view
Change-Id: I591a4330ccbb4d9764100715140d8bd20d0351bf
The test was previously running the transition 20 times incorrectly. This frequently led to OOM errors, since the system would store 80 instances of protos + flicker objects in memory while making assertions.
Intead run the default 5x
Bug: 216303412
Test: atest ExitPipWithSwipeDownTest
Change-Id: I20fe19239a857cfbc0818910814041323735692a
This CL enable OnBackInvokedCallback to be saved in a WindowState and
queried by the BackNavigationController to be returned when
ATM.startBackNavigation() is called.
The DecorView provides a PendingOnBackInvokedDispatcher that can receive
callback registration before being added to a ViewRootImpl.
Test: atest FrameworksCoreTests:BackNavigationTest
Bug: 131727607
Change-Id: I01528a22ea4a6583a56ade4eab69136d727855d0
If onBackPressed was used while the stack was expanded, it was calling
setExpanded on BubbleStackView (BSV) and NOT BubbleData. This results in
BSV and BubbleData being out of sync which can lead to incorrect behavior.
(e.g. using individual bubble dismiss method instead of the stack dismiss
method).
Test: atest BubblesTest NewNotifPipelineTest
Fixes: 217361258
Change-Id: I748fdd49626acaa0e986a9d8038039cada6faa60
The toast is no longer needed since we decided to only show the
letterbox education once as a dialog.
Test: N/A
Bug: 207010227
Change-Id: I1dccf10d0effad111d8ee8e62a068e4dee571c20
Due to the large amount of traces on flicker, the tests take 15min+ to copy the files from the device to the host after the test execution. Instead, start copying the files asynchronously.
It is not possible to use the async mechanism from Tradefed's FilePullerLogCollector because it either: (1) pushes the files form the directory multiple times -- once per test -- creating a lot of duplicates; or (2) cleans up the directory without checking for new files, losing some files.
This CL creates an asynchronous file upload mechanism for flicker using coroutines
Bug: 216111397
Test: atest FlickerTests WMShellFlickerTests
Change-Id: I5bbae834cf3439950626823c6b665c733e27e517
This is required for the go/t-activity-transition (https://direct.googleplex.com/#/spec/241720001&247800001) which we want to use as the default transition for T
Test: atest FlickerTests
Bug: 202844659
Change-Id: I316ddfb937953cf462ac999b8d27ae4cb0128847
Test: manual - reboot the device, rotate, drag stuff into split
=> verify that the orientation of split while dragging is
correct
Bug: 216643100
Change-Id: I300ad7263bf2ac18575d92f057fdd9c13ef736a7
(cherry picked from commit 4a79d7cb97)
Normal applications should have restrictions on how big/many keep-clear
areas they can set. This is to prevent malicious apps from misusing the
API and causing unexpected effects (like the Pip moving unexpectedly or
too much around the screen).
System apps, however, can be trusted to set any keep-clear areas.
In this CL we introduce a new permission to allow system apps to set
unrestricted keep-clear areas. We send two lists to Shell - one with
restricted, the other one with unrestricted keep-clear areas. When
moving floating windows away, the Shell can decide to always take into
account unrestricted keep-clear areas and be more restrictive about the
restricted ones.
Bug: 209578131
Bug: 209577354
Test: atest CtsWindowManagerDeviceTestCases:KeepClearRectsTests
Test: atest WindowStateTests
Test: atest DisplayContentTests
Change-Id: I68804c50fb81173b0795cf30dd71ea91abd02229
Test: manual - reboot the device, rotate, drag stuff into split
=> verify that the orientation of split while dragging is
correct
Bug: 216643100
Change-Id: I300ad7263bf2ac18575d92f057fdd9c13ef736a7
