There were a couple of situations where both cancel and finish
collided. In those cases make sure only one is called.
Somewhat related, launcher actually continues to use leashes
even after calling the finishCallback. Since we make leashes
for launcher anyways, just use launcher's existing leash
clean-up logic.
Bug: 235616350
Test: run/monitor wm presubmits.
Try launching and closing apps in rapid succession.
Change-Id: I7553ba9f9bbad052632a4d8d5a7225ab6c3dbce5
The PipTransitionAnimation#ofBounds is used when entering PiP on back pressed.
- Adjust the scale based on current animation progress
- Alter the auto-enter-pip animation running in Launcher to use the same
mechanism
- Update the ofBounds animation to ignore small source rect hint,
similar to what's in auto-enter-pip animation running in Launcher
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dv35ov6nK2Mrr98DGkLNaE
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/gm8Kl7N3NPIoWoDKyDfd5s
Bug: 235268241
Test: Verify enter PiP animation on back pressed with YouTube in \
both folded and unfolded state. See also videos.
Change-Id: I6043cff31eed7b63087ea03b17ced7549c89e4fb
These views were drawing before the transition startTransaction is
applied. This can cause deadlocks if there aren't enough buffers
and the view blocks the thread since applying the transaction is
what frees-up the buffers.
Bug: 233625646
Test: run tests and check for fewer ANRs
Change-Id: I7d592fe186695cdcde040d4ec315e656e05354e5
Before this CL, SplitController creates new SplitContainer if
min dimensions of new lauched Activity/Intent is not satisfied.
This CL changes to expand the existing SplitContainer
Bug: 232871351
Test: atest SplitPresenterTest
Change-Id: Id8d122f7d95d1c6a3574b02ddd2b6afbc548f853
The exception is because the client side hasn't received
TaskFragmentInfo yet, so we don't have WindowContainerToken
to change the bounds of TaskFragments.
This CL verifies if we have TaskFragmentInfo before
calling expandTaskFragment. If there's no TaskFragmentInfo,
fallback to create new SplitContainer that fills the task
bounds.
Test: atest WMJetpackUnitTests
Test: manual: reproduce steps mentioned in bug
Bug: 232871351
Merged-In: Id8d122f7d95d1c6a3574b02ddd2b6afbc548f853
Change-Id: I83ee6ea32df485bf78db3b50dec8c92d80be8912
This reverts commit:
db407ef12d, and
d8aa7f7882.
Reason for revert:
The surface size would be reduced by mTranslator unexpectedly.
Fix: 233017734
Test: Open a legacy app which has CompatibilityInfo.SCALING_REQUIRED
and see if the app is cropped.
Change-Id: If830866328a5709cf6856fe840a804b304052003
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
