Previously we used 0 for the id of the "Always-on VPN disconnected"
notification, as did many other system services. In a recent CL, an
effort was made to assign a dedicated id to each of these system
notifications. Unfortunately, this CL only changed the id in the call to
NotificationManager#notify(), but not NotificationManager#cancel(). This
causes the notification to persist even when always-on VPN is turned off
by the user.
This CL changes the id in the cancel() call, thus fixing the issue.
Bug: 37175930
Test: manually enable and disable always-on and observe the notification
Change-Id: I39c7325c78479afe3dc9e1764d54406bd721b067
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
Bug: 30932767
Test: ensure getAssociations works as before
Change-Id: I58dc4dac5bf7aae83fe3611890116a928e290a43
(cherry picked from commit 544d714626db38714f826a31a5483c647510a743)
If any(Bundle.class) is used in the mock's when() clause instead of
nullable(Bundle.class), the mock is not called when the bundle argument
is null.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest
frameworks-services
Bug: 36808416
Change-Id: Iab96fe88837e8f27a1da5775494b4611a547f13a
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
