Also:
- Give the session an integer ID as the activityToken is not stable over
restarts of the activity
- Verify that session is only accessed by one UID
- stabilize AccessibilityViewIds over activity lifecycle at least for
the IDs we can do that. This required to split the ID namespace in
"per-app" and "per-activity" views. Only the later ones can be
restored.
- Do not end session when app is killed (as it can be restarted)
Bug: 35484143
Fixes: 36392498
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases --test=android.autofillservice.cts.SessionLifecycleTest
cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
Change-Id: I229acc1b3ce35fb57262da7d7466b5d4328b49d4
Fixes 36869204
Test: create another account, enroll a fingerprint in the new account
touch the sensor and make sure the finger you just enrolled gets highlighted
Change-Id: Ib3e8d9ddc987a2c8b7f0878a83f4cbd025e13f7a
Using a feature will allow app developers to find out if a
particular device supports running activities on secondary
screens before using the APIs.
Bug: 36776777
Test: android.server.cts.ActivityManagerDisplayTests
Change-Id: I7121bdb782cac9df70121e9df5cbf3fcb76f4a93
When a 2D app is launched from a VR app, since the VR app was on
DEFAULT_DISPLAY, the 2D app is also moved to DEFAULT_DISPLAY. This needs
to be addressed by moving any non-VR 2D app launch in VR mode to the
virtual display.
Bug: 37111307
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testVrActivityLaunch
Test: #testVrActivityReLaunch
Test: #testPostVrLaunch
Change-Id: I83bffe94bb89415a6b3c026dd7077e70fe36fee0
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
- Adds a workaround to ensure that onStop() is dispatched to the PIP
activities when the PIP is dismissed
- Consolidating dismiss PIP behavior to call moveTaskToFullscreen().
Now we are consistent, and when we expand the PIP, we call
moveTaskToFullscreen(top), and when dismissing the PIP we call
moveTaskToFullscreen(bottom)
- Fixing issue where we were dispatching extra MW/PIP mode changes when
just expanding the PIP
- Fixing typo in last commit where PIP mode change was not getting
scheduled correctly
- Fixing issue where move-to-fullscreen log was sent for each task
Bug: 36567036
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testStopBeforeMultiWindowCallbacksOnDismiss
Change-Id: I303b88d75e9f136da0c238ef5987804e0684c78e
Signed-off-by: Winson Chung <winsonc@google.com>
Previous logic relied on the returnTo type of the task of the activity
we are launching which can get the wrong signal at times because the
original task might have been started from home, but since we are
already in docked mode it shouldn't cause recents activity to be
launched.
We now decide if recents ability should be shown based on if the home
stack is currently visible at the time we started the new activity.
Also, renamed ActivityStack.getStackVisibilityLocked() to
ActivityStack.shouldBeVisible() since it is used to determine if the
stack should be visible and also so it isn't confused with the new
method ActivityStack.isVisible() which returns true if the stack is
currently visible.
Test: manual
Change-Id: I051e72ce93c886d25526af2afef851c95812ab3e
Fixes: 37005549
When the following conditions happen together, another context in
Application stack was launched unexpectedly:
- There is a context of tasks in Application stack, which is launched
from a task on Home stack.
- All tasks/activities in the context are finishing.
Solution:
Add a condition check to see if the task is NOT one of the task
finishing on-top of the top running task.
Bug: 30883775
Test: manual
Author: Ichitaro Kohara <ichitaro.kohara@sonymobile.com>
Change-Id: I5d6097a7c8dc2733ff684957370c987dd158e329
We create a new thread on which everything is running that
directly impacts window animations, i.e. layout, anim tick and
starting window creation. This is such that any work on
android.display can not lead to jank in the window animation,
specifically lock contention on activity manager lock that blocks
callbacks from android.display into AM can not lead to window
animation jank.
Test: Run animation, take systrace, make sure animation is on
android.anim
Test: AppWindowContainerControllerTestTest: AppWindowContainerControllerTestss
Fixes: 36792959
Change-Id: I5d41419a709b7984724e7053a3afdcc1ffe1aaa2
Added ActivityManager#supportsMultiDisplay() to check if system
supports running activities on secondary displays.
Bug: 36776777
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testMultiDisplayDisabled
Change-Id: I18f98f2f6a9e865ad8dc63a470210190536d3271
If thread was boost priority already before boosting we reset it
to default priority after.
Test: Open app, run systrace, make sure priorities are right
Bug: 36631902
Change-Id: I763be06c0dc68db73548b22f96dd07864a6ace1f
We have already removed the non-functional WebView stub, so we can now
remove the logic ensuring that a primary device user could use any
valid WebView package even when a secondary user did not have any
WebView package to choose from (since all device users should always
have a valid package to use as WebView implementation).
Bug: 34730873
Test: run WebViewUpdateServiceTest tests.
Test: Create new user, disable Chrome for that user, ensure WebView
loads for that user and for the primary user.
Change-Id: Ia77cc2efd9e40a157fb5b68a988425ef15508033
Left over from Change-Id Ic75d4f7a8853e6be20e51262c4b59805ec35093a.
Test: no functional changes
Bug: 37084734
Change-Id: Ifb10b4fe146bb6bea6260d8cd723a8e7f5b853a9
android.display being in the foreground cpuset group is an issue. As
seen on M/S, during heavily CPU load it is not given core 3 even though
it might be free and causes jank. This patch adds the thread to the
top-app group to ensure it is placed on all cores during scheduling
decisions.
Doing this required a couple of changes:
- new API to set per-thread cpusets
- changes to DisplayManagerService to set the thread to top-app group
- changes to SystemServer to set the policy toward the end, as doing it
during start of the DisplayManagerService was in issue (issue being
SystemServer calls setSystemProcess.. -> setProcessGroup which overrides
the group settings for threads in the system server process, including
android.display)
Bug: 36631902
Test: Boot and make sure android.display thread is in the top-app group
Change-Id: Icc394ea0ffcf159d11728ad38de114234a29d20f
Signed-off-by: Joel Fernandes <joelaf@google.com>
(cherry picked from commit 474d311cb098e86c078c3f615e1161e2854f1847)
