- isHomeAndOverviewSame now returns true for launcher in window
- added isHomeAndOverviewSameActivity to differentiate specifically
when Overview is hosted in the Launcher activity (currently only
used for launcherChildTask handling, which we can clean up in a
follow up change)
- overviewIntent now equals homeIntent for launcher in window
- fixed containerInterface to always use FallbackoverviewInWindow
when overview-in-window is enabled; this means TaskbarManager
gets the proper RecentsViewContainer for creating the correct
TaskbarUIController
- updated getSwipeUpHandlerFactory based on isHomeAndOverviewSame
change above
Fixes: 401382430
Test: InputConsumerUtilsTest, manual
Flag: com.android.launcher3.enable_fallback_overview_in_window
Flag: com.android.launcher3.enable_launcher_overview_in_window
Change-Id: Ie8edd55b47d6438af36b9d2a788d72d69afa02f3
To ensure consistent, controllable Taskbar in Connected Displays Behavior, move all independent calls to the singleton DisplayController's various methods into one place in BaseTaskbarContext, where we have access to the parent context and can override default behaviors of these methods throughout taskbar if in external display.
Flag: EXEMPT not adding new behavior
Bug: 401553128
Test: m
Change-Id: If9efc0cfc18bac3ee75bb64bf5280ea979d1faa2
When all windows on external taskbar are closed, exit desktop mode is trigggered. We stop this signal from destroying the external taskbar. This is because we want to be in desktop mode as long as we are connected to a non-mirroring display.
Flag: com.android.window.flags.enable_taskbar_connected_displays
Bug: 401553128
Test: m
Change-Id: I23b61172bb13f1377c4532a56e7838fbe2140f20
All input consumers should be associated with display IDs, especially since these are used by TouchInteractionService.onConsumerInactive and they will be using per-display objects.
Flag: com.android.launcher3.enable_gesture_nav_on_connected_displays
Bug: 382130680
Test: InputConsumerUtilsTest
Change-Id: Ic14121db2361da1f0a819221b85256b1b3926774
This CLs removes DeviceProfile of the display before destroying the
taskbar in onDisplayRemoved(). This makes sure DeviceProfile is null
when destroyTaskbarForDisplay() is called in onDisplayRemoved(), so that
removeTaskbarRootViewFromWindow() can be executed when display mirroring
starts.
Bug: 401180264
Test: adb shell settings put secure mirror_built_in_display 1
Flag: EXEMPT bug fix
Change-Id: I42cb8a1ecfdf1aa57d8ee3d01242a156f8a92cd9
This enables blur both for Taskbar and Launcher, but in slightly
different ways.
For Taskbar All Apps, we apply blur to the overlay window, and
for Launcher All Apps, we utilize the existing DepthController to
blur the wallpaper window. For similicity, we currently fade out
workspace/hotseat to avoid awkward view + window blurs which
don't look that good. This is not the POR, but I think it achieves
most of the effect and will help us get some blur exposure.
Separately I will continue to investigate options such as blurring
workspace in a clever way so it feels blended with the wallpaper,
reusing the Taskbar window and connecting it to LauncherState, or
using a SurfaceView (though I spent quite some time trying this and
it seemed the same as the original issue).
In both cases, we use a 20-30% opacity scrim with a set color, and a
panel that blends 40% opacity of a dark/light color with 10% white.
Also updated some incorrect isTablet checks which really should have
been checking shouldShowAllAppsOnSheet(), which includes the
all_apps_sheet_for_handheld flag.
Demo: https://drive.google.com/file/d/1Ov9Dg3R9YHNfisfxNf97ZIhlDeEA1IWj/view?usp=sharing&resourcekey=0-l_SDpqpS4HtOb10a3b_jNg
Other upcoming improvements: interpolator tweaks, colors of things
inside the app panel (tabs, private space, search results, etc).
Bug: 400827727
Bug: 371343636
Test: Manual
Flag: com.android.launcher3.all_apps_blur
Change-Id: Ic7063cd822f39a5977715b5477f825bf11e57bdf
Eligibilty of perceptible tasks is no longer configured per device. It
is now determined based off of system capabilities (supports PC mode or
freeform windows) - "desktop mode".
Bug: 397076790
Test: Manual
Flag: com.android.server.am.perceptible_tasks
Change-Id: I5932d6f82b40cbe7d78b3c485351b3729fcfeb27
Update SimpleBroadcastReceiver API to pass in broadcast permission and
register Growth Broadcast Receiver with permission to prevent other apps
from triggering Growth Nudge on their behalf.
Flag: EXEMPT add separately
Test: Manual
Bug: 397739323
Change-Id: I3a9d5e131ced752af0a1b35d400eed6d170fc81e
The gesture handle still persists in conjunction with the three buttons. In addition to being forced into three button mode, the taskbar on external displays needs to never enter transient mode. More info and before/after images on bug.
Flag: com.android.window.flags.enable_taskbar_connected_displays
Bug: 399718805
Test: Manual
Change-Id: Iff5c297c8ac4823fa24e7a8e4becd0447224cac0
Flag: com.android.launcher3.enable_fallback_overview_in_window
Flag: com.android.launcher3.enable_launcher_overview_in_window
Flag: com.android.launcher3.enable_state_manager_proto_log
Flag: com.android.launcher3.enable_recents_window_proto_log
Test: built and ran locally with flags on and off
Bug: b/401073215
Bug: b/401073401
Bug: b/401075030
Bug: b/401076625
Change-Id: I1bd2822d20f677445610b912dd82ff160bff4143
The problem: with taskbar animation for Desktop mode we were checking, if we are already in DW then don't recreate taskbar. This was put in as condition so where DisplayController Info change we don't recreate twice. first being from transilition listerners and second being form info change in display controller.
The solution: Ignore the info change listener when there is already ongoing recreation is in progress.
Test: Presubmit
Bug: 399826787
Flag: EXEMPT bugfix
Change-Id: Ib86e79b3b4c86e515e44d1d1dd7ca98ed694c365
Flag enablement is for desktop devices only.
Bug: 395538503
Test: Manual
Flag: com.android.server.am.perceptible_tasks
Change-Id: Ifa13e42de5592bcd5e6a57ab574b6dc4f8710dd9
If taskbar is shown on home screen, have the taskbar all apps button
toggle the launcher activity version of all apps UI. This makes the
behavior consistent with how all apps system action (keyboard shortcut)
works, and addresses a gap in functionality where users are unable to
drag apps from the taskbar all apps UI to the workspace.
Bug: 392118517
Flag: com.android.window.flags.enter_desktop_by_default_on_freeform_displays
Test: On desktop device, toggle all apps from taskbar on home screen,
drag and app from all apps to workspace.
Change-Id: Ida0f230bf38c6e1e35041556f33de1be85daf785
This changes the ILauncherProxy.aidl interface to also allow propagating the display id from SysUI to launcher for each SysUIState update.
The SysUI part of filling SysUI state correctly has not been implemented yet. But for now, only default display flags are propagated anyway.
On the launcher side, the sysui state is propagated correctly to each taskbar instance (there is one for each display)
Bug: 362719719
Bug: 398011576
Bug: 399371607
Test: LauncherProxyServiceTest
Flag: com.android.systemui.shade_window_goes_around
Change-Id: Ic9fa55ca82e4fe395a915c4d611afc8835c5d65d
The growth broadcast receiver will be used to receive broadcast from
Growth Framework and show a nudge on screen.
Refer to go/al-growth-framework-nudge
Test: Manual
Bug: b/396165728
Flag: com.android.launcher3.enable_growth_nudge
Change-Id: Iebf006c733f6f9d079a4c3b03d78fb7c9dd3e5e7
This Cl includes
- addition of entry/exit callback methods in DesktopVisibilityController.
- taskbar manager now listens to desktop mode changes.
- TaskbarBackrgroundRedererer can now individually animation backgrounds for transient and persistent taskbars
- new channel for taskbar icon alpha added to TaskbarViewController
- new animated float to handle background alpha while we are recreating taskbar with animation.
Solution:
we use the callabck we get from DekstopVisibilty for entry/exit to first change logic of when we are considered inDesktopMode. Upon entry/exit we notify display controller for info change.
we also at notify taskbar manager who is now a listener to the desktop mode change and start the recreate process. TaskbarManager first animates existing taskbar out of user view and then follows the original recreate flow.
Test: Presubmit
Bug: 343882478
Flag: com.android.window.flags.enable_desktop_windowing_mode
Change-Id: Ib827564cacd194f499e7d9b1965e2bb13e3548ab
Only allow for new taskbars when wm.shouldShowSystemDecors=true.
Bug: 397250946
Change-Id: I29577224e763ca44a2b1878691dce3e3aa1534ff
Test: m
Flag: com.android.window.flags.enable_taskbar_connected_displays
Mark all tasks on launcher as perceptible tasks.
Flag enablement is for desktop devices only.
Bug: 370890207
Test: Manual
Flag: com.android.server.am.perceptible_tasks
Change-Id: Ic9022dcb07f2fc2d1bd1277bc1a83233ebc5626e
Unless explicitly annotated, parameters in java are by
default nullable. There are a few cases where a null context
may be passed to the unregisterReceiverSafely function
of SimpleBroadcastReceiver.
To mitigate misuses or incorrect contexts being passed for
register vs unregister, keep the context as a strong reference
in the constructor.
Also added NonNull annotations for any public callsites to
enforce behavior.
Bug: 395019017, 395966395
Flag: NONE - bug fixed
Test: manual - presubmit
Change-Id: Ie371fa45cadceaf51cf184b446df9123ef27c337
And make DisplayController display id aware
Test: locally tested on Tangor
Flag: EXEMPT refactor
Bug: 392858637
Change-Id: I805cd7323c48a2988c95b9fda7f6cfe4c153860c
This reverts commit ce9ad064d6.
Reason for revert: <Potential culprit for b/395855288 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted>
Change-Id: I12d1eb66ae03e2638a503c103d0b1fa8a863b6b5
> Using callback patter for various change events instead of routing it
via TIS
Bug: 386288280
Test: Presubmit
Flag: EXEMPT refactor
Change-Id: I95577d6a1c17103cb947ef1200c1c22b68fd1d9c
Use variable constrained within TaskbarManager for primary displays and add external window contexts as new displays are added. Ensures the lifecycle of window context map isn't tied to the required instances of primaryWindowContext.
Test: m
Bug: 395702003
Bug: 393984037
Bug: 391653300
Flag: com.android.window.flags.enable_taskbar_connected_displays
Change-Id: Idc461b8e6e249060feffac703dff1bf7d5974512
- This change will not render KQS on connected display (CD) even with the flag ON as taskbars are not yet created for connected displays.
Bug: 382762871
Change-Id: Id59fb23630aaf0e74c35818f2a4ca56e5ef2e7bb
Flag: com.android.launcher3.enable_alt_tab_kqs_on_connected_displays
Test: manually built and run the CUJ
Create a new New NavigationBarPanelContext per instance of taskbar object for each new instance of taskbar.
Test: m
Bug: 394421505
Flag: EXEMPT not adding new behavior
Change-Id: I6c82140fac9e6a00f0462ea1a593c13f49c3deee
Make Window Contexts also follow map pattern.
Flag: EXEMPT not adding new behavior
Bug: 391706879
Test: Manual
Change-Id: Ib0672e653b9dbfcb3597210ca244f110515cd4dc