Please review the fundamental AIDL interfaces for enabling
the Incremenetal feature. Basically there are three services:
+ android.os.incremental.IIncrementalService:
Provides basic file operation functions. Will be implemented in native.
+ android.os.incremental.IIncrementalServiceProxy:
Started by SystemServer, is it the proxy that starts native
Incremental Service. The proxy also handles Java tasks like finding
data loader service package, binding to data loader service and talking
to it. Essentially the native Incremental Service controls the
data loader service via this proxy. Will be implemented in Java.
+ android.service.incremental.IIncrementalDataLoaderService:
Defines inteface for the base data loader service. I understand that
data loader is being re-designed but I would like to get the
"placeholder" in master first, and we can iterate on the implementation
details in master.
Test: builds
Change-Id: Ifc3a43633356951b239486d66ee80d120bc4ab76
1. add getCellularBatteryStats() at BatteryStatsManager.java
2. CellularBatteryStats API transform to @System Api
Bug: 138806762
Test: build pass and device boots up
atest TelephonyMetricsTest
Change-Id: Iec67f45f18ea26c96198bd732eadf14f878bdaa0
This is a preparatory work for mainline. since Intdef is hidden, so we
have to move some annotations (applied in SDK/system API) to a separate
annotation class and having other module statically link to it.
TODO: include telephony annotation in framework-non-updatable-sources
Bug: 140908357
Test: Build
Change-Id: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit c9d4ee112e)
Merged-in: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit 4712711d3d91621083bf92f5a1647b92c20a8b81)
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
(cherry picked from commit 288b71c8c1)
Merged-in: I1b750751148925b4a7bd94553318907654012fc1
We'll be able to expose system APIs from jobscheduler-framework.jar and
use them from framework-minus-apex.jar, so these elaborated initialization
will not be needed.
Bug: 142281756
Test: boot, "dumpsys batterstats"
Change-Id: I957642fc2573818d138450747e0690d7176636ad
Add new attribute capability to ProcessRecord, it represents what this
process is allowed to do. Capability is a separate dimension for
process state (ProcState).
In OomAdjuster.java, capabilities can be passed from client to service.
Add PROCESS_CAPABILITY_FOREGROUND_LOCATION to represent the capability
that can access location while-in-use.
For permission such as foreground location access, AppOpsService
checks for FOREGROUND_LOCATION capability, also checks if the process
is in one of the foreground process states, if both conditions meet,
the locaton operation is allowed.
Remove PROCESS_STATE_FOREGROUND_SERVICE_LOCATION.
Bug: 136274596
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
atest CtsAppTestCases:ActivityManagerApi29Test
atest frameworks/base/services/tests/mockingservicestests/src/com/android/server/appop/AppOpsServiceTest.java
Change-Id: Ie1c8e670fb0789208b753eb49b7e2fce6a2f211f
