Now that b/329324086 has been fixed, we can be more certain that launcher always gets a signal to clean up from WM.
- Relanding original fix for b/285636175 with some additional error checking
- We will now check whether the recents animation start is pending on ACTION_UP
- We will now block entire swipes to prevent sending additional inputs an input consumer while the recents animation start is pending
- We will now only stop blocking inputs on ACTION_DOWN
Flag: LEGACY ENABLE_HANDLE_DELAYED_GESTURE_CALLBACKS TEAMFOOD
Bug: 329324927
Fixes: 285636175
Test: added a delay in RecentsAnimationCallbacks.onAnimationStart and attempted several rapid gestures
Change-Id: I9805114da34bf44e6b28c2a8a665e4cca88904c2
(cherry picked from commit f3f0e28762)
Merged-In: I9805114da34bf44e6b28c2a8a665e4cca88904c2
Bug: 303078360
Test: Force delay in finishing recents transition and verify with bug steps
Change-Id: I2021cc291204261de56ef9c912d8b5935059c7fb
Signed-off-by: Winson Chung <winsonc@google.com>
* Quickswitching between fullscreen and split tasks breaks split,
need that to be fixed to further test these code changes
Bug: 236226779
Change-Id: I332ad6e2d98760ec1d691dae76e8e3ab8b839c75
- If launcher repeatedly starts the recents animation, we try to finish
the existing animation before starting the new one, but due to some
ordering issues (see b/275561141) the subsequent starts can orphan
the previous animation runner, which can result in no animation callbacks
for either the previous animation (to cancel) or the new animation
(to start).
This change only attempts to reduce the likelihood of a second no-op
transition by synchronously finishing the existing recents animation
on the launcher side prior to starting the next animation.
There is one case this doesn't handle, where if the previous
onAnimationStart() has not been called back, then we can't directly
call the controller to finish, and need to rely on the no-op handling
on the shell transition side to handle the gesture.
Bug: 275561141
Test: Quickswitch and swipe up repeatedly
Change-Id: I820e26dc20fb1851ee0102ed8c114ce998d44999
- Added some missing error detection:
1. screenshot capture errors
2. recents scrolling errors
3. end-of-gesture callbacks
- Added some more explanation for OverviewInputConsumer selection reason
- Added logging the current task's package name to help identify gestures
Bug: 227514916
Bug: 243471493
Test: Ran launcher, performed multiple gestures and checked logs
Change-Id: I8b10cc75f8640a674c6fed6b06efa4763c9635a2
Since CL[1] migrate hide IME logic when quick switching split-screen
task to InputMonitor.
As a result, remove unused API since it would be no longer to
expose hideCurrentInputMethod for launcher to handle gesture.
[1]: Ibfcd48e623336c4690b71c4db0ce1ad8f5b26fc9
Bug: 166736352
Bug: 193990612
Test: manual test as steps
1) launch any apps with focusing an editor
2) from overview, select any app to enter split-screen mode
3) taping the editor to show the keyboard
4) swipe up to overview or quick switch app tasks
5) expect the keyboard will be hidden when starting the gesture.
Change-Id: I76b93af015db098e836795f72f31b663238d9a47
* Remove ENABLE_SPLIT_SELECT feature flag
* Remove unused SystemUiProxy methods
Bug: 233006032
Test: Options show up as expected
Change-Id: I9b98d962db79363a20ad41faa15404f1c156b9ec
created before TouchInteractionService is initialized
SystemUiProxy is a wrapper opject which holds the state information
until the actual proxy is initialized. It is safe to be initialized
lazily.
Bug: 221961069
Test: Verified on device
Change-Id: I1a621cad52e5b8384439ef02de6b95c6452bcb06
With enabling shell-transition, in case of seeing status bar icon
blinking when hammer tapping on the navigation bar to trigger recents
animation quickly as CL[1] mentioned,
As the result, Launcher side still need to callback recents app
behind system bar status to signal WM if launcher should affect
system bar appearance with [1] introduced method
setRecentsAppBehindSystemBars.
Bug: 215504556
Test: manual as below steps
1) Launching a app
2) Hammer tapping on the navigation bar
3) Expect the staus bar icon won't blinking
Change-Id: I4b41e06e559168a61a29fa6ea9f58b834a7f1a1c
- With ag/15023409, the system will screenshot and cancel the recents
animation based on the hint provided by launcher when there is a
global config change. As such, we can remove extra handling of the
configuration change on the launcher side, and handle the cancel
with the provided snapshot.
To handle the snapshot, we need to hook into the gesture state
recents animation callbacks (which actually are of the lifecycle of
the animation and not just the gesture).
Bug: 189843542
Test: With live-tile enabled, swipe up to overview and rotate
Change-Id: If74f3fc5d47c327f9f5cca8f1f5d23b48cd3c954
- 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
Bug: 184703546
Test: Swipe up from app with auto-enter but no source hint rect
Signed-off-by: Winson Chung <winsonc@google.com>
Change-Id: Ib6f03dc6b11d37c44d732c75adabf45d1795fefc
Test: manual, presubmit on the source branch
x20/teams/android-launcher/merge/ub-launcher3-master_master_6925377.html
Change-Id: I928b100c8f41abff34047df69d988622123f9939
Directly transition Activity to PiP mode in launcher if the Activity
claims auto-pip support. Video is taken by commenting out the
requirement of setting the auto-pip flag.
Note that we need app to actively push up-to-dated
PictureInPictureParams to the framework, otherwise we won't be get
- PictureInPictureParams on first entering
- Staled PictureInPictureParams if the aspect ratio is changed
Video: http://rcll/aaaaaabFQoRHlzixHdtY/abenIxLFI1pZzF2O8t4TbS
Bug: 143965596
Test: see demo videos
Change-Id: Iea9a6ff39a79431ac1afa14aea812c500b3ca3b2
- Get rid of the defer cancelation logic
- Render animation on the task view of the task being launched upon task view appeared callback
- Finish the recents animation upon the end of the recents window animation
Fixes: 164926736
Test: manual
Change-Id: Ibffb6a9c74c235efc8615a22b0306551532c7b61
Moving the input proxy logic outside the recents controller, so that it
is not lied to the controller lifecycle.
> Fixing input consumer not getting registered if recentsController
was not received until ACTION_UP
> Fixing input events being ignored after finishing recentsAnimation,
but before handler is invalidated
Bug: 161750900
Change-Id: Ib06617caef77f18a71c5a231e781291c3a4ee57e
(cherry picked from commit ff4b142789)
Moving the input proxy logic outside the recents controller, so that it
is not lied to the controller lifecycle.
> Fixing input consumer not getting registered if recentsController
was not received until ACTION_UP
> Fixing input events being ignored after finishing recentsAnimation,
but before handler is invalidated
Bug: 161750900
Change-Id: Ib06617caef77f18a71c5a231e781291c3a4ee57e
We should always finish the controller when requested, to ensure
everything is cleaned up immediately. But if touch is in progress,
we should keep input proxy enabled until touch up/cancel.
Test: swipe up to launcher and interact with it during the transition
- Swipe to recents and scroll it or dismiss the current task
- Swipe to home and open another app or swipe again on the nav bar
Bug: 157771305
Change-Id: Ida53289e4ecbd5e5d16933fcc79bbebdf1f8d898
This fixes the issue where the app re-appears on top if you touch
the nav bar during the animation to home.
The sequence of events leading to this behavior is pretty long,
but actually always should have happened, it was just masked
until the ag/11172732 fix went in.
Here's an abbreviated version of what was happening
on the touch down during the animation to home:
1 Set mRecentsAnimationController#mTouchInProgress = true
2 Cancel the running animation to home
3 onSettledOnEndTarget(HOME) (this is what was missing before)
4 finishCurrentTransitionToHome(), which, due to #1, doesn't
actually finish the controller, but does run the callback
5 Invalidate the handler due to #4, leading to TIS#reset()
6 Create a new handler (still from the original touch down),
which is mResetGestureInputConsumer
7 mResetGestureInputConsumer handles touch down to finish
the controller the app
This change addresses #4. Instead of calling the callback
immediately, we defer it to when we actually finish the
controller, which ensures there's no longer premature
cleanup that leads to the rest of the sequence.
Bug: 157407284
Change-Id: I0b2ff57bfa77a25c2bf1aece4b0ae7f943637ce6
- Separate the calls to minimize split and to update the flags (we only
want to minimize in split when swiping up, but we want to update the
flags when quickswitching as well)
Bug: 155410195
Change-Id: I56308cc0fbaa8a855383012738f129671d72feff
Launcher can now receive onTaskAppeared callback from
RecentsAnimationController to get remote animation target when in quick
switch mode.
Note: This CL just demonstrates how to receive callback and then
calling removeTask & finish recents animation,
in order to really improve quick switch flicking, launcher side needs
to implement the rest of logic to animate task's remote animation target
to make task switching more smoothly.
Bug: 152480470
Test: WIP
Change-Id: Id0371db7339cfe84942cc905a89b0a2c1fab62ec
(cherry picked from commit bec41bc5b9)
WM is making changes which allows apps to maintain
their orientation independent of the orientation of
the foreground app. This allows recents to always start
in portrait even when the app currently running is in
landscape. This means we have to give the illusion of
a landscape oriented overview when user swipes up in
gesterual nav when launcher is started in portrait
configuration.
PagedOrientationHandler abstracts all coordinate specific
logic from Paged/RecentsView primarily, but also all
other dynamic calculations throughout launcher.
PagedViewOrientationState is the single point of exposure
to other classes that depend on those changes. The goal
is to also minimize holding state to allow for default
implementations of PagedOrientationHandler for all the
3p/Fallback classes. PagedViewOrientationState also
holds other data around rotation that isn't
specifically tied to view logic.
The fake landscape overview can be toggled with:
adb shell settings put global forced_rotation [0/1]
Fixes: 146176182
Change-Id: I65d8d4e9f92b93931cbe0053ccaf0cda8d2ffd6c
Since divider stuff lives in sysui instead of framework
Bug: 133381284
Test: Manual, open 2 apps in split and drag-up to show
recents.
Change-Id: If6740b7ee4829bf4cac6e829e81943f16a41f977
(cherry picked from commit 3ef159becd)
- Bake overview/home component into the gesture state (it should never
change mid-gesture), this allows us to remove OverviewComponentObserver
refs from the handlers
- Move nav bar position into DeviceState
- Remove passing RecentsModel into the handlers, it already partially
references it statically
Bug: 141886704
Change-Id: I62f9138651cbe1fb984b57b96e4212ebaa1ffb5d
- Move the recents animation classes out of util into base quickstep pkg
- Clean up some local var names
Bug: 141886704
Change-Id: I1556179e203cbb43b77ea58e6fe520aa9944099b