When there's no background panel, we should ensure an opaque
background scrim is used.
Fix: 414718408
Test: Manual with all_apps_blur and all_apps_sheet_for_handheld off.
Flag: EXEMPT bugfix
Change-Id: I1ac9f5f8fbb01f2c6a42e9f79823b5f293ebf709
- Support for the GNC allows for some additional animations and clean up. The missing clean up was causing test failures
- Also fixing broken GNC support for split apps. Swiping up from split apps caused consistent crashes, however since the current 1P swipe to home has no special animation, updating the recents window and 3P GNC to match this.
Flag: com.android.launcher3.enable_launcher_overview_in_window
Bug: 377678992
Test: pre/postsubmit; swipe home from 1P and 3P launcher
Change-Id: Idf24d7969e76a50ff656f6644c2b568c42e409d7
- Apply scrollOffset directly to tvs.recentsViewCroll, which already take orientationHandler into account
- Apply gridTranslationY directly to taskSecondaryTranslation, which already take orientationHandler into account
- This make sure both translations are applied after mTaskRectTransform
- Also re-calculate tvs task size after updating orientationState rotations, as the orientationHandler might be changed and affect task position
- Remove setTaskRectTranslation that is no longer used
Flag: EXEMPT bugfix
Test: manual with central/side task launching with portrait, fake landscape and 3p launcher
Bug: 410628946
Change-Id: I8ef38d193328e8a449594515403c00f517e213b3
We previously sent the top coordinate of the bubble bar to shell.
However when the screen height changes, launcher takes a bit longer
to update than shell. So instead of calculating the top coordinate
on the launcher side, we now send the amount of space between the
bubble bar and the bottom of the screen to shell, where we can offset
that as needed.
Bug: 392893178
Flag: com.android.wm.shell.enable_bubble_bar
Test: manual
- send some bubbles
- launch app
- expand
- swipe to home
- fold and unfold
Change-Id: I57b96db49dab1e2304fde8dc55a99eaaf85e40f8
... to launch an individual task window from desktop tile in Overview
when multi-desks is enabled, until the fix for b/413378320 is landed.
Note the changes in
http://ag/q/topic:%22activate-window-from-exploded-view%22 is the right
implementation, however it will only work for multi-desks with the fix
for b/413378320 is in place.
Flag: com.android.launcher3.enable_desktop_exploded_view
Test: Manual
Bug: 413378320
Change-Id: I72914d60fb0ec2e80af6faa7441a67e743720c38
Fix to handle failures caught by launcher.checkForAnomaly so that they
are also reported to the test watcher.
Bug: 406906811
Test: presubmit
Flag: NONE Not production code
Change-Id: I379fcf09e3cd2e6321be9f4bc3dd6f3272e9c2fd
- When we clean up the recents window, the recents view gets dettached, which causes a activity leak in tests and prod through RecentsView.mOnTaskLaunchCancelledRunnable. Fixing this leak across all uses of RecentsView, rather than just for RecentsWindowManager
- Also cleaning up a potential leak in RecentsWindowManager.callbacks
Flag: com.android.launcher3.enable_launcher_overview_in_window
Flag: com.android.launcher3.enable_fallback_overview_in_window
Bug: 377678992
Bug: 292269949
Test: swiped up from running app, checked leak canary and heap dump; pre/post-submit tests
Change-Id: Id95b36dad6e41e5b21d1af8ede489f84ef987e50
When we show a new flyout, it is possible for the previous flyout to
still be there and animating out.
We were removing the existing flyout, but did not cancel the animation.
This meant that there could have been a hide animation running for the
previous flyout. Once that animation finished, it removed the current
flyout from the container. It was possible for the current flyout to
already be updated to the new one. In which case the animation for the
previous flyout hid the new flyout.
Bug: 414808503
Test: atest PlatformScenarioTests:BubbleBarTest
Flag: com.android.wm.shell.enable_bubble_bar
Change-Id: I4229297fa999d815c12eefd9d583bdfc915ec00a
It doesn't seem necessary anymore (and anyway, existing cases like
Taskbar being stashed while IME is showing handle this as well).
Removing the specific block fixes a bug where touches were going
to the underlying app even though Taskbar window is fullscreen
while editing a Folder name.
Fixes: 400859085
Test: TaskbarInsetsControllerTest
Flag: EXEMPT bugfix
Change-Id: If30acd0b3b9c3fd0b29b94ca963beb1c70162416
- In KQS existing code there is a check that returns early if a user is
trying to switch to a running task. This check returns true for a task
that is not running thus creating an issue when user tries to switch
to that task using KQS.
- While the root cause of the issue will take time to fix, this
temporary check ensures that we workaround it when flatenning
heirarchy feature is enabled. This issue happens when multi-desk
backend flag is true and flatenning flag will always be true when
multi-desk is true (given how the features are timed for release).
Flag: com.android.launcher3.enable_alt_tab_kqs_flatenning
Test: m
Bug: 414410702
Change-Id: Ia35d6706a1512efbb4feca0128a9d59cd930df2f
These were intended to be placeholders for non-quickstep builds,
but it seems soong ends up using the base version instead of the
override in quickstep. So now we always use the non-night version
which gets overridden correctly (and that color resource itself
defines a dark mode variant).
Test: mp launcherd - verify light and dark mode use themed colors.
Bug: 414732288
Flag: com.android.launcher3.all_apps_blur
Change-Id: I21bf8e66bf1715a8b3532931ed64725ccc3f86b9