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
For each desktop session, Overview shows a single tile with multiple
desktop tasks. With this CL avoid showing minimized tasks in that tile.
Bug: 333013317
Flag: com.android.window.flags.enable_desktop_windowing_mode
Test: manual: ensured minimized desktop tasks are not shown in Overview
Change-Id: I48cb6826849abf225c0fe4448ca7b0b13afea44e
- Re-support GroupTask as a tag on TaskbarView BubbleTextViews
- Can tap to launch (startActivityFromRecents) or drag and drop
- Move divider when enable_recents_in_taskbar is true
Behavior:
- While in Desktop mode, all open tasks show up in TaskbarView,
either in the Hotseat section or the Running apps section
past the divider. Each one also has a running line indicator.
- While in Fullscreen mode, up to 2 Recent apps that are not
part of Hotseat will be added to the right of the divider.
Flag: com.android.launcher3.enable_recents_in_taskbar
Test: TaskbarRecentAppsControllerTest
Bug: 315354060
Change-Id: I2e2870cca434b51f276a701860edb32069109159
- No longer bind All Apps to TaskbarRecentsController, and register
RecentsModel.RecentTasksChangedListener instead
- The source of truth for "running tasks" in Desktop mode is the
DesktopTask#tasks list itself, instead of
RecentsModel.RunningTasksListener (which is no longer used)
- Added TaskInfo.TaskKey#isVisible to distinguish minimized running apps
- Next CL will hook up the UI for Recent/Running tasks that are
not part of the Hotseat.
Flag: com.android.launcher3.enable_recents_in_taskbar
Test: TaskbarRecentAppsControllerTest
Fixes: 335398876
Bug: 315354060
Change-Id: I1313f97a791c5c0c1db7443a5d4f1d5bc761981f
This cl address the problem for standalone picker (follow up to match
ag/27720721) to ensure widgets that aren't in section of their owning
package didn't appear in suggestions
Bug: 345520128
Test: Unit tests
Flag: EXEMPT bugfix
Change-Id: Ia0ef96c5be77db56b84c76ace498125d07f4be42
Currently the recents activity is started by a pending intent created
by launcher. And the sender is system server.
(HIERARCHY_OP_TYPE_PENDING_INTENT in WindowOrganizerController)
If the intent creator doesn't have visible windows, e.g. launcher is
occluded by its another embedded of another package, then the background
launch policy will check whether the intent sender is allowed. But
system server also doesn't have visible windows, which causes
BackgroundActivityStartController#
checkBackgroundActivityStartAllowedBySender to return BalVerdict.BLOCK.
Which will set MOVE_TO_FRONT_AVOID_PI_ONLY_CREATOR_ALLOWS to disallow
moving the target task to front.
See I72a6c22a5fb27aeac52a4e5d46c6a16e28ee6757 for the block policy.
Although currently the recents activity can still move to front because
some places miss to check blocking the launch. Then it is like just
using a security hole.
By adding the background launch permission hint to ActivityOptions,
BackgroundActivityStartController#hasBalPermission will check if the
real caller has permission START_ACTIVITIES_FROM_BACKGROUND. Then
it will pass because the intent sender is system server.
Bug: 341618283
Flag: EXEMPT bugfix
Test: atest NexusLauncherTests: \
com.android.quickstep.TaskAnimationManagerTest
Test: Swipe to minus one screen. Click a news item to Launch chrome.
Swipe from bottom to return to home. There should not have an
error log:
"Without Android 15 BAL hardening this activity would be moved
to the foreground ... only the creator of the PendingIntent
allows BAL. realCallingPackage: android.uid.system:1000 ..."
(from ActivityStarter#logPIOnlyCreatorAllowsBAL)
Change-Id: I19153f6553c09421bca248d4ff9110d168b34f98
Flag: NONE - fixing tests
Test: built and ran locally, verified test pass in presubmit
Bug: 224595066
Change-Id: Ifefab1e1696853c5bd816a361314082073ba8a20
Currently launcher gets task stack updates through WM core. Ideally we
would like to migrate into a model where launcher gets these updates
through shell instead.
Test: Manually check that the correct task info is delivered to launcher
from shell
Bug: 341932484
Bug: 344684650
Flag: NONE Just adding a listener, no logic added
Change-Id: Iaf534a4bfee968138d4a4ff282a66e62759af2c0
This change fixes TAPL tests by:
1. Scrolling down to locate PS, in case the scrollbar moves after lock/unlock.
2. Retrying lock/unlock, as sometimes, the request is cancelled by UserManager (if the profile is already in that state)
Bug: 345556016
Test: atest TaplPrivateSpaceTest
Flag: NONE Tapl fix tweak.
Change-Id: Ic0cc3259a2f92065a699d694c47f65c5f68934b8
As gestures start with checking of canStartTrackpadGesture() method, disabling it there disables all touchpad gestures.
Test: RecentsAnimationDeviceStateTest
Flag: NONE these changes are not directly flagged but usage of SYSUI_STATE_TOUCHPAD_GESTURES_DISABLED state is guarded by flag: com.android.systemui.new_touchpad_gestures_tutorial
Bug: 345207568
Change-Id: I0409475a3e006609c6b722cd3b17d75e1ebed939
- Merged DesktopTaskbarRunningAppsController up into
TaskbarRecentAppsController, which is now initialized directly
- The old TaskbarRecentAppsController was effectively a no-op
that was always overridden, so merging the one subclass up makes
things simpler (especially for the follow up CLs which will add
support for switching between Running and Recent tasks using
the same underlying data).
Flag: com.android.launcher3.enable_recents_in_taskbar
Test: TaskbarRecentAppsControllerTest
Bug: 315354060
Change-Id: I8411fb832e5dd3d76201d2694dec0b11bd70bbf9
Attempts to fix a flaky test by ensuring that recents is always cleared before creating a split pair (so the split pair under test is always the same).
Bug: 340935208
Test: testSaveAppPairMenuItemOrActionExistsOnSplitPair(), testSplitTaskTapBothIconMenus()
Flag: TEST_ONLY
Change-Id: Ibc81b90fac531f0e78e93a494ff59073ab5e52cf
The bugs for fixing the removed tests are obsolete, and it was decided to not allocate resources for fixing the tests.
Bug: 190618549, 190729479
Test: presubmit
Flag: NONE it's a test
Change-Id: I1ca3c2c054e4b598c65c86913f0ddbbc711d7f6c
Additionally, let only prediction system provide suggestions, since the
UI surface has been there for a while, adding locally filtered widgets
from app package isn't required.
Bug: 345520128
Test: Unit tests
Flag: EXEMPT bugfix
Change-Id: Ia97f0743fefeae750e07a694bb19d24a5cc11ffe
The test seemed to be failing due to animation issues
(settings cog and Lock text not visible)- b//339179262
Re-enabling the test as those issues are now fixed.
Bug: 322882655
Test: TaplPrivateSpaceTest
Flag: None TaplTest
Change-Id: I4053b9759cd97c721ea576965f57ef309fffaab3
