- Updated DesktopVisibilityController to track the numer of visible
freeform windows, and use it to initialize RemoteTargetGluer.
- Updated IDesktopTaskListener to observe visible freeform windows count
- Added resize remoteTargetHandles logic in RemoteTargetGLuer to update
handles size with targets.apps.size on assign.
- This is a workaround and should be removed when RemoteTargetGLuer
intialisation logic is refactored.
Bug: 288121021
Flag: None
Test: Manual
Change-Id: I0297616b4a140fac810c9736bddf6f817d0a98ed
* Previously we defaulted to 2 handles, but we didn't take into
account the posibility of having assistant showing a translucent
task on top of 2 apps. Or other tasks such as Home controls.
* We can scale down the number of handles we have from
initialization (as done in assignTargetsForSplitscreen), but it's
a bit harder to scale up. This is a separate, larger problem in
that the handles are created and needed before onAnimationStart(),
so Launcher doesn't know exactly how many handles are needed to be
created for the recents animation, that's determined by the actual
onAnimationStart() call itself.
* There's a small known bug only in the split case where one of
the tasks shows up over the assistant task, but can live with that
to minimize changes. (peanutbutter@ to clarify?)
Demo: https://drive.google.com/file/d/1hqipfdym_rRXFsAW932es7UdxTx66Zu4/view?usp=drive_link&resourcekey=0-Ri_Kl0xCNN3E81StTh4vxw
As you can see, Assistant translucent overlay seems to work well,
but there are still some glitches with Home controls. Specifically,
there is a flicker, sometimes followed by a black screen, when
returning to the split tasks with Home controls open on top. The
flicker also happens with Assistant, but I haven't seen the black
screen for that case yet. In any case, the crash is avoided, so...
progress? (Also these flickers/black screen happen for Home controls
even without splitscreen).
Original change by peanutbutter@: ag/24830632
Test: Tested assistant result tasks with fullscreen and splitscreen,
and by itself. Seems to animate fine. Also tested with Home controls,
which animates fine and avoids the crash, but still has some issues
when re-opening the tasks as described above.
Flag: NA
Bug: 321328009
Change-Id: I0aa04a6a14cf723b34431855483662039c96e553
- also slightly improve some log messages and simplify some code
Test: presubmit / unit tests
Flag: None
Bug: 294386159
Change-Id: I6f75c0d34bf475d4e20d6250f67a56d5394b9c4e
This will make it easier to test CellLayout, also we should avoid
circular dependencies as much as poisble.
This also allows the CellLayout to be created in other containers
that are not workspace.
Bug: 318417510
Test: creating HotseatReorderUnitTest in follow up cl
Test: TaplReorderWidgets
Test: ReorderAlgorithmUnitTest
Flag: NA
Change-Id: Ic45029a244cb11f8d6775c50b90af9c56f01eaa3
Bug: 230395757
Test: Factory reset in unfolded. Check bar sampling. Fold and swipe up from an app different from system color to overview. Observe the bar color change.
Change-Id: I7d94a3a8f17a40fbabd4d65629846eb12bdbd3d6
* If we start split from allApps or workspace and then go into
workspace, clear all button was previously showing since it's
only hidding via state manager transitions
* Modify the normal Overview LauncherState to provide a split
translation when we are in contextual and have already selected
the first app in split
Fixes: 296006310
Test: Manually started from overview and workspace,
grid tiles look correct, no clear all button
Flags: aconfig com.android.wm.shell.enable_split_contextual
Change-Id: I8630ce7297119392bb0abb07cdb39592eabf129a
Instead of dealing with changing dark theme which can lead to races
with stale Taskbar icons, instead just go home and launch the IME
activity. This is sufficient because the taskbar height changes
when going between home and an app, and the IME will stash the
Taskbar during this transition.
Fixes: 320490387
Test: testThreeButtonsTaskbarBoundsAfterConfigChangeDuringIme
Flag: None
Change-Id: Ib5b1481751af0bf1fccda085c78174f6612441b9
* Currently unarchival tests only pass for Launcher3. We extend the broadcast receiver to AndroidManifest-common to also support NexusLauncher tests.
Test: atest TaplPromiseIconUiTest.java
Bug: 319240622
Flag: ACONFIG com.android.launcher3.enable_support_for_archiving DEVELOPMENT
Change-Id: I9be459a2a0648063d62538eed20c0a6e7644ad44
The issue seems to be that when we begin drag we enter spring loaded mode which triggers the 'app swap' interaction, leading us to getting the wrong position for the app icon we're trying to drag into. Using photos app instead of gmail should make it so that we don't enter the app swap operation with playstore, meaning we would get the correct position for play store and we will drag the app there
Fix: 320484402
Flag: NONE
Test: TaplDragTest#testDragToFolder
Change-Id: Id6f09be997046e7c450a2760ee95cc5735ad5673
Vadim Tryshev
Shamali P
Fengjiang Li
Jagrut Desai
Alex Chau
Helen Cheuk
Ivan Tkachenko
Bill Yi
Android Build Coastguard Worker
Himanshu Gupta
Tracy Zhou
Andy Wickham
Vinit Nayak
Charlie Anderson
Sunny Goyal
Sebastian Franco
Jakob Schneider
Johannes Gallmann
Holly Sun
Tony Wickham
Colin Cross
Rohit Goyal
fbaron
Brandon Dayauon
Uwais Ashraf