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
It uses AM.closeSystemDialogs() and should have the permission. I had
created the protection level in ag/13090697 but forgot to actually
request the permission.
Bug: 177228919
Bug: 159105552
Test: atest CloseSystemDialogsTest
Test: atest android.server.wm.WindowMetricsActivityTests#testMetricsMatchesLayoutOnActivityOnCreate
Change-Id: I661dac17f2160ed36adb1a193e739c200169a37d
(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
Giving the gesture nav tutorial sandbox environment a more accurate look and feel requires the ability to inject mock drawables. The choice of drawables should go to TutorialControllers.
Bug: 175019879
Change-Id: Ie5b03b3fa07b017c0596a58dedf65d3e866a0727
