- Speculative fix for mismatch between navigation mode reported to the
tests vs. what mode the device is in based on the bug report. Original
change to the package name was in ag/6866716
Bug: 136033787
Change-Id: I51f964daa8c42b671733cf3fab19d086e19a9063
Instead of individually removing tasks,
ask for all tasks to get accurate list.
This method is invoked whenever user presses
back on a root activity, which causes the task to
be killed from perspective of the activity.
Test: Visually inspected, recent task no longer
disappears.
Open any app, hit back, and then go to overview quickly.
App should remain in recents list.
Fixes: 135687618
Change-Id: I1c135673ae987016db5df0b83f5ea8e345d3c7c1
(cherry picked from commit 8651219f7e)
During first boot, home activity after FallbackHome may be an
one-time setup. If the overview is preloaded at this moment,
system won't resume the real home after the one-time setup is
finished because the activity stack is not empty.
Since the navigation mode doesn't support gesture during the
first time setup, and in order to keep the ability to preload
launcher if it is also the overview, these conditions are
combined to guard the case of first boot.
Fix: 137281732
Test: Build sdk_gphone_x86-userdebug.
Run "emulator -wipe-data" and check the
recents activity won't start during booting.
Change-Id: I4b20f61f4a412371c19b379410c8a0a188e41276
Now we use the velocity towards the middle of the screen
(e.g. x when in landscape) instead of always using y.
Test: testBackground with @PortraitLandscape
Bug: 135567630
Change-Id: I77ab6bdf0d556475a6c182ae91914a718a81e1c4
- When the user dismisses splitscreen while launcher is hidden and was
previously minimized, getLocationOnScreen() will continue to return
the old position until the first view root traversal after the window
is shown. As a result, we will end up with home bounds for the minimized
state and the wrong target bounds calculated
Bug: 135952890
Test: Enter splitscreen, launcher another app, dismiss splitscreen and then
swipe up
Change-Id: Id19dfa664623b2b855db4209999508c76a9aacdc
This would fix the issue that when drag and drop an icon from the all apps
page, it doesn't have the right container information logged.
Logging after this fix:
07-11 10:57:04.392 12969 12969 D UserEvent: action:DRAGDROP
07-11 10:57:04.392 12969 12969 D UserEvent: Source child:APP_ICON parent:ALLAPPS
07-11 10:57:04.392 12969 12969 D UserEvent: Destination child:APP_ICON parent:WORKSPACE id=0
07-11 10:57:04.392 12969 12969 D UserEvent: Elapsed container 744 ms, session 17440 ms, action 739 ms
Test: manual
Bug: 111935715
Change-Id: Ifb078e57697b051e3a527c16abaad40663eae687
using a different handler
This will allow us to use common logic for handling horizontal swipe
Bug: 137197916
Change-Id: I6f9cba6e8728dd0669482906c4bf34270af2bc82
On swipe up, we start a rencets transition to the current launcher app. At the
end of the transition, if the user is going to recents, we start overview activity.
Bug: 137197916
Change-Id: Ie5ed848879ad965dcab2780a05d649e3be066568