Test: Built and tested locally
Flag: com.android.launcher3.enable_fallback_overview_in_window
Bug:292269949
Change-Id: Ic70d9a3e65ffb86e369f52982891b94bef4cacd7
Test: Built and tested locally
Flag: com.android.launcher3.enable_fallback_overview_in_window
Bug:292269949
Change-Id: I5352ba0b6c5bc196fbd1322d435a7e27e884f7b5
Missed annotating the SettingsChangeLogger as singleton in ag/29424931.
Tested with commands
> m statsd_testdrive
> $ANDROID_HOST_OUT/bin/statsd_testdrive -terse 10108
Verified logSnapshot is called on same instance of SettingsChangeLogger.
Bug: 361850561
Test: Manual
Flag: NONE Dagger Integration
Change-Id: Icdbe57623bb0ce1a2ef55cdab238e1f9bfbedf40
This CL forcefully resets taskbarModePreference on tearDown() to ensure
the following tests are not affected by the changes made by
`testTaskbarPinningChangeInLockedTaskbarChange`.
Bug: 368322666
Flag: EXEMPT bug fix
Test: nexus_unit_test_multi_device_platform
Change-Id: I8bd8e8ca8b4b832ed17e86fbdfc9bda7bf9ab16e
See
https://docs.google.com/drawings/d/1JHFi_nhmQt2xPT1N3FB_1mnaRK5TVqKZ9-fSl3EA7sU/edit?usp=sharing
and
https://docs.google.com/drawings/d/1bx4WURP4uHZGzZ1bWQgpw701jkTkVqlNfA02Yt-ZtSI/edit?usp=sharing&resourcekey=0-oySjsnaCsOSrNIPqqEa0gw
for design details.
We need to make SandboxContext extend LauncherApplication because we
want create MainThreadInitializedObjects in SandboxContext's
AppComponent scope. Since MainThreadInitiliazedObjects are closed in
SandboxContext's OnDestroy() , we need to replicate same thing using
dagger as well.
- DaggerSingletonObject is same as MainThreadInitializedObject but is
used for fetching the dagger created singletons so that we can avoid
major refactors for accessing singletons. This will be deleted soon.
- DaggerSingletonTracker to track dagger created singletons and call
close() on those singleton objects created in SandboxContext scope.
- Annotate the singleton object SettingsChangeLogger constructor with @Inject and execute the statements in Main thread.
- Added createSandboxContextForTest(only for Test) to avoid creation of
dagger component in test. As follow up, I will delete this method and
introduce fakeDaggerComponents in test.
Bug: 361850561
Test: Manual
Flag: NONE Dagger Integration
Change-Id: I2d3762ea64e53baa4de190790568aec750b54201
- waitForToggleCommandComplete was a legacy logic to rate limit OverviewCommandHelper to avoid too many TOGGLE commands simulataneously
- As OverviewCommandHelper iterates, commands are now executed one by one and waitForToggleCommandComplete is no longer useful
- waitForToggleCommandComplete also caused a bug that when OverviewCommandHelper times out, we cancel the command completely, which causes waitForToggleCommandComplete to remain true, as a result all subsequent TOGGLE commands will be ignored
Fix: 368328461
Test: Aggressively keep tapping recents button, it should never get stuck
Test: 3 button Overview tests in presbumit
Flag: EXEMPT BUG_FIX
Change-Id: Ia9b64057ffb8ade6b964eb7f52c2fe72b9e7f77b
Previous sequence of events when swiping home:
- AbsSwipeUpHandler getParallelAnimationToLauncher() ->
TaskbarLauncherStateController#createAnimToLauncher(NORMAL, ...)
(but mLauncherState is still BACKGROUND_APP, so we don't play the
icon alignment anim here)
- AbsSwipeUpHandler#createWindowAnimationToHome ->
LauncherHomeAnimationFactory#createActivityAnimationToHome() sets the
state to NORMAL.
- TaskbarLauncherStateController now animates the icon alignment in
response to the state change, but it's a separate animation from the
one created in createAnimToLauncher()
- If you touch down during the transition to home, we finish the
animation that was returned by createAnimToLauncher(), but that
doesn't include iconAlignment so that part still plays on top
To fix this, we set mLauncherState = toState in createAnimToLauncher so
that the applyState picks it up and does the iconAlignment as part of
that animation.
Test: manual: swipe to home and immediately swipe up to All Apps (or
down for notifications or right for -1), verify no Taskbar on top
Flag: EXEMPT bugfix
Fixes: 360116367
Change-Id: Icd9e4659812c9d77598b9214f51592ce2136b265
Once taskbar is unstashed, the user cannot return back to the overlay. We can
clear it here to set the expected state once the user goes home.
Fixes: 359096594
Test: open -1, launch app, go home
Flag: EXEMPT bugfix
Change-Id: I8059c2c45f10d15701ff2961480aef002d273a06
This CL allows freeform-first devices to lock the taskbar in a pinned
state when Launcher is visible.
Bug: 361419732
Flag: com.android.window.flags.enter_desktop_by_default_on_freeform_displays
Test: DisplayControllerTest
Test: manual
Change-Id: Ic0d2740e33fee19c676d88aa2bcf370eb64366e8
When navigation mode is set to 3 buttons, it is possible for user to
click on recent apps button, so for such scenario taskbar should be
immediately un-stashed
Test: Manual
Set 3 buttons navigation mode. Go to Launcher home. Expand bubble bar.
Press recent apps button. Press the home button. Observe hotseat is
visible. Video:
http://recall/-/gx8ASgewUeUS3QYohfrd1J/fX0gSp18Riw8mYYAw0wj8W
Bug: 367488218
Flag: com.android.wm.shell.enable_bubble_bar
Change-Id: Id65fd9add720125a340294311d470f2be50d43f8
This reverts commit d511538361.
Reason for revert: Droidmonitor created revert due to b/367736714. Will be verifying through ABTD before submission.
Change-Id: I01281bd48c4ba7d07dc0308c504f21aad751ea44
