Fix: 269070986
Test: manual. Install launcher3WithoutQuickstepDebug and swipe to home from within an app.
Change-Id: I1fe3d48793644d35271440e40dd028dd64e6d0cf
- 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
* Created b/268120202 to track other states of split
selection that are unhandled on 3P launchers
Test: Able to initiate split in overview with 3P launcher
Fixes: 264576761
Change-Id: I0311fe83380bf914fa79956b2565b61cc5eab916
> Making the state animator nonNull to avoid null checks at caller
> Updating the methods names to explicitely indication animation
being started or not
Bug: 265352919
Test: Verified on device
Change-Id: I1f5b47921f831ed0b202aced10825c8e1d39a4dc
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
Update LauncherInstrumentation taskbar visibility check to include assertions in fallback launcher using OverviewObject instead of LauncherObject.
Fix: 253042501
Test: manual
Change-Id: I9f2aa228e8aa97ef8ca1a4535b7f8fcded8a4572
- 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
- Refactor TaskbarManager to accept StatefulActivity instead of BaseQuickstepLauncher
- Update the new StatefulActivity in onOverviewTargetChange()
- Cleanup LauncherTaskbarUIController a bit to avoid initializing TaskbarActivityContext, TaskbarDragLayer, and TaskbarViewController in the constructor, and instead get these from mControllers after init()
Test: No change in behavior
Bug: 188790554
Change-Id: Ic4d69d73deb6dada416876eb265db57803c3adfd
Pat Manning
Alex Chau
Jon Miranda
Vinit Nayak
Sunny Goyal
Jeremy Sim
Tony Wickham