Check : go/wm-tests
Ignore the unit tests until the better approach available
Test: atest WMShellUnitTests
Bug: 184813408
Change-Id: I3139afa58ed15c535a55822504c3331771f1bfdf
1) Fix `Could not find: PipApp`, the test previously used the launcher name, instead of the window name for assertion
2) The command previously missed a `verify` call to actually execute the assertion
Bug: 186115871
Bug: 186445782
Test: atest FlickerTests WMShellFlickerTests
Change-Id: Ie9274e273bcda2be24491705cd28d7dc0d5ea5db
The core function of OHM is translate all windows down
instead of resize, it's unnecessary to set WCT & app bounds
that will introduce DA require to cache configuration in
DAInfo as well as handle configuration changes stuffs
This change ensure App Compat mode works good:
- Remove wct.setBounds() & wct.setAppBounds()
- Use float instead of bounds for transition/animation
- Remove unused code
- Reset setWindowCrop(leash, -1, -1) after rotate
- Reset setCornerRadius(leash, -1) after rotate
- Add dump() for OneHandedAnimationController
- Add dump() for OneHandedSurfaceTransactionHelper
Test: atest WMShellUnitTests
Test: maunal trigger OHM, rotate, and obseve function works
Bug: 184091042
Bug: 181091031
Change-Id: I401d9b8a79a2a1526b8683362a1e0330458141b1
When stashing, currently it assumes the entire display is usable - not
taking into insets into consideration that can be caused by navigation
bar, etc.
Bug: 186698828
Test: Manual. Stashing PIP while w/ insets now stashes correctly.
Test: atest PipSnapAlgorithmTest
Change-Id: Ia6cbb8f21b666a4ba4ee10b84e3087b6a23cd982
Add a field of supportsMultiWindow to TaskInfo for WM Shell to use.
Because we will change to Task#supportsMultiWindow to check the
support based on the root activity's resizibilty, min widht/height,
and the device settings, using this to replace the check in
ActivityTaskManager, which is pure device settings.
Bug: 176061101
Test: atest WMShellFlickerTests
Change-Id: Iad94b39506e71b6224d923f02bd7fc454cae02c8
* If something was added to the overflow that was already there
make sure to remove it from the list first
* Did this in data & in update adapter to be safe
Bug: 181890793
Test: atest BubbleDataTest
Change-Id: I2a576911e0f3791768536f4a866d7174f55a0a2d
Some tests are still flaky and affecting presubmit
Bug: 185400889
Test: atest FlickerTests WMShellFlickerTests
Change-Id: I477799646791c69b71c6f29d71e87caba900a983
Before, it called openQuickstep before canSplitScreen, but the later one
is also calling openQuickstep. This caused the recent is pressed twice
to introduce the flakness.
Test: atest WMShellFlickerTests:EnterSplitScreenNotSupportNonResizable
Bug: 182235458
Change-Id: Iba5af5114fd8883b73d78ac34e6f891ee8ca798f
Add 2 cases with rotation change:
(a) Enter PiP from fullscreen.
http://recall/-/d6GxE5mVL8Ww2IPnx7Nk0o/hDfmdrhrBFjJNOdi1s66OW
(b) Launch fullscreen app with the existing PiP.
http://recall/-/d6GxE5mVL8Ww2IPnx7Nk0o/bUpHZ6Sh98zKZJnRM7oFy9
Steps of (a):
1. Task#setWindowingMode to PiP. If the next fullscreen activity
will change display orientation, start fixed rotation on it.
And start deferring orientation change.
2. PipTaskOrganizer#onFixedRotationStarted is called to mark it
will be a special case.
3. PipTaskOrganizer#onTaskAppeared is called and starts the PiP
rotation animation by animateResizePip with rotated destination
bounds from rotated DisplayLayout.
4. When onPipAnimationEnd, use WCT#scheduleFinishEnterPip to notify
that the animation is done, so the deferred orientation change
can continue to update (PinnedTaskController#setEnterPipBounds).
The end transaction of animation (reset matrix) is deferred
until fixed rotation is finished. Also freeze the PiP task
configuration one time, to avoid extra configuration change
(letterboxed) by rotation change.
5. The seamless rotation starts, the PiP surface is transformed
to previous rotation based on the bounds of previous step. So
the PiP task can show the same orientation as rotated display.
The frozen flag of PiP task configuration is cleared.
6. PipTaskOrganizer#onFixedRotationFinished is called. The final
PiP destination bounds and the deferred transaction of step 4
will be sent to WM.
Steps of (b):
1. Fixed rotation happens (PipTaskOrganizer#onFixedRotationStarted)
when there is an existing PiP. Apply fade-out animation.
2. PipTaskOrganizer#onMovementBoundsChanged is called to update
rotated destination bounds.
3. PipTaskOrganizer#onFixedRotationFinished is called to apply
fade-in animation with new bounds.
Other changes:
- WCT#scheduleFinishEnterPip was used to set bounds and notify
windowing mode change. That is already done by other config
change oepration of WCT. So this redundant operation is changed
to be a signal to notify that the PiP animation is done.
- Ignore calculating letterbox bounds for PiP activity because
it should fill the task.
- Add PinnedTaskController#DEFER_ORIENTATION_CHANGE_TIMEOUT_MS
to avoid using alpha animation after swiping from any task.
- Consider source rect hint with rotation.
Bug: 165794724
Bug: 175836469
Test: DisplayContentTests#testFixedRotationWithPip
PipAnimationControllerTest#pipTransitionAnimator_rotatedEndValue
Change-Id: I2c26b5d93996193caaf020bd0e2314c8e1789545
Some tests are still flaky and affecting presubmit
Bug: 185400889
Bug: 186119282
Bug: 186115871
Test: atest FlickerTests WMShellFlickerTests
Change-Id: Ie4e21d01d5ea7586f88470543321ce26ed74afa6
1) Define STATEs flags for OHM CUJ:
STATE_NONE (0)
STATE_ENTERING (1)
STATE_ACTIVE (2)
STATE_EXITING (3)
STATE_NONE->STATE_ENTERING->STATE_ACTIVE->STATE_EXITING
- Default = STATE_NONE
- When user trigger OHM = STATE_ENTERING
- When user is in OHM = STATE_ACTIVE
- When user exit OHM = STATE_EXITING
- When user finish exiting OHM = STATE_NONE
2) Unbound one handed mode state from OHMDAOrganzier
- Move isInOneHandedMode() to OneHandedState
Test: atest OneHandedStateTest
Test: atest WMShellUnitTests
Test: manual test
Bug: 185558765
Change-Id: Ida2f23da6c4df9cbcf6903ffc9ad07fcfc73bbcb
This adds a couple things to support "merging" of transition
animations in shell.
1. Moves the finishing surface operations into a transaction that
gets sent to shell. This does a couple things: it complies with
the contract we have where during a transition, only the player
should touch relevant surfaces; and, it makes it so that the
player can merge the transaction with other ones.
2. Keeps a queue of "pending" transition animations in shell and
either merges them or runs them serially.
3. Any transition that becomes ready while another is playing will
first be sent to the playing handler to give it a chance to
"merge" the incoming transition.
There are 3 expected responses to overlapping transition animations:
1. Cancel the currently playing transition and immediately start
the incoming one. This can be achieved by having the currently
playing transition cancel itself (ie. immediately finishing) when
a merge request comes in. Then the rest of the shell transition
logic will immediately start the next transition.
2. Queue up the incoming transition to play once the current one
finishes animating. This is basically the default as long as
the current transition simply rejects/ignores merge requests
3. Merge the incoming transition. This is achieved when the
currently playing transition actually does some special logic
to handle the incoming transition. It then calls the finish
callback for the incoming transition (before it finishes its
own animation) to indicate that it has been merged (or "consumed").
Basically, any time the finish callback for a transition is
called before a pre-ceding transition, that transition is assumed
to have been merged.
Bug: 183994113
Test: atest ShellTransitionTests
Change-Id: I3cb54e221d57642306ddf15827c21d8881b014d0
* Persist bubbles per-user - rather than one list the
XML now has a list per-user. The entries in these lists
still include userId for workprofile since bubbles are
mixed in the stack / overflow for workprofile.
* When loading bubbles, only the ones for the current user
are loaded / hit bubbleController code
* When user changes, overflow data should be re-loaded
* Allow the bubble window to be visible for all users
Test: atest BubbleXmlHelperTest BubbleVolatileRepositoryTest
BubblePersistentRepositoryTest BubblesTest
Bug: 173408780
Change-Id: I88cb7cc7ee676d8e0756328a95a54fdaf018a013
- Pass TaskSnapshot to Shell directly.
- Parallel process: create a splash screen worker thread to create the
splash screen view and pre-draw the icon drawable, and use splash
screen thread to do stuff about window's lifecycle like add/remove
window. We don't use shell main thread here so the starting window
won't blocking any task execute on main thread.
- Trigger addStartingWindow directly when startActivity, also
removeStartingWindow directly without post the animation thread.
- Do not defer addStartingWindow for prepare surface, on the contrast
it should be execute before prepare surface.
- Remove ActivityRecordTests#testAddRemoveRace, it wasn't been test as
expected because in original logic the add and remove starting window
are post to animation thread, so the test was actually testing on
handler#postAtFrontOfQueue and handler#removeCallbacks.
For now it will only cause OutOfMemoryError.
Bug: 183665220
Bug: 182836977
Test: atest StartingSurfaceDrawerTests SplashscreenTests
Change-Id: Ie9a529c7d81f07f923394eb69944518f3e9010ce
Previously Winscope considered only the `isVisible` property to determine if the window was visible or not. This failed in cases such as `com.google.android.googlequicksearchbox/android.app.ContextImpl` when launching apps, where `isVisible=true` and `alpha=0`
Bug: 181630910
Bug: 182720234
Test: atest FlickerTests WMShellFlickerTests
Change-Id: I75fab0c6de02e43265002986901353f8e230baa5
Previously some assertions didn't run on the whole trace because of a missing `forAllEntries` statement in the library. When activating this statement these tests fail and should be disabled.
Test: atest FlickerTests WMShellFlickerTests
Bug: 183547024
Bug: 181630910
Change-Id: I28f92e2d9de1a5465a4da5971c438bc4c0b311f9
The method was ignored before and now should be activated to enable 3 button mode. Some tests become flaky in 3-button mode and should be disabled for the moment.
Test: atest FlickerTests WMShellFlickerTests
Bug: 162925924
Change-Id: Ife24ad85c302da6fc193f1a5a226722cfed51b2b
This makes StageCoordinator implement the TransitionHandler
interface.
In general, this currently expects 'enter' transitions to
contain 2 tasks (one in each split). The current UX is undefined
when one only one of the splits is occupied, so for now it will
throw an exception if that case is hit.
There is a split-screen API called startTasks which takes a list
of tasks (currently only supports 2) and associated options and
creates a transition to both enter split-screen and launch those
tasks into their respective stages.
These are the currently accounted-for entrypoints into
the handler interface:
- Core-initiated (handleRequest)
- in split: trigger=HOME that is opening -> full dismiss.
- in split: trigger=task with a stage parent that is last closing in
that stage -> dismiss with other stage onTop
- NOT split: trigger=task with stage parent -> exception
- Shell-initiated
- NOT split: startTasks -> enter split with 2 tasks
- in split: snap-to-dismiss -> dismiss with other stage on top
Bug: 182002789
Test: atest SplitTransitionTests
Or use the experimental pair-launch split-screen and observe
protologs to see clean transition-infos.
Change-Id: I4f4dd431ad5642cf98b4a01c32eb1d09e5b9a11e
change though one-handed mode is off
Add more condition check when Talk back announce one-handed mode
related.
Bug: 182475904
Test: manual
Test: atest WMShellUnitTests
Change-Id: I0644146eaa6d7d6701af94fe6caceee5e6c3be8b
