* SystemUi split APIs are overloaded to launch fullscreen tasks
as well, break that out into a separate method for clarity
* Have SplitSelectDataHolder also special case fullscreen launches
Bug: 283045822
Test: Launched various combinations of split tasks,
also tapped on initial view to see fullscreen launch with tasks
and intents
Flag: none
Change-Id: If3de9784b72e0f5f27f1b6d97cbf835b8f5391de
* Launching existing pair doesn't rely on any existing
data/state in SplitSelectStateController or SplitSelectDataHolder
* Consolidate launchTask*() methods in GroupedTaskView
Test: TaskThumbnailViews measured correctly, animation
correct on small+large screen, initiating split
still working
Fixes: 274540670
Flag: none needed
Change-Id: Id359f53ac5f2bba19948d4ae3231092fb90cc7c5
This patch makes changes in various splitscreen controllers to pass userId to the new shell API, to allow same-app splitting with different users.
Fixes: 274973415
Test: Manual
Change-Id: I810b5353aad738c7c275856586b9c521f1554022
* SplitSelectDataHolder contains logic for knowing how
to launch split, separate from the actual API calls to launch split
Flag: ENABLE_SPLIT_LAUNCH_DATA_REFACTOR
Bug: 279494325
Test: Tested w/ all 6 types of launches noted in
SplitSelectDataHolder#@SplitLaunchType.
Also checked to make sure most-recent running tasks are
still being used where applicable.
Change-Id: I8114f87e9956b100622c80f578e291937ed4eeac
This is the second of several patches implementing the App Pairs feature behind a flag.
This patch includes:
- AppPairsController, a new controller that will handle creation, launching, and deletion of app pairs
- ITEM_TYPE_APP_PAIR is a new type of FolderInfo (FolderInfo now can be either a folder or an app pair, and should probably be renamed to CollectionInfo or something more generic in future)
- Necessary plumbing for these new types
- Database code that handles saving a new app pair to the database with the correct schema
Flag: ENABLE_APP_PAIRS (set to false)
Bug: 274189428
Test: Not included in this CL, but will follow
Change-Id: Ie3aefd4eb9171f471789f54876de742849d3013b
Implement two intents or shortcuts to active split with shell
transition.
Fix: 259368992
Test: manual
Test: pass existing tests
Change-Id: If65ddbe6486a8bb1766019c6e05ac2cc5cbe08fc
This patch fixes a bug where split screen did not fully support launching intents with different users.
The bug arose because SplitSelectStateController only had one place to store user information about the staged intent, mUser, but this disregarded the fact that the secondary app could also be passed in as an intent, and could belong to a different user from that of the initial app and the existing context. We need to support this case now since we now allow second-app selection from Taskbar.
Fixed by splitting the field into mInitialUser and mSecondUser, which will be tightly bound with mInitialTaskIntent and mSecondTaskIntent to make sure that Intents are always launched with the correct UserHandle.
Change-Id: I1ec49c75d562e4309a41d98010f0eff113c81e9d
Fixes: 275410160
Test: Manual
Merged-In: Ic904672769be8fd116180d457b36eb567c5ee304
Adding debug-names to remote transitions so that
they can be identified across processes
Bug: 276349701
Test: existing tests since this doesn't change logic
Change-Id: I41400feeb2dd91971f8c750613085c80af309aea
* Created SplitAnimationController to prevent more
RecentsView bloat
* Extract SplitSelectSource attributes into separate class
* http://recall/-/cMb5xTTxhmZtFt04eYnmQj/eACJq1un8Ef91LgmQblpAw
Bug: 267370106
Change-Id: I5d430c091ac84bbbc30319e7b78711b610a21252
This patch fixes a bug where Taskbar would not differentiate between user profiles when selecting an app to launch from Overview.
The bug occurred because findLastActiveTaskAndRunCallback(), which checks for already-running tasks when launching an app from the Taskbar, only checks for a ComponentName match and not a userId match.
Fixed by making the findLastActiveTaskAndRunCallback() also check for a userId match.
Fixes: 270456926
Test: Manual
Change-Id: I43ff06083a5dce775fdbd0b0ed951beaae34c0ab
* Moving things out of RecentsView to avoid
dependency on a non-testable class
* Also helping prevent bloating RecentsView.java
Bug: 266482558
Test: Single Chrome instance in recents. Initiate split
with Chrome from workspace, tap on Chrome again in Taskbar,
ensure no crash.
Change-Id: I99ec704479ffaa860f4d80c2cb9f54182f31f41a
Starting a split pair by indicating (shortcut|shortcut) or
(shortcut|intent) was not properly supported, update to leverage
startIntens flow to handle shortcut info when starting a split pair.
Fix: 265919000
Test: repro steps of the bug
Change-Id: I9afcd6f3cdfb5530c1b440a9c0ade8c9952a5fff
* Consolidated init calls in SplitSelectStateController
* Also add support to launch from taskbar all apps
* Add logic in SplitSelectStateController to know whether
or not we need to dismiss existing TaskView vs relying
on mSplitHiddenTaskView null check
* Default click handling for SplitShortcut is to start
split selection mode
Bug: 251747761
Test: Initiated split from smart actions, thumbnail app
icon, home, taskbar in overview, all apps. Saw it choose
the latest thumbnail
Change-Id: Ib4f64e619c97615af458a19a9c0efd86c92979d9
Starting from target SDK U, we will block creation of mutable
PendingIntents with implicit Intents because attackers can mutate the
Intent object within and launch altered behavior on behalf of victim
apps. For more details on the vulnerability, see go/pendingintent-rca.
From a quick analysis, we concluded that the intents passed into
getPendingIntent() can be both explicit and implicit, so we added
a no-op FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT to bypass the above block of
mutable implicit PendingIntents.
The flag is introduced in ag/21018466.
Bug: 236704164
Bug: 229362273
Test: TH passes
Change-Id: Ia26c8f92d1b4b50e04bc6b487619f54efc7d5a1d
This patch makes it so that when the user initiates a split from Home, a running app instance is used instead of always attempting to spawn a new Intent. If no matching app instance is found, behavior is unchanged.
Previously, splitting from Home always resulted in a new Intent being staged, which ignored the fact that an app of the same type could already be running. This resulted in undesirable situations like being able to attempt splitting an app with itself in Overview.
Fixed by querying the RecentsModel when a split of this type is initiated, checking to see if there is a running task of the desired type, and using that to perform the split operation if one is found. When Overview is loaded, applyLoadPlan() will now check to see if there is a staged task, and remove the associated tile as needed. If the removed task is part of a pair, this involves creating a temporary TaskView to hold the other task.
Also fixes a bug where using the Taskbar to select one's second app would incorrectly choose the oldest instance of a multi-instance app rather than the newest.
Fixes: 257513447
Fixes: 259936298
Test: Manual
Change-Id: I97a62f34c03aa4980f9cd743e35e9fc6ef4c092d
Remove appending MULTIPLE_TASK flag when starting an intent and a task
into split screen and leave it to wm-shell to decide whether to append
the flag or not.
Bug: 255224696
Test: atest WMShellFlickerTests
Test: manual check the start intent and task flow
Change-Id: I3d887f8dcea67b12a7e94cef55850d52a79a8d2d
Add startIntentAndTask and startShortcutAndTask APIs to support starts a
pair of intent/shortcut and task to split with shell-transition.
Fix: 250875492
Test: atest WMShellFlickerTests
Test: manual check start tasks or start intent/shortcut with task flow
with shell-transition enabled
Change-Id: Ibce60f3a10e2bbc99ef17185f45680dc23ef5f48
Since split screen has transferred from stage-based model to app-pair
model. Update to remove the stage concept from split screen APIs, so the
caller won't need to deal with stage concept.
Bug: 250875492
Test: atest WMShellFlickerTests
Test: manual check start tasks or start intent/shortcut with task flow
Change-Id: I36bfb54f3f690cfafd18ba31ab23f5745ead6d97
PendingIntent#getActivity gets the owner UserHandle from the app
context. That makes the activity launch fail since the app only exists
in the work profile environment(secondary user).
This CL gets the correct Userhandle from Launcher and use
PendingIntent#getActivityAsUser to launch split task.
Bug: 242039471
Test: Launch Google chat by shortcut to enter split (work-profile)
Change-Id: Ie1db8a858bf9cee700cb3ff3a9e607a5d1dbad30
This will help SysUI test team (who uses TAPL) to set up Gradle build for their tests.
Bug: 202567877, 234414088
Test: presubmit
Change-Id: I3d923ea4b54d1a4c3d2b345be09692727d30433e
When Launcher restarts (as the result of a UiModeChange or something else), it attempts to recover its previous state. However, the OverviewSplitSelect state is unique because it requires some additional information to recover properly (the taskId of the staged task and so on). This change makes it so that the relevant information is passed forward in the recovery bundle. Launcher will now restart in the base Overview state, and then immediately apply the saved data to recover the OverviewSplitSelect state.
Fixes: 233019928
Test: Manual
Change-Id: Ie6123ef9c374be000268f82857b696c49213c541
Merged-In: Ie6123ef9c374be000268f82857b696c49213c541
* Also fix small other bug where we were
checking only for LauncherState
OVERVIEW_SPLIT_SELECT and not for equivalent
3P RecentsState
Fixes: 227419997
Test: Repro steps don't cause bug. Yay.
Change-Id: Ibb8238185b959d22d8455b6812d29b2e268d9739
Register animation start callback to RemoteSplitLaunchTransitionRunner,
so there can clear up the floating task view when entering recents.
Bug: 223397364
Test: verify no floating task view remaining on RecentsActivity.
Change-Id: Idedc7950b8954d1376960d5e74aa4c60fefa9c86
Param intentFirst is not necessary because we could use stagePosition
to ensure intent side is left or right.
Remove it and ensure start task on main stage at split side.
Bug: 218613028
Test: pass existing tests
Test: manual
Change-Id: I3b8fc74b18c4d48fe73b501be696c3d59677183b
* Consolidate setState() and setStateWithAnimation()
to be handled in the same manner
* If no animation, we run the created
PendingAnimation right away
Fixes: 209935590
Test: Tested w/ and w/o animation
Change-Id: I1d6fdba21761b6721e6bd52234016178547cd437
