This change adds initial support for scanning APEX directories looking
for APK, and make them available to the system as normal system APKs.
For now privileged apps and resource overlay are not supported, and the
support will be added in a later CL.
Scanning features are inherited from the partition in which the
preinstalled version of a given APEX module is located.
Supports both flattened and un-flattened APEX configurations.
Bug: 138429615
Test: Compiled a test apex with the Snake app installed in it. Verified
app is correctly scanned and usable. Tried also installing the apex in
/vendor and /product.
Change-Id: I8fb91317da0296567403b2b62babbb71e4b48938
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Merged-In: I53946ed4e31de0ffe9c84875c391a7dec6f5375a
Change-Id: Idaae690f79a5c680ad0059a52be62160d9dfb5e7
(cherry picked from commit 5e67462971)
There are already public versions of these APIs which allow
these queries for the calling app's user. Need to expose a version that
allows single instance apps, i.e user 0 (like wifi) to query info for
different users. The exposed APIs are:
a) isUserUnlockingOrUnlocked
b) isSameProfileGroup
Bug: 142024973
Test: Device boots up & connects to wifi networks
Change-Id: I77cd31a2344a6cbb272196523c10ad259aea74ce
Initial user creation is slow because the system must prepare per-user data (like storage and
permissions) whose cost is proportional to the number of pre-installed apps. On automovive's
reference implementation, it can take more than 10s, which is a bad user experience.
This change lets OEMs pre-create some users , so that high initial-creation cost is "paid" during
the initial boot. On automotive, it improves the creation of an additional user (or guest user)
in about 7s (from ~17s to 9s).
Bug: 111451156
Bug: 132111956
Bug: 140750212
Bug: 140868593
Test: manual verification
Test: atest FrameworksServicesTests:UserControllerTest#testStartTemplateUser_background
Merged-In: I81de1b5376dc9c42b63be8853d7204c88826401f
Change-Id: I81de1b5376dc9c42b63be8853d7204c88826401f
(cherry picked from commit c1ca4410e1)
Because SettingsProvider needs to call through the IUserManager
interface there is now a method to provide restricted-access information
via that route. It has the same protection as the implicit local
service call surface that was previously used: only system-uid callers
can invoke it.
Bug: 140833849
Test: system boots & runs normally
Change-Id: I05823ca57240ab10feb382c45590541212e406c1
1. decouple IOnSubscriptionChangedListener AIDL from telephonyMainline
2. other refactor. moving APIs which will not be included in
telephony mainline to frameworks/base/core/java/android/telephony.
Moving internal classes like AIDL which will not be included in
telephony mainline to
framework/base/core/java/com/android/internal/telephony
Bug: 140908357
Test: Build & unit test
Change-Id: I9413ef758cceadd251d03f3b5ea1054cc48ef044
waitForService is used to lazily start AIDL services
Bug: 138756857
Test: Manual (tested starting gsiservice with this function)
Change-Id: I7ff16b014052d3845bd4b1baa8fc9843e7975a16
We've already been parsing them for many years, and they're well
defined by other public APIs, so let's reveal them in MediaStore.
Also get some storage-related documentation updated to guide
developers towards replacements in a post-scoped-storage world.
Bug: 140247264, 139185855, 141523097, 139185322
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: Id39a74a9972a330b3f83913b2eef5100ec59627d
Bug: 138204026
Test: Add <meta-data android:name="com.android.graphics.injectLayers.enable" android:value="true" />
to the <application> xml in the manifest of the RELEASE build of a GL/Vk app. Add layer(s) using the method
described here: https://developer.android.com/ndk/guides/graphics/validation-layer
Change-Id: If4809c139f4a667ddf125358274a6d1d030a57d8
Mark the marshaling functions for non-primitive parameters as being
@FastNative: they're all expected to complete quickly.
According to the table in CriticalNative.java, the difference between
a regular JNI call and a FastNative call is about 80ns, so this change
should shave about 160ns per non-primitive parameter off the latency
of a binder transaction. The actual savings will be greater as we also
use these Parcel methods to marshal and unmarshal complex objects like
PackageInfo sent as objects over Binder.
Bug: 142271139
Test: boots
Change-Id: I85c3ee8498640193b9c0777c8c5e7eb349c7b23c
