The bug is caused by launcher saving the grid name and using that grid name
to look for matching display options. This makes sense when changing the grid
size, but doesn't work well when changing the display size.
Example: Initial Pixel display size is set to Default, so we save "normal" as
the KEY_IDP_GRID_NAME. When we change display size to Largest, the
KEY_IDP_GRID_NAME is still "normal" and so we only look at display options
under "normal". Before this, Pixel with display size set to Largest would be
set to "reasonable".
This should be safe change for Q, and we can have a proper fix when we
officially support changing grid size.
Bug: 131867841
Change-Id: If5f3b0a13b90069973e929024b26bd9b9c45a7d8
Test: Manual
Bug:112282235 P3 Starting an app from Launcher very rarely takes > 10 sec
Bug:121279417 P2 Why LauncherInstrumentation.WAIT_TIME_MS == 60000?
Bug:123900446 P1 App to home animation should zoom into the app icon
Bug:131360075 P1 [Gesture Nav] Polish/finish landscape
Bug:131854153 P1 Lots of Cuttlefish (and not only) tests are broken
Bug:132687470 P1 Swiping home from forced landscape app creates cutoff task thumbnail
Bug:132756514 P1 Sometimes (when quick switching?) user gets stuck in full-screen recents view
Bug:132917885 P1 Reduce swipe-up gesture region height in landscape
Bug:132975416 P1 Flake in NexusPredictionAppTracker.getAppPredictionContextExtras
Bug:132993129 P1 If predictions disabled, app predictions loading bar appears briefly on device restart
Change-Id: Ibfa1ed3ab6241fdb9412df2a80c11e83032008d9
(cherry picked from commit c3b21dd0480be4c64df6ac854ccb6d4923a992b2)
Test: Manual
Bug:112282235 P3 Starting an app from Launcher very rarely takes > 10 sec
Bug:121279417 P2 Why LauncherInstrumentation.WAIT_TIME_MS == 60000?
Bug:123900446 P1 App to home animation should zoom into the app icon
Bug:131360075 P1 [Gesture Nav] Polish/finish landscape
Bug:131854153 P1 Lots of Cuttlefish (and not only) tests are broken
Bug:132687470 P1 Swiping home from forced landscape app creates cutoff task thumbnail
Bug:132756514 P1 Sometimes (when quick switching?) user gets stuck in full-screen recents view
Bug:132917885 P1 Reduce swipe-up gesture region height in landscape
Bug:132975416 P1 Flake in NexusPredictionAppTracker.getAppPredictionContextExtras
Bug:132993129 P1 If predictions disabled, app predictions loading bar appears briefly on device restart
Change-Id: Ibfa1ed3ab6241fdb9412df2a80c11e83032008d9
(cherry picked from commit c3b21dd0480be4c64df6ac854ccb6d4923a992b2)
Test: Manual
Bug:112282235 P3 Starting an app from Launcher very rarely takes > 10 sec
Bug:121279417 P2 Why LauncherInstrumentation.WAIT_TIME_MS == 60000?
Bug:123900446 P1 App to home animation should zoom into the app icon
Bug:131360075 P1 [Gesture Nav] Polish/finish landscape
Bug:131854153 P1 Lots of Cuttlefish (and not only) tests are broken
Bug:132687470 P1 Swiping home from forced landscape app creates cutoff task thumbnail
Bug:132756514 P1 Sometimes (when quick switching?) user gets stuck in full-screen recents view
Bug:132917885 P1 Reduce swipe-up gesture region height in landscape
Bug:132975416 P1 Flake in NexusPredictionAppTracker.getAppPredictionContextExtras
Bug:132993129 P1 If predictions disabled, app predictions loading bar appears briefly on device restart
Change-Id: Ibfa1ed3ab6241fdb9412df2a80c11e83032008d9
(cherry picked from commit c3b21dd0480be4c64df6ac854ccb6d4923a992b2)
When device is locked, only scale down the top task as a response to
the user interaction. When user flings or lifts his finger, the task
is dismissed to go to the lock screen
LockScreenRecentsActivity is an empty activity which starts on top of lock
screen and finishes immediately. This allows us to start a recents transition
with just the top activity as the animation target. This target is then used
for swipe up interaction
Bug: 133167096
Change-Id: I466ed142ea33d626c78cb9cc5f6311bad26b8d98
When the container was present, but empty, it was showing it's background.
Bug: 133783088
Change-Id: I97b65435d66e9ced7f5487dc50a00665794f8fcd
Tested: manual
- Previously, we clamped the progress to 1 when reaching mTransitionDragLength.
Now, we allow dragging all the way to the top of the screen, and store this
new top progress in mDragLengthFactor (> 1f).
- Because the launcher animation controller is inherently bound to a progress
between 0 and 1, we have to do a bit of trickery involving interpolators.
Specifically, we normalize the progress to 0 to 1 by dividing by
mDragLengthFactor, but then we set the interpolators to multiply their
progress by mDragLengthFactor. The result is that the animation progress
appears to go from 0 to mDragLengthFactor, just like the window progress.
- To avoid scaling too small, we start interpolating the progress at a certain
point, ending at a specified max progress when reaching the top of the screen.
Bug: 131741395
Change-Id: Ie8b4b56d37249cd1456f93c110c26c78fe052dc0
This eliminates an unreliable timeout.
Also removing an unnecessary check for harness that is done by the
called method.
Change-Id: If954580060415cbb2952532c16ea0ae4dc7b9469
If we are cancelled after the animation has completed, but before the deferred frame
was captured, we set the state as cancelled, and start the new consumer with the
existing recents controller.
But after the deferred frame, we finish the controller (and since the state was set to
cancelled, do not launch the new task)
Bug: 132756514
Change-Id: If30af713c76b6d895d0b01b93d31c0e1403b7214
vadimt
Bill Yi
Winson Chung
Tony Wickham
Sunny Goyal
TreeHugger Robot
android-build-team Robot
Jon Miranda
Zak Cohen