Use focused task id for getting task size
When getting the selected task size, look at the focused task id, not
the running task id.
I believe this was a typo from the original change.
Bug: 190399315
Test: Local build and flash and run
Change-Id: Ice92e0562765f4f0142e27da0c38140df4c11425
- With live tile enabled, the race between destroying the task and
killing the process is more evident since the app may not get
stopped at all. For now, when dismissing, defer removing the
task until we've finished the recents animation to allow the
app to be stopped accordingly
Bug: 184899234
Test: Dismiss the task from overview, check that the app gets
lifecycle events
Change-Id: Ib3ea479643d65859fe4cd580b4c347b87130a69d
Merged-In: Ib3ea479643d65859fe4cd580b4c347b87130a69d
The App window will be under Launcher, so we can't actually blur
launcher at that time, otherwise the live window will also be blurred.
Test: manual
Bug: 189207458
Change-Id: Ie07449d29d3b0dc60d3787b6d32aa9e46e0bb613
When one handed mode activated, user swipe-up to exit usually
cross over the NavBar region, and then invoke TouchController
intercept touch event to trigger All Apps drawer on Home.
To enhanced the UX of gesture conflict of exit OHM & All Apps,
notify TouchController throught LauncherActivityInterface,
and Launcher dispatch onOneHandedModeStateChanged() event to
all mTouchControllers in DragLayer that touchController can
adjust the touch slop by it's SingleAxisSwipeDetector.
Test: manual trigger One handed mode and swipe-up to exit
Test: monitor minDisplacement of SingleAxisSwipeDetector
OHM activated : touchSlop x multiplier
OHM deactivated : touchSlop x 1
Test: check All Apps doesn't mis-trigger when exit one handed mode
Bug: 186235522
Change-Id: I7b9e6e7fa898231697d1866186a5f9b1717a9aa3
There is a case when one handed mode triggered(Activated), all apps
drawer is very easy to trigger while user swipe up around NavBar
region to exit one handed mode. Since System Gesture monitor regsion
is small on screen bottom, swipe-up gesture usually cross over NavBar
monitor region and invoke launcher touch controller intercept touch
event and introduce unexpectedly trigger all apps drawer.
Adding onOneHandedModeStateChanged(boolean activated) for controller
be able to adjust the touch slop by multiplier, we can set a larger
multiplier when the visible window size translate become smaller
and make swipe gesture not too sensitive.
Test: manual swipe up to swich "home <-> all apps" and monitor
minDisplacement of SingleAxisSwipeDetector
Test: Trigger one handed mode and swipe up to exit one handed mode
check the minDisplacement of SingleAxisSwipeDetector
Bug: 186235522
Change-Id: I9729cd408d85b2b22582bf800e28d1471fc06980
Don't allocate animators when there is no animation to do. The work was
not required.
Bug: 189492167
Test: Local build, run and trace analysis
Change-Id: I111768b055ed636aa92d5d9d6b799f316a568380
The call into system server is synchronous, so make the call off the main
thread to avoid jank.
Bug: 189251291
Test: Local with flag enabled
Change-Id: I1787a0ad68488755bf19e813ecfe9fc079cfaed8
- Add SKIP_DEPTH_CONTROLLER in OverviewToHomeAnim if WorkspaceRevealAnim is used, because WorkspaceRevealAnim already handles the depth.
Test: visual, and also log to ensure we only get one call to DepthController#setStateWithAnimation()
Fixes: 189060172
Change-Id: Ifb4ff3278272b3e98b4cf43bf94d6e108921ea80
The task overlay should be refreshed on size change for rotation changes.
Bug: 187515688
Test: Local
Change-Id: I1a4fa6bfbc66b9d24cfa906184bdefb9067db5ae
This handles an edge case where RotationTouchHelper#mMode starts as 3 button (by default)
* then changes to gesture nav.
* then onDestroy called
* then on re-initialization mMode will be gesture nav instead of 3-button
(it maintains state because of it being singleton).
The check to register the callback won't happen because we register only if previous mode and
current mode differ.
Don't rely on default value of mMode being 3 button when initializing
Bug: 181928969
Test: Followed repo steps in bug.
Restarted phone in all 3 nav modes and verified
expected quickswitch behavior
Change-Id: I381eba7417c4cde593edf4b9a34da55b50774e98
Need more time to experiment with interpolated + springs based approach,
will aim for QPR instead.
Bug: 189120868
Bug: 173107751
Test: manual
Change-Id: I5698bd61c92b4fa719d82f2553125fc7f65b5969
- This reset the task view's show-screenshot state to show the
snapshot the next time the task view is visible
Fixes: 186143625
Test: Enter pip w/ autoenter pip app, swipe up to overview
Change-Id: I6a1ec3d0654a33b228f97a6009145450e72e8d48
When the transition is canceled (e.g. when touching the nav bar during the transition), do the following:
- Abort the RecentsView scroll including the edge effects to ensure we get onSettledOnEndTarget() immediately.
- Jump to the current gesture end target state instead of the default rest state.
Test: Swipe up and to the left and hold to go to overview from an app, then swipe up to home during the transition; ensure that the touch down goes to overview rather than home, and subsequently that the swipe is respected and goes to home
Fixes: 189142339
Change-Id: Ie1d7dd05f45ab48968df7fdfd69fa1e1dda36d06
