The background in DesktopTaskView wasn't added for accessibility, so it couldn't be retrieved from the view hierarchy during e2e tests. This view is necessary to calculate the correct size of the DesktopTaskView.
The changes in this cl:
- Add backgroundView to DesktopTaskView's children for accessibility
- Use the correct snapshot resource for desktop mode in OverviewTask
Bug: 353948500
Change-Id: I83746510849e4013d623d49cbaccebd81daba96d
Flag: EXEMPT bugfix
Test: TaplTestsOverviewDesktop
This CL adds 2 new E2E Tapl tests for checking dismiss DesktopTaskView.
- dismissFocusedTask_thenDesktopIsCentered validates the following scenarios:
- Scenario: When Focused Task is in the center of the screen, with 1 other task in the grid and 1 desktop task.
- When focused task is dismissed, the next task in the grid takes its place to be the next focused task at the center of the screen.
- When the last focused task is dismissed, the desktop task takes its place at the center of the screen.
- dismissDesktopTask_thenFocusedTaskIsCentred validates the following scenarios:
- Scenario: When Desktop Task is in the center of the screen, with 1 focused task and 1 task in the grid.
- When focused task is dismissed, the next task in the grid takes its place, adjacent to desktop task.
- When desktop task is dismissed, the focused task takes its place at the center of the screen.
Fix: 353948500
Flag: com.android.launcher3.enable_large_desktop_windowing_tile
Test: TaplTestsOverviewDesktop
Change-Id: Ie2aa28cd2b30a2bf10e877721416399bcf47acf6
Use a ViewPool for DesktopTaskView for same reason.
Fix: 369590189
Flag: com.android.launcher3.enable_refactor_task_thumbnail
Test: Manually looking at slow-mo videos of home to overview
Change-Id: I0335e4d0eea4841145815244bbbec19541f31c73
Expand the bubble bar when the user taps on the flyout view.
Flag: com.android.wm.shell.enable_bubble_bar
Bug: 277815200
Test: atest BubbleBarViewAnimatorTest
Test: atest BubbleBarFlyoutControllerTest
Change-Id: I156acfa663d6a00bc70dd7bbfc35642643902d83
Added a method to the device profile to calculate the vertical center of
the hotseat icons. Simplified the logic for positioning the bubble bar.
Test: TransientBubbleStashControllerTest
Test: PersistentBubbleStashControllerTest
Test: Visual. Go to home page, check that bubble bar is vertically
center aligned with the hotseat
Bug: 345491493
Flag: com.android.wm.shell.enable_bubble_bar
Change-Id: I52f1b94de79f6c912f43a88fcc5c884e20e56310
If a user pins the taskbar and immediately swipes to home, this would
show the taskbar edu tooltip on the home screen. This change checks that
taskbar isn't transitioning to home to prevent that scenario.
Fix: 369061563
Test: Reset Search Taskbar edu, pin taskbar, then swipe to home
immediately. Ensure that the edu doesn't show up on home
Flag: EXEMPT bugfix
Change-Id: I9948189df880b3ed318c4952a8f715cf9a7fa708
Forgot to do a git add :)
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Bug: 356394053
Test: go/testedequals
Change-Id: I42f85f5850152f498db8a399835b19a5e493c68d
Creates a new view for the taskbar overflow button that draws up to 4
recent item previews. The items are stacked on top of each other in
counter clockwise order, with overlapping bounds, recent items closer
to the top. The item icons have a 2 dip ring around them, of the taskbar
background color.
Adjusts logic to calculate which items become part of the overflow
button, so more recent items get shown in the taskbar.
Initial consideration was to usse FolderIcon to represent the overflow
button, but decided against it because:
* FolderIcon is fairly entangled with the associated folder view
* item information uses different data structure (ItemInfo) than
recent items (GroupTasks)
* item preview layout within the main icon is similar, but
sufficiently different that using clipped folder layout rules felt
like hacking around assumptions made for folder icon UI
Bug: 368119679
Test: Keep opening apps until the task bar enters overflow - verify that
overview button shows up, and contains least recent task
representations. Keep adding items, then closing windows, and verify
the icon gets updated accordingly. Done in landscape and portrait, and
ltr and rtl layout.
Flag: com.android.launcher3.taskbar_overflow
Change-Id: I2824cb0db1f7516ebd74361ce00fb8887857325d
Bug: 368119679
Test: open KQS via taskbar and observe the bounds change
Flag: com.android.launcher3.taskbar_overflow
Change-Id: I5060a339cf0cdf70a2a11b57a325767405772ef8
Removed calls that were stashing and unstashing the hotseat bar.
Flag: com.android.wm.shell.enable_bubble_bar
Test: Manual. Be on Launcher home, have some bubbles. Expand / collapse
bubble bar. Hotseat remains behind the scream view.
Fixes: 373429249
Change-Id: I1a9ba39c8ca11d49340f217f095d5e872b06105b
Continued quick switch couldn't work using existing infrastructure until RecentsWindowManager could be properly tracked by ActivityTracker. Refactored ActivityTracker into ContextTracker to support this.
Also refactored ActivityInitListener into ContextInitListener to fit the updated pattern.
Flag: com.android.launcher3.enable_fallback_overview_in_window
Fixes: 366023051
Test: RecentsWindowSwipeHandlerTestCase; Attempted continued quick switch from home and launched app
Change-Id: Ic38ebf3611ef22fbfd1ddeb79d72d8a3621940a0
Fixes the condition that defines which task should be the focused task when grid-only is enabled and desktop windowing is the running task.
In some cases, when the user adds or removes a task from Desktop Window, the DesktopTaskView does not get updated with the new list of tasks. This causes a mismatch of tasks that are inside the DesktopTaskView and the actual Desktop Windowing. So, RecentsView can't match the previous DesktopTaskView with the current running tasks, entering a specific condition to update the runningTaskViewId. The method called in this condition (showCurrentTask) also updates the focusedTaskViewId for some situations. This CL fixes the conditions which focusedTaskViewId is set to prevent it to replace the focused task id when it's not needed.
Fix: 370736395
Flag: com.android.launcher3.enable_large_desktop_windowing_tile
Test: Manual
Change-Id: I25f5bd67ee0486f6754673eec404832779fc0498
* changes:
Set task properties to prevent the task being null. This behaviour is expected by existing callers and was likely broken by ag/28151977
TaskRepository performance improvement
When laying out its contents, TaskBarView generally lays the icons so
they get centered in the task bar - this is done by calculating the
total size of all icons during layout (this will generally be transient
taskbar icon sizes), and substracting extra margins that get removed
from the divider view. After initial layout, `TaskbarViewController`
adjusts the icon view positions to match expected icon sizes (it
offsets icons horizontally reducing margins between icons to match
intended icon sizes for the taskbar type). Additionally,
`TaskbarViewController` translates all apps button container - this
transformation is asymetric, and causes the task bar contents to become
off-center. To account for this, update taskbar layout to reduce the
total icon size used for centering icons by the amount all apps button
is offset. This makes the taskbar off-center after initial layout, but
by the amount by which all apps button is eventually offset (resulting
in centered taskbar content).
This alone worked for left-to-right UI direction, but not right-to-left.
To fix this, correct the reference point from which
TaskBarViewController offsets icon positions. The offset used to be
calculated by distance of an icon index from half of the icon count -
instead offset needs to be calculated relative to mid-index.
For example, icon at index i needs to be offset by
(mid_index - i) * difference_in_icon_size: ((n-1) / 2 - i) * diff).
Code used to work for LTR UI layout because the list of icons contained
invisible qsb view, which incresed both n and indices by 1, so
(n' / 2 - i') * diff_in_icon_size worked fine, as it evaluated to
((n + 1) / 2 - i - 1) * diff = ((n - 1) / - i) * diff
Bug: 372567501
Test: Verify that taskbar icons are centered when it needs to be, both
with ltr and rtl language UI.
Flag: EXEMPT bugfix
Change-Id: Ic06873cc225a4361d9140d72c055db23f446a1ad
Does not implement any animations.
Flag: com.android.window.flags.enable_desktop_windowing_taskbar_running_apps
Fix: 356394053
Test: go/testedequals
Change-Id: If8e319b605beedd0e9b14dc37da1b5ffa12f3c9f
This CL improves Overview's performance by preventing multiple thumbnail and icon fetches for visible tasks. It introduces manual cancellation and removal of tasks that are no longer visible to prevent fetching and listening to changes in such tasks.
- Renamed 'augmentedTasks' to 'tasks' and updated it to be a MutableStateFlow with a map of Task Id and Task.
- When a new task becomes visible, the task is added to a list of requests along with a Job that fetches the Thumbnail and Icon. Additionally, 'taskVisualChangesDelegated' is added and removed for that task per request.
- When a task becomes invisible, the Job is canceled to prevent fetching the Thumbnail and Icon. The thumbnail and icon are cleared from the list of tasks, and the listener from 'taskVisualChangesDelegated' is unregistered.
- The list of tasks is updated when the list of visible tasks changes and a new thumbnail or icon is updated. This list is also updated when a force fresh from getAllTaskData is requested.
Fix: 373361888
Flag: com.android.launcher3.enable_refactor_task_thumbnail
Test: TasksRepositoryTest
Change-Id: Ifd9c54fdfcb85463c043c121fb829dec3e9faedc
When opening 5 instances of Chrome in Desktop Windowing, navigating back to Overview and trying to split a new Chrome instance from the Taskbar resulted in a crash.
This happened because SplitSelectStateController searches for the last active task of the app chosen to be in split. Then, it returns its taskId that is used in RecentsView to find the TaskView to be animated to split.
However, after the 5th Chrome instance in opened in Desktop Windowing, the last active taskId is no longer visible in Overview or Desktop Windowing. Then, RecentsView won't find any TaskView with that taskId and mSplitHiddenTaskView will be null. This will result in a crash because we have some if-else conditions assuming that is not null because of mSplitSelectStateController has a task to be dismissed during the split animation.
More info in the bug report.
Bug: 372400577
Flag: EXEMPT bugfix
Test: Manual. Steps in the bug report.
Test: Manual. Open 5 windows of Chrome in Desktop Windowing. Go Home. Open a Fullscreen App. Go Overview. Split a new Chrome instance from the Taskbar.
Change-Id: I0f3757e898b606b4e0a180f43c73f1e2d887e996
Jordan Silva
Uwais Ashraf
Treehugger Robot
Mykola Podolian
Brandon Dayauon
Saumya Prakash
Wen-chien Wang
Liran Binyamin
Sihua Ma
Brian Isganitis
Toni Barzic
Bill Yi
Schneider Victor-Tulias
Artsiom Mitrokhin
Sunny Goyal
Orhan Uysal
Alex Chau