- Adds support for android.app.search.SearchTarget in plugin while maintaining plugin SearchTarget support
- Introduces SEARCH_TARGET_LEGACY temporary to switch between plugin and sdk variants.
- Maps resultType and layoutType pairs to the appropriate view
Bug: 177223401
Test: Manual
Change-Id: If8d4bb7c21c47a12447dcb0c56eed8781bd21e54
Setup architecture for separation between aosp and quickstep search as setup for switch to android.app.SearchTarget
Bug: 177223401
Test: manual
Change-Id: Iefd069a34d5e5551bf731e9171958e93377774aa
Move all the logic that calculate the app open float properties
to a separate class.
This is in preparation for the new app launch properties.
Change-Id: I1a008b2ea1379cbf667c5ad3ad58ece04bd88185
(2/n)
Define a new larger gesture height instead of replacing
existing navigation_bar_gesture_height with RRO.
Bug: 159580663
Test: manual
Change-Id: Icdd70b28d9b2629171fb60a0c9d603f6a69f076a
Fixing missing trigger when using fling gesture
Bug: 130186141
Bug: 175839420
Test: Verified fling does not work over keyboard dismiss button
Change-Id: Id15320122cf9183c591416962634561a1ddc6fa0
There are some artifacts actually come from test app implementation
- when in landscape fullscreen, sourceRectHint would include the black
background on both sides
- when settled in PiP, app does the transition which causes the final
glitch
Would address these later in the test app itself
Video: http://rcll/aaaaaabFQoRHlzixHdtY/cOco1yoMXwFzSifFqQET9U
Video: http://rcll/aaaaaabFQoRHlzixHdtY/f3IWG09DRO9aUNnzqSdPLU
Bug: 171802909
Test: see video
Change-Id: I783e51e78277b1179a7e8de50050b7c9e1a6de17
The problem is that currently upon touch down we place recents above app, before recents view is visible, so instead home screen is revealed.
Here is the breakdown:
Initial touch down -> app on top
First move event -> updateFinalShift -> recents on top
End target = home -> app on top
Fixes: 175423704
Test: manual
Change-Id: I81a4fea34c983ac2e6921f4e3515ef3193201069
- Map to progress 1 instead of dividing by 0 if expectedDuration == 0
- Map to starting progress one frame ahead based on velocity
- Change direction of velocity so it's in the same direction as the
task progress (0 is down and 1 is up).
Change-Id: I5ac3f8a0d6c616bd303ac1a902242964bb33d3c7
Pending a resolution in b/174174514, disabling the visibility-gating of hotseat and all app prediction row updates. Updates will be allowed regardless of visibility.
Test: manual
Change-Id: I10e4dae9aad9af7b799fdad3b231c734e383b493
It's 5 sec, and it works better both
for test runs under stress and for
users in the field that invoke the gesture
slowly.
Test: presubmit
Bug: 169221288
Change-Id: If1d04b63e3d490d7865b9141fc3be34a21693c39
Previously, we were using scroll direction POSITIVE as a catch all
to mean "up" but in seascape, we actually want NEGATIVE. Added
getUpDirection() to capture that. Tried to clarify the code a bit
by putting all the methods used solely by TaskViewTouchController
together with documentation. It's still pretty confusing and feels
redundant, but couldn't think of an obvious way to simplify.
Test: Swipe up and down on a task in all permutations of:
- 3 button mode
- Gesture navigation
- Portrait
- Landscape
- Seascape
- LTR
- RTL
- Home rotation allowed
- Home rotation disallowed
Fixes: 174009771
Fixes: 173567204
Change-Id: Id0f8d6f4365d888eb46182d8544d18206795dfb8
It will help finding jank in the quick switch
scenario.
Also removing tracing for cases when it's done
by the jank monitor.
Test: manual
Bug: 174892351
Change-Id: I16fc784ddb52203dba54eab2700b5a04a10088ff
