We use to rely on the onActivityPinned and onActivityUnpinned callbacks
from Window Manager in EdgeBackGestureHandler to determine the current
PiP state and it will always be reset to false when
EdgeBackGestureHandler is being re-created, for instance, as a result of
folded state change.
Deprecated also the Pip#setPinnedStackAnimationListener interface method
since it's not in use and it may cause confusions over
IPip#setPinnedStackAnimationListener.
Bug: 174702196
Bug: 198651351
Test: stash in unfolded state -> fold -> drag to unstash \
stash in folded state -> unfold -> drag to unstash
Test: atest WMShellUnitTests:PipControllerTest
Change-Id: Id874056415011ee8a55dadcd4ec6af6e1b568092
The default behavior (if nothing is done) for a merge request
is to let the animation continue and queue up the incoming animation
to start once the current one has finished.
This is maybe the "smoothest" default; however, it is not
responsive for the user. So, instead, go through and, where
appropriate, make animations "jump-to-end" when they receive
a merge request. This way the user will see the new animation
start immediately after they perform an action. There is
technically a "jump" in the animation, but it seems like the
responsiveness is preferable and the jumps aren't super
noticable anyways. This is also how legacy transitions works
so it's not a behavior change.
Bug: 236309064
Test: interrupt animations with other transitions and observe.
Example: launch an app and then go "back" before it finishes
animating.
Change-Id: I4a76e7efe2c610b22f3fe97b0bd3ab692a01be08
Primary Activity and secondary Activity were both finished
while starting another Activity with FLAG_ACTIVITY_CLEAR_TASK
flag. The secondary container was then removed and the primary
container was resized to fullscreen while the organizer gets
the secondary TaskFragment info-changed event. And the primary
container was removed by primary TaskFragment info-changed event
afterward.
Since the primary Activity was resized before completely being
destroyed. The organizer got an onActivityConfigurationChanged c
allback and resulted in another placeholder activity being launched.
Bug: 236272623
Test: making Duo calls
Change-Id: I851828f739a4937725510d99cbdfae9ed212a023
The attached frame is the frame of the parent window that its child
attaches to, as long as the child is not
TYPE_APPLICATION_ATTACHED_DIALOG. It is a factor while computing the
window frame.
Previously, we let the child obtain the attached frame from its parent
view root. However, if the parent and the child are not in the same
process, it can be tricky.
This CL sends the attached frame from the server to the client via
ClientWindowFrames. In this way, the child can compute its window frame
without having to accessing the parent view root.
Bug: 161810301
Bug: 175861127
Test: atest ActivityRecordTests WindowLayoutTests
Change-Id: Ia844a4c927027e305a56114216eaee2bf7933b1f
to BackAnimation.
The original MotionEvent instance may have been recycled by the time BackAnimation processes it, since BackAnimation runs in a different thread. This could cause crashes from both Java side and native side, as described in b/233163975#comment11.
We work around this by passing the numerical values that BackAnimation
need instead of the MotionEvent itself.
Test: Swipe back in various scenarios. Make sure back can be triggered.
Try cancel. Make sure back can be cancelled.
Test: atest BackAnimationControllerTest
Bug: 233163975
Change-Id: I4792debc705536b49d1caafcc43e5466941c1d43
to BackAnimation.
The original MotionEvent instance may have been recycled by the time BackAnimation processes it, since BackAnimation runs in a different thread. This could cause crashes from both Java side and native side, as described in b/233163975#comment11.
We work around this by passing the numerical values that BackAnimation
need instead of the MotionEvent itself.
Test: Swipe back in various scenarios. Make sure back can be triggered.
Try cancel. Make sure back can be cancelled.
Test: atest BackAnimationControllerTest
Bug: 233163975
Change-Id: I4792debc705536b49d1caafcc43e5466941c1d43
Merged-In: I4792debc705536b49d1caafcc43e5466941c1d43
If an application uses ActivityEmbedding it would not be able to
observe display features (like folds or hinges) because they are
filtered out for activities in multi-window mode. One of the reasons
is because the client won't always know the correct position of the
window on screen in multi-window, and the position of the hinge could
be translated incorrectly to the task coordinate space.
However, it would still be OK to report the display features
when activities are in multi-window due to ActivityEmbedding as
long as the task is not in multi-window.
Bug: 236295340
Test: Sample app with embedding and display features.
Merged-In: I00f62574124df6df61f121228bd91ff9bc751c2a
Change-Id: I00f62574124df6df61f121228bd91ff9bc751c2a
If an application uses ActivityEmbedding it would not be able to
observe display features (like folds or hinges) because they are
filtered out for activities in multi-window mode. One of the reasons
is because the client won't always know the correct position of the
window on screen in multi-window, and the position of the hinge could
be translated incorrectly to the task coordinate space.
However, it would still be OK to report the display features
when activities are in multi-window due to ActivityEmbedding as
long as the task is not in multi-window.
Bug: 236295340
Test: Sample app with embedding and display features.
Change-Id: I00f62574124df6df61f121228bd91ff9bc751c2a
The RRS(runtime resolution switching) feature which supports users to
change resolution directly. Split-screen did not update the Context
object during the runtime resolution switching. That results in the
split layout can not get the proper resource in time.
This CL updates the new Context object whose resources are adjusted to
match the new given Configuration when the split bound is different
from existing. That’make sure to get the updated resources objects
when calculating the divider snap target for this case.
Bug: 235044746
Test: atest MultiWindowTests
Change-Id: I94d1a95c6b4aeb3bf1b75aed2e0b3008f036c968
This fix was introduced in ag/16150706 and recently got overridden with
ag/18751998, UnfoldAnimationController#resetTask happens in between
RecentsAnimationController cleanup and PipTaskOrganizer#onTaskAppeared
may cause flicker at the end of auto-enter-pip transition.
Fix it by intentionally ignore resetSurface if the task's pinned.
Bug: 235737615
Test: auto enter pip repeatedly on foldable
Test: atest WMShellUnitTests:UnfoldAnimationControllerTest
Change-Id: I5de034f5c0d3f150dd77aadb97c0d2b3f9c64c15
This registers system default clear-top xmls and propagate the
showBackdrop flag.
Test: atest RemoteAnimationsControllerTest
Bug: 221048002
Change-Id: I664f7edd181fd7d625b7010a77cd1f7b58fc3113
Before this CL, minimum dimensions of Activity wasn't respected,
that said, an Activity could be embedded in a TaskFragment of which
bounds are smaller its minimum dimensions.
This CL add the minimum dimensions on several places:
WM core:
1. Verify minimum dimension requirement before adding an Activity to
a TaskFragment. It'll be early return if the requirement is not
satisfied.
2. Propagate the minimum dimensions to the client side through
TaskFragmentInfo to notify the requirement.
3. If TaskFragmentOrganizer tries to shrink a TaskFragment to
the bounds that smaller than minimum dimensions of its children
Activity, switch to match the parent bounds.
AndroidX Window extensions:
1. Early return if TaskFragment is resized to the bounds that smaller
than minimum dimensions which dispatched from the server side.
2. When organizer tries to show Activities side-by-side, verify if
minimum dimensions requirement of the primary Activiy. If the
requirement is not satisfied, show Activities in fullscreen
instead.
TODO: Add an API to check if an Activity intent is allowed to embed
in a TaskFragment.
Bug: 232871351
Test: atest TaskFragmentOrganizerControllerTest
Test: atest TaskFragmentOrganizerTest TaskFragmentOrganizerPolicyTest
Test: atest SplitActivityLifecycleTest
Test: atest CtsWindowManagerJetpackTestCases
Test: atest WmJetpackUnitTests
Merged-In: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
ag/18759417 introduced a new call to onTaskMovedToFront which impacted
some bubbles behavior, basically while switching bubbles the
"background" app now appears to move to the front for a moment which
causes bubbles to be collapsed. The fix is to flip the flag for
bubbles switching a bit sooner than we already do.
Test: manual - have some bubbles, visit each of them once (i.e. have
the activity launched), then visit them all again
=> verify all the bubbles can be visited both times and
the stack doesn't collapse.
Bug: 235781358
Change-Id: Id0674cafd92d5aeb802a0da77a679996e7041b74
Set vsync id to transactions moving divider bar surface, so those
transactions won't be committed together and result to empty frame while
dragging the divider bar.
Bug: 230050092
Test: manual dump and verified with perfetto trace
Change-Id: Id570e80a908a07113b8e4bd77f38c05e3eee1d0c
