PIP is not automatically appareing when launching via intent after
the Bubbles tests, when launching independently it works fine.
Bug: 218604389
Test: atest WMShellFlickerTest
Change-Id: Ib5dd76476cbe5cc054e5d4964e6dd4a5cb0ae5cc
The position of the letterbox education is fixed to the top left corner (0,0) of the task (parent surface) so there is no need to set the position of the surface because this is the default position of a surface (relative to its parent).
We do however need to update the dimensions of the layout (relayout) when the task bounds change because they are dependant on them.
Finally, there is no need to relayout when View#onLayout is called because neither the surface position nor the layout's dimensions depend on changes in the layout itself.
Bug: 215314668
Test: N/A
Change-Id: I17850b4106b13809e51cf2b9b83c6d67151a9df5
When the last bubble is removed we clean up the views associated with
the bubbles, including the overflow view.
BubbleOverflow#getExpandedView would create the view if it didn't exist
but it wouldn't be initialized which means it wouldn't have the Bubble
Positioner set on it.
When a bubble is removed some code runs that would do stuff to the
last expanded view, if it's non-null. If the overflow was the last bubble
expanded, rather than skipping that code because the expandedView is
null (because all the bubbles are gone), it was actually recreating
the overflow expandedView but it wouldn't be initialized at that time
resulting in the NPE.
This fixes the issue by modifying BubbleOverflow's getExpandedView to
only return the view, not do any view creation.
Additionally this change removes some redundant code in BubbleStackView.
Bug: 214399371
Test: atest BubbleOverflowTest
Change-Id: Ib8d94fc7ea1163e79146e1439ec3f404d3caa303
WindowAnimator.animate repeatedly calls into
handleCompleteDeferredRemoval() which wasn't checking
the same conditions as removeIfPossible() (which is
the function that actually sets mDeferredRemoval). This
meant that removeImmediately() would be called early
at times and break CTS tests.
Similarly, moved the onDisplayRemoved call in keyguard
controller to removeImmediately() so that it wouldn't
get called prematurely.
Also fix a NPE in DefaultTransitionHandler
Bug: 183993924
Test: atest MultiDisplayPolicyTests (with shell-transitions)
Change-Id: I73b10a290a3b2be6ea4d978190863cc6ce62ef8f
Update remaining uses of grantEmbeddedWindowFocus
to pass in a grantFocusToken instead of the input token.
Test: steps in b/218436735
Fixes: 218436735
Change-Id: Idadbd584c06f75ea64dd18a6a002d14426de8998
Use a flag to prevent we should divider during luancher is
animtating the divider and set surface bounds on this transition.
Fix: 215667718
Fix: 215667829
Test: manual
Test: pass existing tests
Change-Id: I4bee717d8be314dd59ec303e73b1dd66be98c0c3
This works by separating an app launching to 2 phases
(similar to legacy fixed rotation). First it launches
the app into a different rotation. Once the animation
finishes it creates a new seamless display-rotation
transition.
Because we have displayRotation in windowconfiguration,
we can directly rotate a window's surface instead of
checking explicitly for fixedRotationState. Since the
second-phase is a transition, we don't (ab)use
seamlessRotator. Once the display lines-up, the
surfaces and configurations automatically update.
Since we still want to explore shell-transitions style
rotation (single-transition), add a system property
to turn it off and on.
Bug: 217560545
Test: existing tests and manual tests
Change-Id: I0b34b32ff5b2650a519d3c195df452de446cf515
Create specific class for shell transition when whole CUJ crashes
Bug: 209843622
Test: atest FlickerTests WMShellFlickerTests
Change-Id: I8d3d96af7303e6bd7bc4a540aa79b0f9ea3bf4a0
We run the flicker tests multiple times to detect CLs that intoruce flakiness early. Currently we run 5 executions of each CUJ. However, due to lab capacity and impact in presubmit times, this CL reduces the repetitions to 3
Bug: 209843622
Test: atest FlickerTests WMShellFlickerTests
Change-Id: I165937fb82953d62c028ffe96a948d0ca00dbbe2
- When dragging to launch a new app, apply MULTIPLE_TASK to the launch
intent to allow apps that support it to show side-by-side
- This requires the pending intent resolved from LauncherAppsService to
be mutable (should be ok since we only use this api from SysUI)
- Also remove some unused members and duplication of getting the running
task when dragging
Bug: 207686016
Test: atest WMShellUnitTests
Change-Id: Ib233ad754a6c6e3c4e0d0e10ed788ab8e055cccc
Assertions are very flaky, don't provide any immediately useful information in the current state and going to be replace soon anyways
Test: atest FlickerTests
Change-Id: Id8f7649b818237bc16051d808ef46ca875669faa
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
