diff options
| author | Chilun <chilunhuang@google.com> | 2019-03-13 17:14:36 +0800 |
|---|---|---|
| committer | Chilun Huang <chilunhuang@google.com> | 2019-03-15 13:10:03 +0000 |
| commit | 8b1f1be2007ff01d3e7684048b12b889092c6aa5 (patch) | |
| tree | 68a48c963f9fb6de3c81f34e941953cb26880c04 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | a3e9de112196e86bbafd36d70983fa7981f39295 (diff) | |
Use the same logic to launch home activity
The original logic of startDockOrHome is using the intent with
CATEGORY_HOME to find the home activity, which is not guarantee to
support secondary display. That may cause no response when tap the home
key on secondary display.
RootActivityContainer#startHomeOnDisplay already has a complete flow to
find the proper secondary launcher for secondary display.
So, let's expose startHomeOnDisplay through ActivityTaskManagerInternal
and let PhoneWindowManager can use the same logic to launch home activity.
One more change is to be consistent with InputDispatcher to fallback to top
focused display if the specific display id is invalid.
Bug: 127348870
Test: atest ActivityManagerMultiDisplayTests
Test: atest ActivityManagerActivityVisibilityTests
Test: atest ActivityManagerSplitScreenTests#testMinimizeAndUnminimizeThenGoingHome
Test: atest ActivityMetricsLoggerTests#testAppHotLaunchSetsWaitResultDelayData
Change-Id: Iebef462f244ef2457a2e7c9ad0a706aebe291fe8
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions