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
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
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
Fix no features emitting by emitting if they are present.
Ignore emitting features if the current state is not valid.
No features are emitted on registration because consumers are not
registered to the source.
The following tests ar fixed
ExtensionWindowLayoutComponent#testDisplayFeatures
ExtensionWindowLayoutComponentTest#testSidecarHasSameDisplayFeatures
ExtensionWindowLayoutComponentTest#testGetWindowLayoutInfo_windowRecreated_windowLayoutUpdates
ExtensionWindowLayoutComponentTest#testGetWindowLayoutInfo_configChanged_windowLayoutUpdates
ExtensionWindowLayoutComponentTest#testGetWindowLayoutInfo_windowRecreated_windowLayoutUpdates
Bug: 232354881
Test: atest CtsWindowManagerJetpackTestCases:ExtensionWindowLayoutComponent
Change-Id: Ia1f7631576bad0bbefdca0fea3308973c5514056
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
A CL in that directory had broken SysUI presubmits:
ag/18030738
Bug: 230793322, 202567877
Test: presubmit
Change-Id: If9b39f357948cefb12338f4477ac360a25783107
Sending a split info callback before activity created would
give developer a reference to a not fully initalized class.
It is possible that an attemp to apply actions to such an
activity in the split callback would lead to unexpected
issues for developers. E.g. one might assuming that the
UI for an activity would've been constructed at this point
and try to update it to fit the split or collapsed state
requirements.
Bug: 228770009
Test: atest CtsWindowManagerJetpackTestCases:ActivityEmbeddingLifecycleTests
Change-Id: I3a19a028ad6da9a6d534a97d315bce5f95b191af
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
Default focus should be on primaryActivity when a placeholder is shown.
This is a short term improvement as focus navigation works from primary
to secondary but not in reverse.
Fix: 229138140
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: Ic4e2280e4b37a8fa04fc532245a5d0cfa4e5e012
When the activity exits PiP and is reparented to the original Task, the
organizer should handle it as a new launch.
Bug: 225371112
Test: atest WmTests:TaskFragmentTest
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: Ia7e32e995a35e167b0d76e701c972b269ae068cc
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
Adding a change for a device state to be
found by DeviceStateManagerFoldingFeatureProducer
before it reports back the display features.
Bug: 223237296
Test: NA
Change-Id: Iad15ea6e66209a15fefdcf1b7d0a39796a28a1de
