1. Announce description of both snapshot in GroupedTaskView.
2. Announce them in correct order.
After setting right content description for both the apps in split mode, announcement order was reverse. Seems that order of the node tree which android sees was wrong. Also order did not change even in RTL mode.
see here https://paste.googleplex.com/6492038621298688.
The correct order is manually set using addChildrenForAccessibility in GroupedTaskView. (similarly being used in RecentsView since we use reverse order for overview). Also considered RTL.
See order after fix here
https://paste.googleplex.com/6492038621298688https://drive.google.com/file/d/1BA1YKkcNsovEu4us9cvq5xOdXviTR1OV/view?usp=drive_link
Other alternatives tried were fixing order using android:accessibilityTraversalAfter and android:accessibilityTraversalBefore, both in layout and programatically which doesn't seem to work.
Test: Manual - Using Node tree debugging of talkback developer options.(Print and filter by tag TreeDebug)
BUG: 330424779
Flag: EXEMPT bugfix
Change-Id: If3c360277bd951d2d2b223bab7844e078e9c7d27
- The shell transit flag is already hardcoded to true in Launcher
so we can remove the non-shell transit paths
- The minimized split was from legacy splitscreen where launcher would
show in a minimized state, which is no longer the case
Flag: EXEMPT bugfix
Bug: 359608026
Test: atest NexusLauncherTests
Change-Id: Idea46fc065485233b9e508dae3ebc4ee87c29ba6
Signed-off-by: Winson Chung <winsonc@google.com>
This cl includes
- adding support for listenting into when desktop window mode task is resizing and we need to adjust taskbar corner radius.
Test: Presubmit
Bug: 348335379
Flag: com.android.window.flags.enable_desktop_windowing_mode
Change-Id: Ic6ea3dc1353df7fa4b8079106f20fade0f740683
The issue existed because of taskbar insets where set to the full height
of bubble and task bars. Added check that only adds bars touch area if
the user is currently not on the launcher home screen. Commented failing
tests.
Bug: 358301278
Bug: 359277238
Flag: com.android.wm.shell.enable_bubble_bar
Test: Manual.
http://recall/-/gx8ASgewUeUS3QYohfrd1J/hcgYuHUJwfbhlvPRsvdWYf
The touch area is within the red rectangle.
Change-Id: I3c2ad3633a049972b93fe5c5e45efd557c220e1f
Code changes:
- TaskView, GroupedTaskView and DesktopTaskView now uses different resId, so it can be differentiated by TAPL
- Extracted result handling of icon loading, so we can override in DesktopTaskView
- DesktopTaskView now load icons, so titleDescription can be loaded. When icons are loaded, contentDescription are applied to respective snapshotViews; icon unloading is ignored
- Track launchDesktopFromRecents and composeRecentsLaunchAnimator in TAPL events so we can test if the TaskView launch path is correct
Test changes:
- Added TaplTestsOverviewDesktop that move 2 TestActivities into Desktop, and launch the DesktopTaskView as static and live tile
- TaplTestsOverviewDesktop is limited to Tangor/cf_tablet only, and added LimitDeviceRule to AbstractLauncherUiTest to enable @AllowedDevices and @IgnoreLimit
TAPL changes (2 APIs added/modified):
- Changed TaskView matcher to use id/task_view_* to match all TaskView types
- When Overview is launcehd from Background, mark the currentTask after the launch as liveTile. When an OverviewTask has the same accessibility node as the liveTile, it'll expect different event when launching.
- [API change] BaseOverview.getTestActivityTask can now matches mutiple test activiites, useful for matching GroupedTaskView and DesktopTaskView; Fix a bug that getTestActivityTask wrongly use `getParent()` which is RecentsView to match activityName.
- In OverviewTask.open, we'll expect different events based on TaskView types and whether it's a live tile. Launching DesktopTaskView will in additional verify Desktop header is present on screen.
- [API change] In OverviewTaskMenu, support tapping Desktop menu and verify Desktop header is present on screen.
- Removed unused OverviewTaskMenuItem
Fix: 320313527
Test: TaplTestsOverviewDesktop
Flag: com.android.window.flags.enable_desktop_windowing_mode
Change-Id: I89261c787364901320f3acb18f01ddad5f62d17c
- Hover over IconView passes to FastBitmapDrawable
- Hover over TaskThumbnailView bounds highlights the border
- Hover over TaskView outside of IconView or Thumbnail does nothing
(previously highlighted a border incorrectly)
Bug: 342594235
Test: OverviewTaskViewHoverImageTest, OverviewDesktopTaskImageTest
Flag: com.android.launcher3.enable_hover_of_child_elements_in_taskview
Change-Id: I5b0753bdec609a4a6658a35422e2823c4ed109fc
Replace usages of the old get/setPendingIntentBackgroundActivityLaunchAllowedByPermission
API with the new replacement (passing in mode = ALWAYS).
Test: atest TaskAnimationManagerTest
Flag: EXEMPT refactor
Bug: 352182359
Change-Id: I76998b2bfa9d76ab3659ddd4d4c42d74872f5b2f
Also unregister it if the feature becomes disabled (currently
this is only done in tests but in the future there will be a
user setting as well).
Added tests to verify getTasks() is not called while both
canShowRunningApps and canShowRecentApps are false.
Bug: 354087794
Test: TaskbarRecentAppsControllerTest
Flag: com.android.launcher3.enable_recents_in_taskbar
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Change-Id: I3123501e7584ad7f877e13294454556501d2dbc8
- The reason Recents is empty after a force-stop is when RecentsTasksList.getTasks is called first time after restart, the result is always invalid but we cached the invalid result with a chagneId(=1). The next time we call getTasks again, we think the cached result is valid, and returend an empty list.
- The fix is to mark such result as invalid to avoid caching the wrong result
Fix: 353926204
Test: RecentTasksListTest
Flag: EXEMPT bugfix
Change-Id: If15ab8fd7454db8a08c22b17eaac73f0c78aa75f
After swiping from a landscape app to portrait home, the touch
orientation may be changed if there the touch event comes in a
short time (e.g. click app icon immediately):
DOWN
MOVE...
SimpleOrientationTouchTransformer#onDisplayInfoChanged
MOVE... (start to transform with inconsistent orientation)
UP
That could disturb the gesture detection:
OverviewInputConsumer#onMotionEvent
> BaseDragLayer#proxyTouchEvent
onInterceptTouchEvent, findControllerToHandleTouch
> PortraitStatesTouchController#onControllerInterceptTouchEvent
> BaseSwipeDetector#onTouchEvent
which may show the app drawer unexpectedly.
http://recall/-/b2qm27pJZxFIWQccA9qE9Q/ggLXlE5kf7AWMOjUc0FCUU
Bug: 351755391
Flag: EXEMPT bugfix
Test: atest NexusLauncherTests: \
com.android.quickstep.OrientationTouchTransformerTest# \
testSimpleOrientationTouchTransformer
Change-Id: Ic0e9d8292606837feb4775663abb60229c90e9c5
Before this CL we would show only one Taskbar icon per app, making it
impossible (through the taskbar) to switch between several windows of
the same app.
With this CL we add one icon per task instead, making it possible to
bring each task to the front individually.
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Bug: 351118893
Bug: 349790805
Bug: 351156858
Test: Started several Chrome windows -> taskbar has one icon per window
Change-Id: Ia692977effceb9ce339906bf6ca24d73e19d8769
- Made TaskThumbnailViewDeprecated nullable in TaskContainer, with non-null getter that requires feature flag to be on/off
- Removed TaskThumbnailViewDeprecated.setTaskOverlay, as it'll now be null with feature flag on
- Removed TaskThumbnailViewDeprecated from DesktopTaskView xml
- Simplifed DesktopTaskView binding logic, to always get thumbnailViews from viewPool, removeView and recycle all thumbnailViews in onRecycle
- Didn't implement view pooling of TaskThumbnailView due to difficulty with TaskContainer not being recycled togetehr with TaskThumbnailView
Bug: 338360089
Test: TaskThumbnailViewModelTest
Test: manual testing for DesktopTaskView for both enable_refactor_task_thumbnail on and off
Flag: com.android.launcher3.enable_refactor_task_thumbnail
Flag: com.android.window.flags.enable_desktop_windowing_mode
Change-Id: I38a6dfc6bc561689578d1660794f91d30bad4a68
- Add GroupTask and DesktopTask equals() (with tests)
- Add tests to verify multiple onRecentTasksChanged
doesn't commitRunningAppsToUI if there's no change
- Add tests to verify commitRunningAppsToUI is still
called if minimized or running apps set changes
Bug: 348802109
Bug: 348787176
Test: TaskbarRecentAppsControllerTest
Test: GroupTaskTest
Test: log TaskbarView#onMeasure() locally, ensure it is called
much less despite noisy onRecentTasksChanged callbacks
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Change-Id: I3efff7f4492272f88aa2bdbd7cc45bd2bf8156f6
