- Don't report insets change to underlying app when stashing taskbar during all apps transition
- Internally override all apps insets to take stashing into account
- Don't offset all apps window by display cutouts, as we handle them internally via padding internally
- Also Fix bug where "stashing" taskbar in 3 button mode (which just fades out taskbar icons but keeps nav buttons) was reporting smaller insets to apps
Test: 1) open all apps in Calculator, ensure Calculator doesn't adjust insets and all apps has bottom content padding but no nav scrim
2) in 3 button mode, scroll to bottom of all apps and can read last row icon labels
3) enable display cutout in developer options, ensure no change to tests 1 and 2, and all apps scrim fills the screen (including behind cutout)
Fixes: 219980805
Change-Id: Ic3c6a744bc675e4ea277d22c4c0b3b353eddd905
Touches are ignored as soon as we want to start system drag so that system drag can start sooner (i.e. before any AbstractFloatingView animations finish). This approach utilizes ViewTreeObserverWrapper's compute insets listener by temporarily setting the touch region to empty. The taskbar window remains fullscreen until the drag finishes so the touch region is reset at the right point. Similarly, the all apps window is kept open during its drag operations until the drag finishes. System drag state is now exposed through the drag controller to skip predrag.
Test: Manual by dragging to split screen and triggering dismissal
animation from both windows. Verified predrag works.
Fix: 221104066
Fix: 220070070
Change-Id: I424106269c841f58cbe5338d30b6c33fbd889019
Divider bar might be hidden before swipe-up gesture started when users
touching task bar region. This makes sure to update visibility of
divider bar only after gesture started.
Fix: 219995626
Test: long press task bar region to stash/unstash task bar, divider bar
won't be hidden as long as it didn't trigger swipe up gesture.
Change-Id: Iacf690c84a3ad4b5e4fc9b066e9a1ecb8a8aa7d1
Shell transitions resumes launcher. This was causing logic in
launcher to pick incorrect inputconsumers which resulted in
aborting animation logic.
Bug: 220196913
Test: quickswitch very quickly
Change-Id: I66d894436a6cc6eae57d505db8a7abf6c10ab00f
- Introduce rounded corners (since we scale x and y differently, we can't use outline since it doesn't support rx and ry. It's achieved by custom drawing).
- Make sure the thumbnail content doesn't shift during the transition (we use custom cropping for TaskThumbnailView, and we have to do it accordingly here)
TODO: update UX of the initial split view (b/219085340)
Fixes: 194414938
Test: https://recall.googleplex.com/projects/f46cfe9c-8076-4efe-bf8a-b1cc4f1f5e1b/sessions/64953aa7-62ea-427c-8ec0-5f2bd96e4762
Change-Id: Id9a5d2f0f41cb4d619c8b3bd3a83c633e3d1f2de
- So DeviceProfile dumpsys will be available in bugreports, useful for debugging
- Only dump DeviceProfile in createdOverviewActivity if it's non-null
Fix: 221395133
Test: adb shell dumpsys activity service com.google.android.apps.nexuslauncher/com.android.quickstep.TouchInteractionService
Change-Id: Iaf7b7abd25771814be6cb918e96e042d1085debb
Test: manual
TL;DR;; this value is used for tap on qsb all apps container
atomic transition. 320 is value that used to be used in R
when all apps travel distance used to be entire window height.
In S, we reduced the travel distance to 1/3 of the height.
Change-Id: Ib66f8a4408fd77350c31c5b894d9f8b2c889159f
What's happening is that we first draw a background,
on top of it, we then draw the Task and because we
have a curvature the corners have pixels with transparency,
and those pixels get combined with the background pixels.
Most tasks have a transparent background or background
of the same color as the task so we don't see this
but for example, Telegram has a white background and
you can see this in the corners.
Fixed by creating a bitmap, drawing the background on it
and then drawing the thumbnail on top of it then using
that bitmap to draw it on the canvas.
Test: Put Telegram in recent Task (shouldn't be the first one) and you won't see a white border. Also when a task was in multitask the backgroudn should be draw.
Fix: 146521490
Change-Id: Id02a64ef472eb07900b0c7c5522d931d5b08f94e
Instead, scale down hotseat behind all apps alongside workspace.
Test: Swipe up to all apps from home; all apps button in an app works as before
Fixes: 221094533
Change-Id: Ia6f1e7bac86849018dc8d0b1d95f0bab963835a8
- Make AllApps bottom sheet solid and appears from bottom
- Teleport AllApps bottom sheet as user drag to reduce drag range
- Consider teleport interpolation for state transition sdetection
- Tuned workspace motions for AllApps bottom sheet (no translate, shrink)
- Add portrait vertical translate for tablet portrait including taskbar AllApps
- Updated bottom sheet handle and created common variables for other bottom sheets
Bug: 208599118
Test: manual on tablet AllApps, taskbar Allapps and handheld AllApps
Change-Id: I69dba5f155914cd012cc8ef3be1ef71fb2be5a40
All apps should display below system UI components such as the
notification tray and power menu, so an overlay window is more
appropriate. As a result, all apps has a separate window activity
context, but some properties are delegated to the taskbar activity
context. Taskbar should also be stashed while all apps is open.
Change-Id: I593457708779d84a0ab8b949a966d247d0a2e1b7
Test: Manual
Bug: 216843189
Fix: 217383817
(cherry picked from commit 473b980bf9)
While re-arranging icons the hotseat remains in scale 1.0f, while the workspace reduces it's scale (as defined by SpringLoadedState.java). Previously, the code to aggregate animations was assuming hotseat and workspace always had the same scale.
MultiScaleProperty.get() was being used to set the starting value of the animation. Previously, it was returning the last aggregated value. However, this value was correct only for the workspace, but not for the hotseat. Returning the current view scale makes it always correct.
Bug: 220271046
Test: Dragged icons from hotseat to workspace, and verified animation didn't jump
Change-Id: Ic01776c1d8e3967624626ed7c44d194a06295790
If icons are re-bound during the animation, they were not moved. I was able to reproduce this case 100% of times by folding, restarting launcher and unfolding. From a perfetto trace it seems that in this case `finishBindingItems` was called after the animation already started, therefore not registering any view.
With this cl, items are animated also after they are rebound.
Bug: 197834977
Test: folded -> restarted launcher -> unfolded -> verified icons are now moving towards the center
Change-Id: I5b001c502860c17d6ea5d54d099f04b2ddf1820a
With enabling shell-transition, in case of seeing status bar icon
blinking when hammer tapping on the navigation bar to trigger recents
animation quickly as CL[1] mentioned,
As the result, Launcher side still need to callback recents app
behind system bar status to signal WM if launcher should affect
system bar appearance with [1] introduced method
setRecentsAppBehindSystemBars.
Bug: 215504556
Test: manual as below steps
1) Launching a app
2) Hammer tapping on the navigation bar
3) Expect the staus bar icon won't blinking
Change-Id: I4b41e06e559168a61a29fa6ea9f58b834a7f1a1c
The launch cookie can now be transfered via the broadcast
Fixes: 220290671
Test: add Photos widget, return properly to widget
Change-Id: Ibfe9e5232317837f3111459212a4b016b5828ef4
- Determine the task in the group being clicked in split-select mode
and launch split using that selected task
- Also make sure we don't handle drag cancel twice when we are animating
the return of the drag surface
Bug: 219060441
Test: Split from home/overview with fullscreen+fullscreen task, and with
fullscreen+split task
Change-Id: I48ec0a82812197803ff4b3698830a9cb705719e3
TreeHugger Robot
Sunny Goyal
Tony Wickham
Wei Sheng Shih
Jerry Chang
Brian Isganitis
Pat Manning
Evan Rosky
Tracy Zhou
Hyunyoung Song
Alex Chau
Winson Chung
Sebastian Franco
Nicolo' Mazzucato
Mady Mellor
Vinit Nayak
Jordan Demeulenaere
Ming-Shin Lu
Selim Cinek