Previously the navigation bar and taskbar were incorrectly using the
back dispositon state as the source of truth for the IME visibility.
While this can only be set while the IME is visible, it can (and is)
also unset despite the IME still being visible. This was fixed in [1].
While the taskbar previously did not take into account the back
dispositon state, by the IME visibility changing, the rotation of the
back button would also change, leading to an equivalent state. However,
with the fix from [1], this would no longer happen, with one scenario
being showing the IME and then the IME swithcer menu, which temporarily
unsets the back disposition mode while the menu is visible.
This propagates the back disposition state to SystemUI, so taskbar can
respond to changes in this value, rather than in the IME visibility.
[1]: Ic57cea49f5ff49132802083b4f0c9b0e82db1cf7
Flag: EXEMPT bugfix
Test: switch to 3 button nav, show IME, show IME Switcher menu,
observe back button rotation
atest NavigationBarTest#testSetImeWindowStatusSysuiState_ImeVisibleImeSwitcherButtonVisible
NavigationBarTest#testSetImeWindowStatusSysuiState_ImeVisibleImeSwitcherButtonNotVisible
NavigationBarTest#testSetImeWindowStatusSysuiState_ImeNotVisibleImeSwitcherButtonVisible
NavigationBarTest#testSetImeWindowStatusSysuiState_ImeVisibleBackDispositionAdjustNothing
Bug: 366129400
Change-Id: Ib05f9263afb754724021b5f3e48520eff5dad398
This renames the SysUI states related to the IME and IME Switcher button
visibility from "shown" to "visible", to maintain consistency.
Flag: EXEMPT refactor
Bug: 366129400
Test: n/a
Change-Id: I45219e62b633ca984de98df43f5c238604b38109
The taskbar and bubble bar were using both the visibility of the IME and
that of the IME Switcher button to determine whether these bars should
be stashed. However, the IME Switcher button will never be visible while
the IME is not visible, so using its visibility is redundant.
This changes the stashing logic to only take into account the IME
visibility. Note, the IME is also considered visible even when a
hardware keyboard is connected, regardless of any UI being visible or
not. This visibility state determines various system behaviours.
Flag: EXEMPT refactor
Bug: 366129400
Test: open the IME and IME Switcher menu on large screen devices;
observe taskbar behaviour
Change-Id: Ibcd16896582ca575538d8c1c3d2ab879090d075c
The code related to this flag was removed in [1], but the flag
declaration, and two no-op usages were left over.
[1]: I1de7fa061a6c6aba9f949a0bcf8cfced84273e3f
Flag: EXEMPT cleanup
Test: n/a
Bug: 366129400
Change-Id: If3d0751e0a9035ba8b0c66250df9339856788171
This cl also removes forced hidden annoucement and focus for Bubble Bar since they are annouced together.
we are keeping the tasksbar show annoucement and focus since it is only way to notify user of taskbar being shown on screen until we figure out proper solution with talkback team.
Test: Manual, Presubmit
Bug: 383928453
Flag: EXEMPT bugfix
Change-Id: I2c32ea393da2509af49e2fce795759a6903b0451
Add debugging logs to understand why taskbar root layout would be null.
Flag: EXEMPT not adding new behavior
Bug: 382378283
Test: Manual
Change-Id: I1140360274667a6c3766f03e1f5f1592c09e13e1
See go/refactor-group-task for details. This CL introduces `SingleTask`
and `SplitTask` and makes `GroupTask` abstract.
Bug: 388593902
Test: m
Flag: EXEMPT pure refactor with no behavior change.
Change-Id: I96d0eb0600420ce5cb2fff30ed9d766224b6961e
Update debugging logs for TaskbarManager to be display specific.
Flag: EXEMPT not adding new behavior
Bug: 390004132
Test: Manual
Change-Id: I0222e3bce94bee410b3572d1bc820cc71a2c1a68
Added an IPC call to inform the Bubble Bar in the launcher process
of drag events from the shell.
Bug: 388894910
Flag: com.android.wm.shell.enable_bubble_bar
Test: Manual. Check that events from the shell process successfully
reach the launcher process.
Change-Id: I01615911ce7e4250138aedaa5823f639b9163ff0
The issue: we were blocking the opening of existing app in when multi-instance flag was tunred on.
The Solution: we don't actually need to do this since, the multiple taskbar icons of the same app are blocked pm TaskbarRecentsAppsController
Test: Manual, Presubmit
Bug: 391143101
Flag: EXEMPT bugfix
Change-Id: Ic2aa7cca4fd18d9b8cf48a2778c6e666241a4f7f
Add two new APIs for multiple desktops:
- `createDesk()`.
- `activateDesk()`.
Currently these APIs are not hooked up yet. This will be done in
follow-up CLs.
Also removes the unused `getVisibleTaskCount()` API.
Bug: 390715986
Test: m
Flag: com.android.window.flags.enable_multiple_desktops_frontend
Change-Id: I363f0e520f649572156047ebcd4ed6e542d77dc1
Flag the change to use the previous class.
Fix: 391107339
Test: Manual.
Flag: com.android.launcher3.enable_expressive_dismiss_task_motion
Change-Id: Icf139fc0d6744766da548f2137597b2b020863c1
onDisplayRemoveSystemDecorations() is a new method in IOverviewProxy.aidl
Bug: 352461502
Flag: com.android.server.display.feature.flags.enable_display_content_mode_management
Test: manually (adb shell settings put secure mirror_built_in_display
{1|0})
Change-Id: I42d96ef27fd62d35ae1ca6134bd74752de3a2b5d
When tapping an icon in the AllApps tray, before this CL, we would use
the WM Shell API startLaunchIntentTransition() to launch a task for that
app icon. However, this would break the window limit logic since in WM
Shell (startLaunchIntentTransition()) we think we're launching a new
task, when in fact we're just moving an existing one to the front.
With this CL we instead reuse the showDesktopApp() API whenever the app
we're trying to launch has an already visible / minimized Desktop task.
Bug: 391365151
Test: launch visible Desktop app from AllApps - doesn't overtrigger
window limit
Flag: com.android.window.flags.enable_desktop_app_launch_transitions_bugfix
Change-Id: Ia3638012226fe28c853ec6cfd0523a8fb23b8961
Updates taskbar and KQS to show (running) desktop tasks when taskbar is
shown on the home screen - adds `shouldShowDesktopTasksInTaskbar` method
to TaskbarDesktopModeController to be used instead of
`areDesktopTasksVisible*()` to determine whether to show desktop tasks
in the taskbar. The method, in addition to desktop tasks visibility,
also considers whether taskbar should be shown on the home screen, and
whether current launcher state is home.
The launcher state is fetched from `TaskbarStashController`, which
already keeps track of this state. This is likely not ideal, but can be
removed in the long term - see http://b/390665752.
Furthermore, updates ReventsModel login not to always filter out desktop
tasks with no non-minimized tasks (which is currently expected behavior
in overview) in `getTasks()`. The filtering is now done by the filter
passed to `getTasks()` method, instead of when processing tasks in the
background. The filter used by default is updated to filter out such
desktop tasks, but callsites from `KeyboardQuickSwitchController` and
`TaskbarRecentAppsController` are updated to use an empty filter, so
they can display desktop tasks when they're all minimized.
Bug: 376711722
Bug: 390665160
Test: Manual on desktop device - verify that taskbar and KQS when shown
on home screen display desktop tasks, including the case all tasks are
minimized.
Flag: com.android.window.flags.enter_desktop_by_default_on_freeform_displays
Change-Id: Iabc22e20bf64aa9a826b4a5952f1edc6ea639cdc
Revert submission 31332401-recents-device-state
Reason for revert: DroidMonitor: Potential culprit for http://b/391684419 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:31332401-recents-device-state
Change-Id: I3986328ee3aa8ebb822f7ef05b9f80ef68872aef
