Create new APIs in TelephonyManager for DevicePolicyManager to add
override APNs, and use them in DevicePolicyManagerService instead of
directly accessing the APN database.
Bug: 146834818
Test: cts-tradefed run cts --module DevicePolicyManager --test
com.android.cts.devicepolicy.DeviceOwnerTest#testOverrideApn
Test: atest TelephonyManagerTest
Change-Id: I6c6214424169c05fd452db71a8c6593f8473b9d4
Merged-In: I6c6214424169c05fd452db71a8c6593f8473b9d4
When kernel is configured with CONFIG_VMAP_STACK=y kernel stacks are mapped
into process space and therefore already accounted as part of the value
returned by ReadVmallocInfo and reported under MEMINFO_VM_ALLOC_USED
category. Introduce isVmapStack function to check if kernel is configured
with that option and if so do not exclude kernel stack size in the
calculation of memory used by kernel.
Bug: 146088882
Test: dumpsys meminfo with CONFIG_VMAP_STACK enabled and disabled
Change-Id: I9230bbf0ab05524cf52ded35171fd9ec3da16fa0
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Instead of using "ro.product.apps.unbundled", use
"ro.product.vndk.version" to determine if product apks are unbundled.
"ro.product.vndk.version" will be defined by
PRODUCT_PRODUCT_VNDK_VERSION. If it is defined, all product apks must
be unbundled.
Bug: 144534640
Bug: 127738095
Bug: 128557860
Test: boot and check logs if product apps are loaded successfully
Change-Id: I6d0f7c20e131dfe12203c63a14e6254a8223893b
This is to fix an issue when calling getUser for a context that
is different than the context of the current foreground user.
getUser for a ContextWrapper would call the base
class Context#getUser which returns the user of the current foreground
process rather than returning the user of the calling context.
Currently, this is a bug that does not meet the ContextWrapper class Javadoc.
It looks like the ContextWrapper call was missed in Ib772ec4438e57a2ad4950821b9432f9842998451.
Fix: 144024489
Test: called the API from a test App with a different context than the
current application context.
Change-Id: I58ec9fda24bf135ba8c648a905ef0c81d36ea098
Merged-In: I2d24f5141e8cbc2546c8dc5894a1aeab376b7632
(cherry-pick from ag/9673528)
- Clean up usages of hidden AppOpsManager APIs in SmsApplication
- Add unit tests for SmsApplication
- Expose RoleManager#getDefaultSmsPackage for use in SmsApplication.
Bug: 146834818
Test: atest SmsApplicationTest
Change-Id: I4ab49d7f6274389e7de7cd7223cab3c433936044
* changes:
Hide com.android.server package with @hide javadoc tag
Add more enums for the client and process attributes of SystemApi
SystemApi is parameterized
Some internal changes are depending more strongly on annotations
being "leaves" which don't directly reference other parts of the OS,
so replace the direct import of Intent with a qualified javadoc
reference.
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I198d84a755b5e270a19b41328f6a6e152112c40a
Merged-In: I198d84a755b5e270a19b41328f6a6e152112c40a
1) Remove Unused Parameters for onDataConnectionState:
The data connection state broadcast includes a number of
parameters that are never used anywhere. To prepare for
updated code that relies on PreciseDataConnectionState,
remove the unused parameters that were internal-only and
included in the broadcast.
-LinkProperties
-NetworkCapabilities
-DataRoaming
-DataAllowed
-Interface name
2) Add Disconnecting State for Data Connections
Add a disconnecting state to correct a mismatch
between the internal and externally visible enums.
This will allow apps to know when connections are
in the process of being torn down, which in the case
of radio link issues could be as much as 15 seconds.
3) Expose PreciseDataConnection for Carrier Apps
Exposes the PSL for PreciseDataConnectionState along
with existing fields in the PreciseDataConnectionState
class.
-Make PreciseDataConnectionState public along with some
of its fields.
-Expose onPreciseDataConnectionStateChanged.
-Add onPreciseDataConnectionStatesChanged to provide PDCS
for all APNs in one cohesive batch.
4) Cache PreciseDataConnectionState by APN Type
In telephony registry, multiple different APN types
are all piped through the same cache entry, so every
time any APN changes relative to the previous type,
it triggers an update. This also means that when
a registrant requests the data connection state, only
the most recent type's state is updated.
This change caches entries in TelephonyRegistry based
on the APN's type (specifically the type among types
which triggered the change).
Bug: 143083105
Test: make update-api && make offline-sdk-docs
(no functional change in this CL).
Test: atest FrameworksTelephonyTests
Merged-In: Ib6a769f5a0cae923ca47a842733bd28755a90ed5
Change-Id: Ib6a769f5a0cae923ca47a842733bd28755a90ed5
(cherry picked from commit 4d340f12c9)
(cherry picked from commit c95b4e5421)
