When attach the task snapshot to the leash of newly created Task, move
its position to the new Task's coordinates and apply the crop with scale
in mind (snapshot is scaled to its task size).
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/d72OCvyYh0G0Z6YrEwyXMp
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/eacts7tgSeN28R3BWpXAem
Bug: 232984253
Test: launch into PiP with source rect hint middle of screen, \
see also the video
Change-Id: Ib79e75d7e6f6f667e50db197d5377b87cffc714d
Because ag/18529596 change the drop position, the test need to modify
the expected position of the app.
Bug: 232878493
Test: atest EnterSplitScreenByDragFromAllApps
Change-Id: Ib4823a899aa42ab2c0b23f9e654cbf13becb02bd
When app is re-launched, WM shell enters the exitPip process and within
which we should ensure any content-overlay attached to the on-going
animator is removed.
Bug: 232439933
Test: re-launch app immediately after app explictly calls enterPip
Change-Id: I17a204378c75d2442db588a1fa8cc2917f00b3f4
1. When an activity is launched without specifying launch TaskFragment,
it may be placed to the primary TaskFragment of a split if all
activities in secondary split are finishing. In this case, we still
want to check if activity should be splitted with the activity below.
In order to do that, we need to know if it should be split with the
secondary TaskFragment, which may still be empty, so store the
pending appeared Intent until the TaskFragment becomes non-empty.
i. The secondary TaskFragment can be empty when the primary trys to
start the secondary during #onCreated.
ii. If the Intent never actually started, it will trigger
#onTaskFragmentAppearEmptyTimeout to update the existing top
container.
2. When we are finishing a TaskFragment, we used to finish all
activities in it as well. We should not do that for activity that is
requested to be reparented (as pending appeared).
Fix: 233684054
Test: atest WMJetpackUnitTests:TaskFragmentContainerTest
Test: atest WMJetpackUnitTests:SplitControllerTest
Change-Id: I47329b23709da7e069a6a0c84124a3d7d08aae12
The algorithm computes a new position for PiP based on the registered
keep clear areas within the system. If no occlusion happens the original
position is being returned. Otherwise, the bounds are moved in one of the
available directions so that none of the keep clear areas are occluded
while keeping PiP within the display bounds.
Test: atest PipKeepClearAlgorithmTest
Bug: 183746978
Change-Id: Ic2d11861329a46e2da0448f90283f67f6e7125d7
Allows vendors to choose to restore to bounds other than the display
bounds on exit PIP. This is specially useful in freeform enabled
desktops where the previous windowing mode was freeform and PIP should
return to its original freeform bounds.
Bug: 225294296
Test: atest PinnedStackTests
Merged-In: Id25906c4b11e5f3c8351ba96cff80c63a6a5cf4e
Change-Id: Id25906c4b11e5f3c8351ba96cff80c63a6a5cf4e
(cherry picked from commit 2a68fc0b1a)
onTaskVanished already attempted to do some last resort overlay
cleanup, but because onExitPipFinished was called right above it, and
it internally set the state=UNDEFINED, the overlay removal in
onTaskVanished was always a no-op.
This change changes the order of onExitPipFinished and the animator
cancelling/overlay removal so that there is always an attempt to do
the removal in on vanish.
There should be no risk with this change that the removal is done twice
since even if the overlay is removed by an animator in onAnimationEnd,
the removal in onTaskVanished first checks that an animator exists and
that a content overlay exists, and one or both of those should cause
it to no-op if someone else removed the content overlay earlier.
Bug: 230561935
Test: enter MS teams call, swipe edge to go back, verify there's no
fullscreen overlay lingering.
Test: atest --iteration 5 \
ActivityThreadTest#testHandlePictureInPictureRequested_overriddenToEnter \
ScreenshotTests#testScreenshotSecureLayers \
TaskStackChangedListenerTest#testTaskChangeCallBacks
Change-Id: If8639ce78148c5ba1b247bb8afeee76e20863dc5
When entering content-pip
- We take a snapshot for the host task within the
ActivityStarter#startActivityInner function, this is to make sure that
the snapshot is taken before an app switches to the placeholder content
- We retrieve the snapshot in WM Shell when animating the newly created
content-pip task, and use that snapshot during the animation
- This works similar to the solid color content overlay when app enters
PiP without specifying a valid source rect hint. Therefore, we
abstract the functionality to a dedicated PipContentOverlay class
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dRSTf7prHc0krPhTKZ0kXx
Bug: 220191201
Test: enter content-pip from ApiDemos app, see also Video
Change-Id: I2420402341a910b44bd8f64e3ad518ebef41bc19
Add more assertions for layers become visible.
Bug: 232878493
Test: atest EnterSplitScreenByDragFromAllApps
Change-Id: Ida948525b618b800915813cf2927523600e23724
Adding synchronization to the public methods in SplitController,
as they might be called on different threads and cause a
ConcurrentModificationException.
Bug: 228201646
Test: atest CtsWindowManagerJetpackTestCases --iterations 100
Change-Id: I2db9ccb5e9829487eae7aa85eff5f6153721cc04
There were few reports in the bug for this to not always be set.
Based on the stack trace it is related to Keyguard showing/hiding,
but I was unable to repro locally the issue.
Adding a safety check to prevent this from occuring with proto log if it happens.
Bug: 233129957
Test: n/a, unable to repro, fix based on the stack trace
Change-Id: Ie45e557601fe52da6003790446b18aad2db681e5
