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
1. Changed Preload Icon UI to be grayscale while the app is not startable.
2. Added progress bar for when app is installed but still ownloading.
3. Updated Preload Icon progress and click handling to use new incremental api.
Progress bar color updates will follow in a separate CL.
Demo: https://drive.google.com/file/d/1H1EvtTorLeJwC1eiq10tm-TT81YZ6osk/view?usp=sharing
Bug: 171008815
Test: manual
Change-Id: I5874a5146d79a8c91d7d90ff0b9c1c427a3c95dd
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
Set newOneHandedSettingsObserver() defaut value 0 to prevent
blocking swipe-down notification's OneHandedModeInputConsumer
.onStartGestureDetected() when device first booting.
Bug: 175084985
Test: rebuild ROM image and manual
Change-Id: I5fe7d4036ac74682ae72cf210e8b40c63ceb53e1
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
Bernardo Rufino
Ice Chang
Becky Qiu
Schneider Victor-tulias
TreeHugger Robot
Sunny Goyal
Jason Chang
Hongwei Wang
Tracy Zhou
Vadim Tryshev
Tony Wickham
Jon Miranda