Recent changes passed down the nullable array to a method where it
was not being properly checked.
Change-Id: Ibf940f9225e4c9901869188aa55a04d0908015c3
Fixes: 37197666
Test: manual via bug repro steps.
Callers of addNetworkPolicy() were not taking locks in the correct order
inside NetworkPolicyManagerService:
- addNetworkPolicy() is an internal method that calls
setNetworkPolicies which takes both mUidRulesFirstLock and
mNetworkPoliciesSecondLock in order.
- both callers of addNetworkPolicy, mWifiStateReceiver and
mConnReceiver via ensureActiveMobilePolicy, were taking
mNetworkPoliciesSecondLock before calling addNetworkPolicy.
- this causes the order of locking to be reversed, which can cause a
deadlock when another concurrent codepath in
NetworkPolicyManagerService tries to take both locks in the correct
order.
This patch fixes this issue by wrapping both problematic codepaths into
addNetworkPolicy() with a lock on mUidRulesFirstLock.
Test: build, flashed, NetworkPolicyManagerServiceTest passes
Bug: 36972283
Change-Id: If7888c11aef8b628e1b013224075c4c75eae0022
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
1. ActivityConfigCallback might not have been registered
because DecorView was not yet attached to window and ViewRootImpl
was not available. In this CL the callback is set as soon as a
DecorView is attached to window.
2. When private display was removed from system, its stacks were
moved to bottom in AM but moved to top in WM.
3. When reparenting stack visibility of activities should be updated
before reparenting in WM, because otherwise WM will be resizing
windows that should no longer visible and reporting it to clients.
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Test: #testContentDestroyOnDisplayRemoved
Change-Id: I6ccc27d873d0d60d7650659fb25cbfcaaeb0fd07
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)
for callers with READ_CONTACTS permission.
Test: manual
Bug: 36983643
Change-Id: I1239a30a71cb13ce9ffff6f38b8506e9686abe4d
(cherry picked from commit d7e7a74179c51a36845c35614ac3247c13474fca)
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
