Fixes to taskbar state when tasks are moved to desktop and fullscreen.
When freeform tasks are visible and we start a new task from taskbar, it
first launches in fullscreen. Transition handler in WMSHell switches it
to freeform as needed. This switch causes launcher activity to be paused
and then resumed. Resuming launcher activity while freeform tasks are
visible, puts the launcher into an incorrect state. (Launcher should
appear paused while freeform tasks are visible).
When a freeform task switches to fullscreen, freeform tasks are no
longer visible. This causes us to resume the launcher activity. We
should not do that if a fullscreen task is visible as it puts the
launcher into an incorrect state. It appears resumed even though the
activity is paused. Added a check to DesktopVisibilityController that
checks if the activity is actually resumed before marking it appear as
resumed.
Test: manual, switch a task to freeform, launch another freeform task
from taskbar, taskbar should continue to be available
Test: manual, switch a task to freeform, switch the task back to
fullscreen, taskbar should continue to be available
Bug: 261234278
Change-Id: Ia8d208619fabfcc9bffff6d8d227b236cb62a00c
mGestureState.getRunningTask() is probably null in this situation, we
need to add a null check here refer to the usage in TaskAnimationManager.
Bug: 263041039
Test: manual
Change-Id: I7707bf204190ff506f40640ff764f07cb98aab68
- Also removed transient_taskbar_two_panels_size and use sw720dp override instead, to be consistent with how we handle small vs large tablet in overview
- Also made isTransientTaskbar mockable so we can test that in DeviceProfileDumpTest
Bug: 260596114
Test: DeviceProfileDumpTest
Change-Id: I3c2236b95d91246e9581531478e3c97601cfb2ec
- Added a cehck on chagnedFlags before skipping stash animation, in additional to !isHotseatIconOnTopWhenAligned check
Fix: 262835548
Test: manual
Change-Id: I5a90213bc0b3f34609a074ba887adbf113e04120
On legacy case, we hide divider bar when gesture start, but this
might cause divider hidden when transient taskbar case.
We should follow the timing it actually start entering overview
then hide divider.
Fix: 261376202
Test: manual
Test: pass existing tests
Change-Id: Iae1339ae0b42033075dd840fc071ba28a7d3e13a
Change margin spaces and logic of how many items the hotseat and taskbar should show.
Fix: 246424857
Test: DeviceProfileDumpTest
Test: HotseatWidthCalculationTest
Change-Id: I8ec71c56a0aa362483c43d6400c762d12cf45f5b
Fix: 235358918
Test: Manual
1. Rebooted the device and verified that widgets are still updating properly
2. Changed the theme from dark to daylight, then from daylight back to dark and verified that widgets are working
3. Kept the device on for several days and verified that widgets are still updating
4. Turn on auto-rotate for the launcher, open any app then exit, verified that widgets will not vanish and reappear
5. Add & remove widgets from the screen, added widgets are still updating
Change-Id: I98ee902f7d16b47bd77626201a4fefc897ba17a0
When "Don't keep activities" is enabled in developer settings, the RecentsView gets re-initialized every home gesture. The home animation can often finish before the load plan ever gets applied, so the page scrolls can be used before the RecentsView has had a chance to add all its TaskViews and recalculate its page scroll.
Fixes: 249020573
Test: launched an app and went home
Change-Id: I83ca9de60b50693f7a22b08534ec36973cd6a0fc
- ITYPE_BOTTOM_MANDATORY_GESTURES should always be > 0 in gesture
navigation mode, but before we were setting it equal to tappableHeight
which is 0 if the taskbar is stashed. Fixed it to be contentHeight
instead.
- Updated VIS insets to only override them to be 0 for tappableElement,
not for others like navigationBars. We still only override this for
gesture navigation; 3 button mode will continue reporting the same as
we report to the underlying apps.
Test: manually with 3 button mode, gesture nav mode with taskbar
stashed/unstashed; checked that TaskbarInsetsController dump looks as
expected, and that behaviors like Assistant and IME look correct
Flag: none
Fixes: 262516176
Change-Id: I5a1cdf5a9956777d3189ef6042493e2f5aa9b162
Fix: 254191175
Test: With 3 button, rotate at home and overview, nav button are at expected position. Repeat with TASKBAR_IN_OVERVIEW flag off.
Change-Id: I1e629e6be92c4793d3dfdb0dac60c3bfce886e7a
- After ag/20691430, iconScale no longer scale app icons (I should rename it later, after QPR2), so we'll need to set the desired iconSize directly for Taskbar's DeviceProfile
- Extracted setting iconSizePx and testSizePx out of updateIconSize, as they are no longer affected by scaling. This allows TaskbarActivityContext to set desired iconsize and then call updateIconSize
Bug: 256976071
Test: Test Taskbar icon size in different density
Change-Id: I741c178b59e0d8ecb4c63689e68767622329379c
This patch makes it so that the correct animation will play when the user selects a second app from the Taskbar.
Previously, when the user selected a second app from the Taskbar, an animation would play showing the expansion of the app -- but it would come from the wrong place. The error occurred because when we calculate the animation start position, we assume that the starting view is located in the DragLayer, which fills the whole screen. But in cases where the starting view is located in the Taskbar, the root view is actually the TaskbarDragLayer, which only fills an area on the bottom part of the screen.
Fixed by adding a check to see if the starting view is part of the TaskbarActivityContext, and if so, adding an offset to calculate the correct DragLayer coordinates.
Fixes: 258692761
Test: Manual
Change-Id: I4026676fefe1e4c5cdf9d9a47d95c0d6e64672e8
Alex Chau
Ats Jenk
Brandon Dayauon
Shen Lin
Sihua Ma
Luca Zuccarini
Tony Huang
Brian Isganitis
Thales Lima
Jeremy Sim
Schneider Victor-tulias
Sunny Goyal
Tony Wickham
Jon Miranda