If the user swipes to go home before the Launcher can startup properly,
the user will be stuck on a black screen after swiping up to go home
after reaching the AllSet page after completing the setup wizard. This
change forces the device to go home if the go to home swipe is going to
fail (aka if the Launcher hasn't finished initializing).
Bug: 261901912
Test: Manually verified the device doesn't get stuck like before. UX is
not perfect since the Launcher still needs to load for a few hundred
milliseconds, but the user doesn't get stuck on a black screen.
Change-Id: I8590e7ec1e341ba17db853900de7186284b07e93
Use the same PipContentOverlay in Launcher as in WMShell, this should
further make it easier to experiment the app icon overlay (solid
background with app icon as an overlay).
Bug: 265998256
Test: Enter PiP from Google Maps, ensure the content overlay works
Change-Id: I1ce008700da44bdc28b9515e03aeb3c9c9633f59
- Add option for the rotation button to be positioned to the right
when in ROTATION_0
Bug: 265197526
Test: atest FloatingRotationButtonPositionCalculatorTest
Test: foldable-folded (floating rot button in sysui, natural rot=rot_0)
foldable-unfolded (floating rot button in launcher, natural rot=rot_0)
tablet (floating rot in launcher, natural rot=rot_270)
Change-Id: I856a0be2e10fceb34254cd58ceb58dfa8a1819bd
- Rename isInAppAndNotStashed to areTaskbarIconsVisibleAndNotStashing,
and check taskbarViewController.areIconsVisible() accordingly. This
effectively handles the same as before, but also handles Overview,
which is not inApp but does have areIconsVisible()
- This fixes bubble scrim over overview taskbar, as well as showing
taskbar background behind assistant in 3 button mode.
- Also fix nav bar button dark density changing when applying the
separate background for assistant
Test: Open bubble and invoke assistant in overview, over IME, inside
an app, over home
Fixes: 266715337
Change-Id: Ie655de7abd1634e2165543d57664d7c7e054a986
These are temporary UI updates until the redesigned gesture nav tutorial is ready.
Fixes: 265857697
Test: ran tutorial on large screen device
Change-Id: I3e50de1b0f5cd9e84dccea17c7ac07d3668e1168
Currently, TaskBar expansion is allowed when an activity context is
available. Since Dreams are implemented as an activity, this leads
to being able to expand the TaskBar over a dream. This changelist
updates the logic to not allow system gestures when dreaming.
Test: manual
Bug: 265755700
Change-Id: If58608c1e491da7906a2615681da0514fa49cfc8
Merged-In: If58608c1e491da7906a2615681da0514fa49cfc8
Starting from target SDK U, we will block creation of mutable
PendingIntents with implicit Intents because attackers can mutate the
Intent object within and launch altered behavior on behalf of victim
apps. For more details on the vulnerability, see go/pendingintent-rca.
From a quick analysis, we concluded that the intents passed into
getPendingIntent() can be both explicit and implicit, so we added
a no-op FLAG_ALLOW_UNSAFE_IMPLICIT_INTENT to bypass the above block of
mutable implicit PendingIntents.
The flag is introduced in ag/21018466.
Bug: 236704164
Bug: 229362273
Test: TH passes
Change-Id: Ia26c8f92d1b4b50e04bc6b487619f54efc7d5a1d
This reverts commit c5985751c4.
Reason for revert: Confirmed with Manasi that we don't want to have a different behavior for the trackpad gesture even if it starts from the task bar area. It should be treated the same.
Change-Id: I5817c477968545e452d7600d43825209e2c75c37
This CL adds a layer of OnBackPressedHanlderRouter to Launcher:
1. 4 OnBackPressedHandler(s) are added in such order: auto cancel action mode handler, drag handler, view handler and state handler
2. first handler who can handle back will handle the entire back gesture
3. Let WidgetsFullSheet to handle widget to all apps transition
Bug: b/260956481
Test: manual
Change-Id: Idbce3dcec746226dd68aaabaddc8fe01334e9673
Currently, TaskBar expansion is allowed when an activity context is
available. Since Dreams are implemented as an activity, this leads
to being able to expand the TaskBar over a dream. This changelist
updates the logic to not allow system gestures when dreaming.
Test: manual
Bug: 265755700
Change-Id: If58608c1e491da7906a2615681da0514fa49cfc8
When transient taskbar is opened, launcher state updates to background
and then quickswitch. Quickswitch launches the last task which is the
DesktopTaskView when desktop tasks are visible.
DesktopTaskView launchTasks is called which ensures that desktop tasks
are visible on top again and launcher state updates to normal.
If launcher state moves to normal with animation, the task views for any
visible desktop task flicker on screen. To remove this flicker, stop
animating state transitions when moving from DesktopTaskView back to
home screen.
This can be readdressed when implement a proper recents animation.
Bug: 263264985
Test: enable transient taskbar, put some tasks on desktop,
swipe up to show transient taskbar, observe no flicker
Test: have some tasks on desktop, swipe up to overview, click on desktop
tile, observe they are brought to front
Change-Id: I6ee5c55d9b805d6ef6d58ea137e697ccd40cda29
We only want to prevent updating taskbar stash state during
the swipe-to-overview gesture. Previously, we were blocking all
resumes into a "non-aligned-with-hotseat" state to prevent the
taskbar from hiding until the gesture completed. This, however,
also selected for situations where the launcher is resumed
directly into Overview outside of a transition (which is
triggered by some Tapl tests).
This narrows the check to only when resuming into a non-interactive
state (which basically just selects for BackgroundApp state).
Bug: 266246618
Test: TaplTestsQuickstep on a device with taskbar
Change-Id: I414ba7384f4ca3901211855b26c6c200319a2996
This is eventually allow us to move all register to background thread
Also creating a single ScreenOn tracked which is used at multiple places
Bug: 264465756
Test: Verified on device
Change-Id: Ibadf9ca43218e578954420d97a733adfa0a94fc7
Merged-In: Ib410e5bf02773cefde5bf0a0a1f2f1c108718d24
