test: built and tested on multiple devices. recorded videos and shared in chat.
bug: b/253520701, b/253521660, b/241813570
Change-Id: I57f88f5fb35c6a7b1219fac6e992bb84354b91ef
Prior to this change, if taskbar is showing and we are cloing an app
that is visible in the taskbar, the taskbar view would immediately
disappear.
Now we will fade out the view until the animation is 33% complete,
at which point the 'space' will be clear for the FloatingIconView
to settle at its final location.
Bug: 273961611
Test: open app in hotseat
note that the taskbar view is gone immediately
have taskbar visible, close app that is shown in taskbar
note that the taskbar view fades out
Change-Id: I5589e2ce3033cfa19669d1bfaf568aef2a96015e
with a taskbar.
Thought about using the Builder pattern here but the CL becomes
much larger due to SwipePipToHomeAnimator having its own
Builder.
Bug: 268026344
Test: swipe up to close app thats in hotseat
swipe back to close app thats in hotseat
Change-Id: Idd0729224374579753fc91c7820f3b04a7d3e1a4
For apps that use AdaptiveIcon, we used to animate the foreground
drawable independently from the background. This is sometimes
perceived as jank so we remove the animation since it is very subtle
in the best case scenario.
Bug: 268026344
Test: open/close apps/folders that use AdaptiveIcons
Change-Id: I500bf56e04823757d511d909a93d3b30703249a1
Instead of making the icons themselves move faster, we change
the startDelay/duration of the taskbar bg alpha animation
so that the taskbar is only visible when the icons are within
the taskbar bounds.
This is still an approximation. For U+, we should support taskbar
width change to fit the icons when they are in the 'hotseat'
alignment.
Bug: 273961611
Test: home <-> overview
home <-> app
stash <-> unstash
foldable/tablet
RTL
Change-Id: I39bedafac4afd641d250f7c97abf1e2de070d646
This change adds in a new animation and layout to change the existing back tutorial as part of the effort to redesign gesture navigation education for users. This temporarily uses placeholder animations for the overview gesture. Large screen animations are also added for Home and Back tutorial.
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Bug: 241813570
Bug: 253521922
Bug: 253520701
Test: Manual
Change-Id: Ied18b88a83a3b673a7cf40fd33b6013f24998e44
We only set qsb alpha if isQsbInline = true, since that is when
we draw/animate the qsb in the taskbar.
Fixes: 269164187
Test: isQsbInline = true / false
Change-Id: I92022135e74f734a8e50c606dc9c605df39a9f97
When swiping up to recents and creating the current tasks TaskView, we
were checking for proto 1 or proto 2 to be enabled. And if they were, we
were creating the DesktopTaskView object. The DesktopTaskView should
only be enabled in proto 2.
Updated the feature flag check.
Bug: 273950066
Test: enable proto 1 and gesture nav, have a desktop app open, swipe up
to recents, no desktop tile
Test: enable proto 2 and gesture nav, have a desktop app open, swipe up
to recents, see the desktop tile
Change-Id: I73a47347d60e0f57ad6cf6e363a6fe83ac8cc509
- Moved colors to final in TaskbarViewController (since controllers are
recreated on theme change)
- Clarified some variable names
- Animate from progress 1 to 0 instead of vice versa, since 0
corresponds to launcher's theme icon color which is what the alignment
animation is going towards
Test: in gesture nav with dark themed icons in hotseat, go to overview
and ensure smooth transition to ligher themed background; return home
and ensure reverse transition
Flag: none
Fixes: 271651337
Change-Id: I4451f995a3e79e512c59a834051f601ead70ff87
When desktop tasks become visible or hidden, we update a SysUI state
flag. This flag update gets processed in TouchInteractionService which
then calls DesktopVisibilityController to update launcher state based on
whether desktop tasks are visible or not.
We were getting a reference to the DesktopVisibilityController through
OverviewComponentObserver. This was causing issues when device was
unlocked with desktop tasks visible. And 3-button navigation was enabled.
In this scenario, we are immediately processing a SysUI flags update
that desktop tasks are visible again (they are hidden while device is
locked). When this update is processed, OverviewComponentObserver
returns the fallback launcher interface. And not the nexus launcher.
The fallback launcher interface does not contain the
DesktopVisibilityController. Since the fallback controller does not
return the visiblity controller, we skipped processing the update that
desktop tasks are visible. Which resulted in launcher remaining in a bad
state with home screen icons visible and desktop tasks on top.
Bug: 273594452
Test: enable 3-button nav and proto 2, move an app to desktop, lock
screen with desktop app visible, unlock screen, observe launcher icons
hidden
Test: enable gesture nav and proto 2, move and app to desktop and lock
screen with desktop app visible, unlock and observe launcher icons
hidden
Test: repeat the same steps with proto 1 enabled
Change-Id: Id52ac4cf2df151b2aee2070ee2eb14de3d74fead
Turns down the amount of translation/scale
of the animation to make it more subtle.
Bug: 271563317
Test: manual
Change-Id: I1cdd045cf4e045a9a238e71a6315d7d813e9f398
Since mTaskbarInAppDisplayProgressMultiProp is set by various states
that are hard to query in init() (e.g. state of all apps, -1, widgets,
etc.), we store the last mTaskbarInAppDisplayProgressMultiProp in the
TaskbarSharedState and restore those values in init().
Also updated some debug logs in the dump.
Test: manual: from home screen, swipe down to quick settings and toggle
Dark theme, ensure nav buttons don't translate; do the same but over
launcher all apps
Flag: none
Fixes: 267325761
Change-Id: Ib8e6778582ed39c674cd3c1e95312e673659f6a7
Tony Wickham
Jon Miranda
Hyunyoung Song
randypfohl
Jagrut Desai
Saumya Prakash
Nick Chameyev
Mateusz Cicheński
Pat Manning
Hongwei Wang
Mike Schneider
Goooler
Ats Jenk