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
This can happen in two cases:
1. The activity is embedded in another app. Then the current organizer
shouldn't control it.
2. The activity is in a TaskFragment that the organizer just request to
remove, but hasn't reach the server side. Then the activity will soon
be finished with the TaskFragment.
In either case, the organizer shouldn't need to resolve it. Otherwise it
may incorrectly change the state, such as entering split for a finishing
activity.
Bug: 233295443
Test: atest WMJetpackUnitTests:SplitControllerTest
Change-Id: I5d2028dd45abd8d20a8e82bc4e51c4d6dc6e26ee
If the secondary TaskFragment becomes empty, it may trigger to launch
the placeholder activity. If this happens when the Task is in the
background, we don't want the placeholder launch to bring the Task to
the front.
Fix: 232828672
Test: atest WMJetpackUnitTests:SplitControllerTest
Change-Id: Idc159a8c8117e6cc601d7f8650bcfa3c575af076
1. For new created activity, check if it should be split with the other
activity that is currently split with the activity below.
2. When the activity is reparented back to the Task from PiP window,
check if it can be split with the existing.
3. Breakdown the long #handleActivityCreated to smaller pieces.
Bug: 225371112
Test: atest WMJetpackUnitTests:SplitControllerTest
Test: atest WMJetpackUnitTests:TaskFragmentContainerTest
Change-Id: Iba9f1487328768f5f2c27241d04c57ee7e5ed1d4
1. Refactor onStartActivity so that we can reuse the same logic for
onActivityReparentToTask. Also cleanup the logic there.
2. Besides the launching activity, check if the launched activity can be
split with the top activities.
Bug: 225371112
Test: atest WMJetpackUnitTests:SplitControllerTest
Test: atest WMJetpackUnitTests:TaskContainerTest
Change-Id: I840766e4efaa4bdb9ec89cdca8b3c2c0bbe8cf8c
1. When the top TaskFragment just appears, we should treat it as active
even if it is empty, because we are expecting an activity to be
launched into it soon. Before that happens, we don't want to launch
placeholder for the activity behind.
2. When a TaskFragment is appeared as empty, set a timeout to remove it
instead of waiting forever in case the activtiy start failed.
Fix: 230540531
Bug: 219683160
Test: atest WMJetpackUnitTests:SplitControllerTest
Test: atest WMJetpackUnitTests:TaskFragmentContainerTest
Change-Id: Ie05e379bf898b67912a849ad84f9fe7708e289c6
1. When the Task windowing mode changes, notify the organizer.
2. When organizer requests windowing mode change, record the last
request value to avoid unnecessary IPC call.
Bug: 230446204
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest WMJetpackUnitTests:SplitPresenterTest
Change-Id: I30c5dbf7b70d085647490943508bd5d22fda3ead
If an app is split with an Activity from another process
by Activity Embedding feature, and is launched twice
with different orientations, there's a chance that
the app still shows in previous orientation at the second
launch even if the orientation is changed.
The root cause is that, the app goes back to background
before the secondary container receives its TaskFragmentInfo.
Also, there's no pendingActivities and #onActivityPostCreated
won't be invoked, and also #updateContainer to change its
layout, because the Activity is from other process.
Moreover, in #onTaskFragmentParentInfoChanged, updateContainer
is skipped because secondary container is empty(No pending activities,
and hasn't received its TaskFragmentInfo).
This CL fixes the issue by verifying if one or both containers are
finished instead.
fixes: 228906392
Test: atest SplitControllerTest
Test: manual - reproducible steps in bug
Change-Id: Ifba4b56c9225089776835aeeef7c4a13249b55bf
This reverts commit 0dc147eeee.
Before, when we are in ActivityEmbedding split, the TaskFragment
windowing mode is always set the WINDOWING_MODE_MULTI_WINDOW, which
overrides the activity windowing mode, and it causes the app process
unaware of the Task windowing mode. Now, when the Task is multi
windowing mode, we set the TaskFragment windowing mode to the same as
the Task.
Bug: 230446204
Change-Id: I61b0857c551e6fd4ee9a544b63a3a2c20e291fab
Test: atest WMJetpackUnitTests:JetpackTaskFragmentOrganizerTest
Test: atest WMJetpackUnitTests:TaskContainerTest
This reverts commit 0522842a34.
Reason for revert: Breaking PlatformScenarioTests Tests due to NPE
Bug: 230793322
Change-Id: Ib6a9a1b7fb1c95681fc7a1bb959da5618b840f16
Before, when we are in ActivityEmbedding split, the TaskFragment
windowing mode is always set the WINDOWING_MODE_MULTI_WINDOW, which
overrides the activity windowing mode, and it causes the app process
unaware of the Task windowing mode. Now, when the Task is multi
windowing mode, we set the TaskFragment windowing mode to the same as
the Task.
Bug: 230446204
Test: atest WMJetpackUnitTests:JetpackTaskFragmentOrganizerTest
Test: atest WMJetpackUnitTests:TaskContainerTest
Change-Id: Id78a86359297c0c225043b14844441445711f89d
Before, before TaskFragment appeared, the getTopNonFinishingActivity may
be null, and throw exception for no bounds found.
Now, make sure we always have Task bounds stored.
Bug: 228885031
Test: atest WMJetpackUnitTests:SplitControllerTest
Test: atest WMJetpackUnitTests:TaskContainerTest
Change-Id: I3744813a85f24941563c8ff8f284b2e45396f906
We ignore WCT for TaskFragment in PiP, but in case the empty
TaskFragment is not removed before the Task enters PiP, we should allow
organizer to remove it.
Also make sure we have all requests in one WCT during
onTaskFragmentInfoChanged.
Bug: 225371112
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Test: atest WMJetpackUnitTests:SplitControllerTest
Test: atest WMJetpackUnitTests:TaskFragmentContainerTest
Change-Id: I718bbb7f6c18c35048c671ed3c131eaf536cf265
Before, we register remote animation per organizer, and assume it only
organizes in one Task. Now, we register per organizer Task if there is a
rule that supports split in the Task width.
Bug: 207720388
Test: atest WMJetpackUnitTests
Change-Id: Iac4e10af9aa0e7846c81b036b2cf708b6cbe627e
