NetworkStatsService is using INetworkManagementService APIs, which
cannot be accessed after moving into the mainline module. So, replace
and remove those hidden API usages.
Bug: 209738761
Test: atest NetworkStatsServiceTest
Change-Id: I5740f6d8a54e9a06c6dbb93203cb4c954383c3c8
Design doc is at go/statsd-bootstrap-logging. Creates a proxy service for
logging atoms from bootstrap processes to statsd. Service has one API,
which converts StatsBootstrapAtom into StatsEvent and logs to statsd.
This should only used by processes that start in the bootstrap namespace
and cannot directly link statsd's libraries to log to statsd.
Bug: 204889815
Test: booted, made sure binder service was published.
Change-Id: I09709a30a42a7a398234c995324f62a0d62ad24f
Create a skeleton system service which will be used to run Isolated
Compilation using a system server classpath fragment in the CompOS
APEX.
This has no effect if the CompOS APEX is not present (i.e. isolated
compilation is not enabled).
Bug: 199147668
Test: starts up with CompOS present & not
Change-Id: I5ee853cfaf4d9633dd8db348d13e0dfe00bd4dca
Bluetooth can no longer call SystemConfig and need to use the manager.
Bug: 190440540
Bug: 199279027
Test: Manual
Tag: #refactor
Change-Id: I065ab407c83cd2edf2244e4170496b0979ac562c
Starting the service asynchronously is resulting in a
race condition when accessing a shared data structure.
We could add a lock to guard this data structure but
this is resulting in a slightly worse performance than
starting the service synchronously.
Bug: 194428627
Bug: 179687249
Test: treehugger verification
Change-Id: Ib4d610e8a221f94a3dcc8475371b4a05e5582149
Merged-In: Ib4d610e8a221f94a3dcc8475371b4a05e5582149
(cherry picked from commit 9df4ac6093)
Lone calls to System.gc() generally don't do anything.
Runtime.getRuntime().gc() would force a GC, but it would be ineffective
without waiting for reference processing and finalization to complete.
Adding the runFinalization() call implicitly makes the preceding GC call
effective.
Bug: 183912710
Test: Treehugger
Change-Id: I0f4806b8e3f9ca898eb7ea1b1c8de14aa94e2646
Lone calls to System.gc() generally don't do anything.
Runtime.getRuntime().gc() would force a GC, but it would be ineffective
without waiting for reference processing and finalization to complete.
Adding the runFinalization() call implicitly makes the preceding GC call
effective.
Bug: 183912710
Test: Treehugger
Change-Id: I0f4806b8e3f9ca898eb7ea1b1c8de14aa94e2646
Merged-In: I0f4806b8e3f9ca898eb7ea1b1c8de14aa94e2646
This is in preparation for adding some system_server-only, non-binder
APIs, which mean we need to keep a handle to the actual class and not
just the binder interface.
Bug: 175793106
Test: boots, sensors work
Change-Id: I83dcaee53ac52e95aa238a8fa9b875caeeddc725
This CL establishes a single flow of registration for both HIDL and
AIDL HALs. The registration of both is done on a separate thread to
avoid blocking system server. Previously, only AIDL registration was
done on a separate thread.
Bug: 184677066
Test: atest CtsBiometricsTestCases
Test: atest AuthServiceTest
Test: atest Fingerprint21Test
Test: atest Face10Test
Change-Id: I4442db15a7b690bb34c6eb7e8793ab4411cbd6d2
Only a couple distinguished packages will need to hold these
permissions. We can grant via role for these cases.
Previously system ui was started assuming the system server was
initialized enough but the problem was that the role service may not
have finished granting all permissions. If we start sys ui after system
services have finished onUserStarting then we can _probably_ safely
assume the state of user 0 is initiallized.
Test: Wipe & reboot; dumpsys package com.android.systemui
Test: atest SystemUiTests
Bug: 184303952
Change-Id: I160ac8e0f2fbc36a76e8f2ee99d73e613ddc3c11
This thin AOSP service layer will trampoline all API calls to the vendor
UWB service.
In follow up CL's,
i. The AOSP service will perform all the permission checks
necessary for this API surface before forwarding the call to the vendor
UWB service.
ii. Similarly, it will perform necessary permission checks +
noteOp before forwarding the ranging callbacks from the vendor service
back to the apps.
Bug: 183904955
Test: atest android.uwb.cts.UwbManagerTest
Test: atest com.android.server.uwb
Change-Id: I2b367d1b6accc2f4e075cacb5c8e3c51f1faf5db
Currently, the Translation uses feature to determine if we need to
start the translation system service. But our case is like the
content capture not the autofill, the autofill can have the feature
without any service defined and the user can install one later. But
translation isn't, we should need to check config instead of
feature.
The feature will not be used anymore, it's safe to delete it. If we
leave the removal to next OS, it is painful to delete it.
Bug: 183360041
Test: atest CtsTranslationTestCases
Change-Id: Ib6886a17965937abf064e526c36c67428af7398f
Serve memtrackproxy service from system server.
This service enforces access control on requests for memory usage stats
to the memtrack HAL based on the call context's PID and UID.
Bug: 177664629
Test: memtrackproxy_test
Change-Id: I10829ffcf4e5b2813d4c622268b0b59da6f171b6
Merged-In: I10829ffcf4e5b2813d4c622268b0b59da6f171b6
Serve memtrackproxy service from system server.
This service enforces access control on requests for memory usage stats
to the memtrack HAL based on the call context's PID and UID.
Bug: 177664629
Test: memtrackproxy_test
Change-Id: I10829ffcf4e5b2813d4c622268b0b59da6f171b6
The activity recognition source may access activity
recognition in its operation as being the activity
recognition source. Accesses from an AR source
(for special tags it designates - the APK may contain
other components) for location and AR are tracked in
a dedicated app op.
bug: 182204957
Test: atest CtsActivityRecognitionTestCases
Change-Id: If29fba1c51d70a2806a0907a73a96d3d8d7a3100
This CL causes the System Server to create and load the ART Local
Manager.
Test: Build and flash
Bug: 177273468
Merged-In: I9734160f1cd4fd9fc363b3af50e27ec8973be557
Change-Id: I9734160f1cd4fd9fc363b3af50e27ec8973be557
This CL causes the System Server to create and load the ART Local
Manager.
Test: Build and flash
Bug: 177273468
Merged-In: I9734160f1cd4fd9fc363b3af50e27ec8973be557
Change-Id: I9734160f1cd4fd9fc363b3af50e27ec8973be557
PacProxyInstaller class is running a thread all the time and is
listening to intent ACTION_PAC_REFRESH so it would be better to
make it be a system service with a manager class PacProxyManager
which is obtained with getSystemService(PacProxyManager.class).
Besides, rename PacProxyInstaller to PacProxyService will
be easier to know it's the service for PacProxyManager.
ConnectivityService is going to be a mainline module and it
needs constructor of PacProxyService to be SystemApi.
However, in current design, it needs to pass a handler and
an int arguments to the constructor which would be difficult
to maintain if just expose the constructor directly.
So, define a listener for the event that the current PAC
proxy has been installed so that the handler and the int
arguments can be removed from the constructor.
Bug: 177035719
Test: FrameworksNetTests
Change-Id: I2abff75ec59a17628ef006aad348c53fadbed076
The platform has the concept of a location provider which could
be a plugin implemented by another package. The implementation
of a location provider plugin can make calls to APIs that require
a location permission, e.g. fusing data from different sources.
However, such accesses are counted in app ops as a location access
but the accessor is in this case the data source. It is also
possible that the package that provides the implementation of a
location provider also hosts other funcionality which may need to
call APIs that require a location permission.
This change allows a location provider to specify app op attribution
tags which which could be used when calling location to singal to the
OS that the access is for the location providing functionality of the
location provider. For location accesses of the provider package that
are not related to providing location to the OS the provider can use
any other non delcared as location attribution tags. Accesses with
the location attribution tags would be counted in app ops but instead
of towards the OP_COARSE_LOCATION/OP_FINE_LOCATION the would be
counted towards dedicated OP_COARSE_LOCATION_PROVIDER/
OP_FINE_LOCATION_PROVIDER ops. This would allow proper classification
while enabling auditability and tracking via the standard app op APIs.
<meta-data
android:name="android:location_allow_listed_tags"
android:value="foo;bar;baz"/>
Test: atest android.location.cts.fine.LocationManagerFineTest#testLocationAttributionTagBlaming
Bug:179062648
Change-Id: I36739ab42cedc94e1aa7a3bfd3b9aa213f5b3e97
