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
Also disable legacy animation override from the organizer since it will never be used with Shell transition enabled.
Bug: 207070762
Test: pass existing
Change-Id: I16aaad606acb51bb47e881d5d533a5a3b1e1fbc9
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
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
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
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
Change-Id: Ib46c2cec2a0735b9e3f3420f2cb94754801b86b9
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
