This gives semantics similar to the start command
queue of services.
The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.
This includes a first step of adjusting/fixing locking
within JobSchedulerService. The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler. However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.
The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL). Right now we have
the locking, but still also the handler. But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.
Test: new tests added
Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
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.
The BoringLayout measurements for auto-size are
incorrect. Removed those and kept the StaticLayout
measurements.
Bug: 36940118
Test: cts-tradefed run cts-dev -m CtsWidgetTestCases -t\
android.widget.cts.TextViewTest
Change-Id: I772ade08ed26efac05ca56cb7df8cfec0327633b
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
WebView safebrowsing can be opted in using a manifest value. However,
we also need to control individual WebViews.
Bug:37158813
Test: See change I71e813bccc2fab73d100384661128c7311dd396c
Change-Id: I647dc304787d6406691b5cbadf1c9a4f13ac5604
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
Only for these two configurations since selinux permissions only
allow system_server to access profiles in these cases.
Motivation is to allow collecting profiles for improving RAM and
performance for preopt.
Setting the property dalvik.vm.profilesystemserver to true is required
to enable the collection of profiles for system server.
Test: device boots
Bug: 34927277
Bug: 36457259
Change-Id: Icbba6dafe376fd9c6c3d0c7feba7f64009f7c2c3
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
