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
- Added support for escape(backtick on some keyboards) keyboard keys
- Added support for d-pad left and right keyboard keys
- Fixed janky behaviour when quick switching too quickly.
- Removed unused code
Bug: 269618928
Test: Tried quick switch very quickly, tried escape, d-pad left and right keys in RTL and LTR modes
Change-Id: Ie03207cb349891e9c2de18502f3f65b7c8f9c018
- We need to reset icon alignment whenever icon layout bound
changes. This fixes the issue where we build an icon
alignment animator before any of the views are laid out.
- Separated animation logic between.
createTransientAnimToIsStashed and createAnimToIsStashed
* The values still require a bit more tuning but this gets us
a lot closer to spec for many of the motion polish.
Bug: 267806083
Bug: 246634367
Bug: 246635237
Test: manual
Change-Id: Id122134b22ef4e418ce632e4a8137239dc8bb313
Adding KeyboardQuickSwitchView and associated flows.
Test: Manually tested alt-tab and alt-shift-tab in and out of overview on a tablet and phone
Bug: 258854035
Change-Id: Ifb48b005067b3a9c66acfd5ecdbae144b359d3be
Preparatory change for adding the KeyboardQuickSwitchView and associated flows.
Test: Manually tested alt-tab and alt-shift-tab in and out of overview on a tablet and phone
Bug: 258854035
Change-Id: I468481a023e82d3ef7c7d4d44c5b9435173b49ae
This change is a minor cleanup to make a function more streamlined.
Bug: 265244769
Test: Manual, confirmed no regression
Change-Id: I557246a7633b10701adf75aaba6930f25e1c30aa
This patch makes it so that the correct task will be chosen when selecting a second splitscreen app via Taskbar.
Prior to this patch, the Taskbar app selection function -- which attempts to match the tapped icon to a running TaskView -- assumed that the TaskView in question was always a solo (non-grouped) Task. This resulted in the wrong app being selected for split when the desired Task happened to be the secondary app in a pair.
Fixed by checking to see if the desired app is primary or secondary, and returning the correct Task, IconView, and ThumbnailView for the split operation.
Fixes: 265244769
Test: Manual
Change-Id: Ie1122d1b49151d70dec9711fe558fba7752b7d8e
This patch fixes the following user flow:
1) App is already running
2) User initiates splitscreen from Home with that app
3) User selects the same app from Taskbar or AllApps
Previously, this caused a crash because the split-from-home initiation removed the corresponding app tile, causing a null pointer exception when the same task ID was used as a split target.
Fixed by adding a null check: if the target TaskView can't be found for any reason, fall back to launching the second app via Intent instead. If the app doesn't support multi-instance, the UI will now show an attempted split, followed by the message "This app can only be opened in 1 window."
Fixes: 263041522
Fixes: 266218404
Test: Manual
Change-Id: I39ed60c9ac758ac215391f0618f44f7fcee4f32c
* 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
This patch fixes a bug where Taskbar launches (tapping an icon on the Taskbar) were not executing correctly in Overview.
Now that Taskbar is always present in Overview, we need to handle cases where the user taps to launch an app, but the app is already visible to the user in Overview. This was breaking in a noticeable way with split apps, where the Taskbar simply wouldn't respond when the tapped app was already visible as a live tile.
Fixed by polling RecentsModel for already-running tasks, checking to see if the associated TaskView is visible to the user or not, and calling launchTasks() on the TaskView if so. If the tile is not visible to the user, the app will launch normally.
Fixes: 261952204
Test: Work in progress
Change-Id: If761546913bde7451a22456a272ba6c31942c5f8
- During gestures from taskbar all apps, unstash immediately in
transient.
- Overlay closes sooner if all apps is open (still done later for EDU).
- Taskbar stashes in overview when All Apps is opened.
- Transient app-window threshold is ignored if All Apps is opened.
Test: Manual
Fix: 262076812
Change-Id: I46b2dcdc75ee0cc15c1b47da2139ff8c20cf618a
- Transient taskbar nav threshold now works in overlays.
- Delay closing overlay to transient app-window threshold if necessary.
- Persistent taskbar no longer stashes for EDU overlay.
- EDU overlay provides enough bottom padding for transient and
persistent taskbar.
Test: Manual
Bug: 217261955
Change-Id: I2ae5612ef70a6d09e22f83f8117cdbf2a0a053b8
Fix: 260769010
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
- Added isHotseatIconTopWhenAligned to control both iconAlignment and stash animation to just fade in if hotseat icon isn't on top of the screen in the aligned state
Fix: 257355864
Fix: 213455090
Test: Launch apps from/back to home, taskbar animate from/to hotseat
Test: Launch apps from/back to AllApps/-1, taskbar fade in/out
Test: Repeat aboth with transient or persistent taskbar
Change-Id: I6bdae615ff9e199d23cbfe2d26c8d46a08fbc436
As per the latest mocks, the taskbar will be stashed during EDU to
prevent taskbar interactions that inadvertently close the EDU sheet.
Thus, this animation is no longer needed.
Test: Manual
Bug: 217261955
Change-Id: I8c5999121b7bb927b748d6163575dc4555ece84c
This patch makes it so that (when we enable Taskbar in Overview) users will be able to select their second app for splitscreen by tapping the Taskbar icon, or the icon in AllApps.
This was done by performing a check to SplitSelectStateController when a taskbar icon is hit. If we are currently in split select mode, Taskbar/AllApps icons will no longer launch their respective fullscreen apps, but instead confirm the split attempt. The confirmed app will either be an already-running instance of the app, or a fresh instance of the app (if none is currently running). The split confirmation function is located in TaskbarUIController, where it is accessible to both LauncherTaskbarUIController (for 1P Launcher) and FallbackTaskbarUIController (for 3P launchers).
Also cleans up ~2 lines of unused code from the old splitscreen instructions toast.
Outstanding issues:
- When selecting a second app from within AllApps, the AllApps shade does not animate away in a satisfying way
- When selecting a second app and launching a fresh instance of that app, the animation appears to come from the wrong location
- Intent + Intent splitting does not currently work
- If the selected app is already running with multiple instances, it picks the oldest instance. Ideally, the newest instance is preferred.
Bug: 251747761
Test: Manual testing with Taskbar in Overview flag enabled
Change-Id: I302dc092740bb880f9134ba8e2e587c4f2c29d01
- Makes taskbar threshold an absolute Y threshold
instead of a distance threshold.
- Moves handle, taskbar view, and taskbar background
during the swipe up gesture
Next CL will address transforming the nav handle <-> taskbar
and ensuring that there's a clean handoff
Bug: 246631059
Test: swipe up on taskbar, release. see bounce
swipe up on taskbar to go home, proper icon alignment
swipe up on taskbar, pause for overview, see bounce
-> further movement should not move taskbar
test launcher3
Change-Id: I141236fd72428cda7edd0ff116de1d478d18c722
This reverts commit afc3bff10b.
Reason for revert: fixing launcher tests broken by original change
We'll only add flags for transient taskbar case
Bug: 256988243
Bug: 256987492
Change-Id: I8915ef5345816316bfb71efc9fc667e4e8db824c
- Threshold to move app window
- Threshold to reach home/overview
- Threshold for window to catch up to finger
Bug: 252905206
Test: manual
Change-Id: I71082fab07a0227d64ce6ed66cbfa3c1ffb319f5
Having EDU in the same window as Taskbar causes it to be above All Apps
and other system views such as the notification tray. This change
refactors the existing All Apps window to accomodate more AFVs so that
EDU can also exist in it.
Demo: http://shortn/_Qcki3gwvf7
Test: Manual
Fix: 232177330
Change-Id: I1bef31d798041a90a0c3e033e71be63898fa5fbc
Because we check supportsVisualStashing() in
TaskbarStashController#init(), we need to avoid using
TaskbarUIController to provide that value since TaskbarUIController
isn't initialized until a bit later than the other controllers. So I
moved the logic from supportsVisualStashing() back to
TaskbarStashController, but still allow TaskbarUIController to override
it (e.g. for DesktopTaskbarUIController).
After that fix, I noticed that force stopping launcher (to test the fix)
would briefly show the taskbar background before resetting the stashed
state. This is also due to LauncherTaskbarUIController not being ready
immediately, since that's what sets FLAG_IN_APP due to launcher being
paused. To work around this, I set FLAG_IN_APP to true by default in
TaskbarStashController#init(), since that is the most common case, and
taskbar background/stashed handle isn't shown on home anyway.
Test: Force stop launcher while taskbar is stashed, verify it recreates
as stashed without background flicker; same when changing wallpaper
color on home or in app; also tested when taskbar isn't stashed and in 3
button mode for good measure
Test: testHideTaskbarPersistsOnRecreate
Fixes: 235986838
Change-Id: Ie55bd70e8288d5ad7433dde970f18c176831d747
Bug: 221455508
Test: opened all apps, widgets, -1 screen, notifications shade and keyboard in various combinations and orders; locked screen, launched app, returned home with the back/home buttons, opened overview
Change-Id: Ia0b406aacf72b34bd6b7ff1c01278ab6895a7da4
Merged-In: Ia0b406aacf72b34bd6b7ff1c01278ab6895a7da4
(cherry picked from commit 9c1a452a1d)
This is to prevent the Taskbar from flickering when the app settles in
full-screen mode.
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/dIgvinb9yEB8MYfYDx0Ijy
Bug: 218450853
Test: see video
Change-Id: I9cfb0ca151dea6951561f78798bb16bafa48eba0
Invoking the drawer is currently hooked up to tapping empty space on the
taskbar. Apps can be launched, and drag-n-drop split screen works. The
drawer can only be dismissed by acting on an app icon or tapping the
taskbar again.
Test: Manual
Bug: 204696617
Change-Id: I7c5fdbc7d54d8209f6f15ef80bfeb5e9b80cf647
This avoids changing them when going from an app to launcher (most obvious when going to overview).
This also allows us to not change insets on apps when opening/closing IME, which reduces potential jumpiness.
Finally, also use this logic for 3P launchers by calling directly from TaskbarDragLayerController instead of TaskbarUIController (which was only overridden by LauncherTaskbarUIController). This fixes some bad issues like sending fullscreen insets when opening a folder from taskbar.
Test: Open Calculator, unstash taskbar, go to overview and ensure no jump as taskbar stashes.
Fixes: 200805319
Change-Id: I4f1cc187398d0051863ff44ea90b7ab9c6aaa8f9
- SysUI removes SYSUI_STATE_IME_SHOWING when starting a gesture from an app, but because unstashing has implications on the gesture transition (e.g. clips the bottom of the app), we defer handling the ime hiding until the gesture settles. Repurposed the flow that swaps the taskbar background during the gesture to support this case as well.
- Delay the unstash when IME is closing, to align with the end of the IME exit transition
- Remove TaskbarViewController.ALPHA_INDEX_IME now that we stash when IME is opening, since stashing already hides the taskbar icons
- Also support passing a starting progress to the stashed handle reveal animation, to allow it to be reversed when cancelled. For example, when returning to an app that has IME showing, we first start unstashing because we're in an app, but then we get the signal that IME is attached so we stash again almost immediately (within a frame or two).
Test: In both 3 button and fully gestural, open a keyboard in an app, ensure taskbar gets out of the way and then reappears at the end when the keyboard is dismissed
Bug: 202511986
Change-Id: I93c298a98ba369ea6310466ff3f802231c582687
Log:
- Taskbar app launch (also from foldeR)
- Taskbar app drag (also from folder)
- Taskbar folder open
- Long press to hide taskbar
- Long press to show taskbar
- Overview Split screen action
Also add support for ActivityContext to overwrite/add to LauncherAtom.ItemInfo, which TaskbarActivityContext does to change HotseatContainer and PredictedHotseatContainer to TaskBarContainer
Test: enable logcat locally
Bug: 193009817
Change-Id: Ia82c846a727fecb8cbfd0a069c8af1276083bf83
Each icon scales and translates up, then back down. If the icon is predicted, it also plays a "slot machine" animation through random icons from AllAppsList.
Test: Visual
Bug: 180605356
Change-Id: Ia41cb0e340347eea6b580d23c8a2386837e9c399
Only when taskbar is unstashed in apps:
- Scrim workspace with the taskbar color when opening apps and in BackgroundAppState
- Crop opening apps to above the taskbar
- Crop TaskViews to above the taskbar during gestures
If taskbar is stashed in apps, behavior is the same as before, i.e. no scrim over the wallpaper and no cropping of tasks.
Added a field DeviceProfile#taskbkarPresentInApps to distinguish these cases. LauncherTaskbarUIController and TaskbarStashController ensure this value is set appropriately.
Test: Ensure tasks don't appear behind taskbar when it's unstashed; set ENABLE_SCRIM_FOR_APP_LAUNCH = true to test the whole screen scrimming when opening an app
Bug: 196257194
Fixes: 190681228
Change-Id: I481501457a5a6d49c380feea3db3b4058e4cf3f8
Also fix unstashing not working in 3P launchers by moving the unstash call from LauncherTaskbarUIController to TaskbarActivityContext
Test: long press taskbar background and stashed handle, watch it hint towards the new stashed/unstashed state respectively and then complete the animation when the long press is triggered
Fixes: 193926311
Fixes: 192926350
Change-Id: I0e538be9129bf5c600d07f360b8106d7077862ad
- Added StashedHandleViewController to provide properties such as ViewOutlineProvider to animate the handle that's shown in place of taskbar while it's stashed
- Added TaskbarStashController to coordinate the stashed state, including orchestrating the animation across taskbar controllers
- Added TaskbarStashInput consumer to detect long press in the nav region when taskbar is stashed
Behavior:
- Long pressing taskbar background animates to the stashed state by morphing the TaskbarView into the stashed handle view and offsetting the background offscreen
- We persist the stashed state across app launches and reboot; to unstash, long press the stashed handle
- We also visually unstash when going back home
Test: long press tasbkar background when in an app to stash it, long press the resulting stashed handle to unstash; while stashed, swipe up to home to also unstash until launching another app
Bug: 189503603
Change-Id: I698eff785388dff1ef717c76879719d6af236c2d
Organize existing properties as follows:
- TaskbarViewController contains properties affecting TaskbarView (though child icons are still supplied by TaskbarHotseatController)
- TaskbarDragLayerController contains properties related to TaskbarDragLayer itself
- Renamed NavbarButtonUiController to NavbarButtonsViewController, following the pattern of TaskbarViewController and TaskbarDragLayerController
- TaskbarControllers contains the different controllers to make it easier to construct, initialize, destroy, and pass them around
- Removed TaskbarIconController as its responsibilities were moved to more specific controllers
Test: compiles and runs, manually tested
Bug: 187353581
Change-Id: Idccd95d47117101bf9617e5532a5b87635d2b8f6
> Calculating the hotseat padding statically
> Animating taskbar views individually when animating to home
instead of a layout animation
> Moving all navbar buttons to a separate layout/controller and independent
of Launcher
> Fixing RTL layout for taskbar and nav bar
Bug: 187353581
Test: Manual
Change-Id: If21696f38beee328f553e467394776a8e8ed4c3e
UI fixing todo: b/187754252
Bug: 180046394
Test: Works in basic cases with on home and
in app taskbar.
Change-Id: I69985b57e38a9fdb7935fcafb097b1e6da73a6b9