- isHeadlessSystemUserMode() returns whether the device is running with
headless system user (go/multi-user-headless-user0)
- RoSystemProperties.MULTIUSER_HEADLESS_SYSTEM_USER is replaced by
isHeadlessSystemUserMode()
Bug: 137755681
Test: Bluetooth service and Network policy manager should work fine with
headless system user. A profile user should be created with headless
system user.
Change-Id: Ic48d98426f7a5ea47dde2008ae51f78855f622e6
This should be the last method movement. More work needs to
happen with the intenral APIs between the permission manager
and the package manager. There is still a lot of package
manager internal logic inside the permission manager.
Bug: 135279435
Test: atest PermissionUpdateListenerTest
Test: atest android.content.pm.cts.PackageManagerTest
Test: atest android.permission2.cts.RestrictedPermissionsTest
Change-Id: Iec118d198cb4ce3c4789991ddbdd2928dbc4bf6f
- In Auto, headless system user is used, instead of split system user.
- When a profile user is being created based on a normal user, the normal
user should not be a system user if headless system user is enabled.
- We could consider defining isHeadlessSystemUser in UserManager.
Bug: 137195727
Test: Creating profile user in Android Auto should work in hawk_md
environment.
Change-Id: I47192d8f92320296d4220ded285a36b376e6d971
Pass the set of disabled changes from the system server into the app in the
bindApplication() call. Use this to instantiate an implementation of
Compatibility.Callbacks() to implement the API.
Test: Manual.
Bug: 135010838
Change-Id: I2fcf25264c62acc801f9e62967072cd04e4641e7
The new MediaProvider design has an internal dynamic security model
based on the value stored in OWNER_PACKAGE_NAME, so the OS always
needs to consult the provider when resolving Uri permission grants.
Blocking calls from the system process like this are typically
discouraged, but this is the best we can do with the limited time
left, and there is existing precident with getType().
For now, use "forceUriPermissions" as a proxy for determining when
we need to consult the provider directly.
Bug: 115619667
Test: atest --test-mapping packages/providers/MediaProvider
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I1d54feeec93fbb4cf5ff55240ef4eae3a35ed068
Previously, the apex file being installed was moved into the staging
directory as same name provided during installation, due to which, when
the source apex file of installation did not have .apex suffix in its
file name, it failed validation in apexd. Now, if an apex file does not
have proper suffix, it will be concatenated during validation in
PackageInstallerSession.
Bug: 124837227
Test: atest CtsStagedInstallHostTestCases
Test: atest StagedInstallTest#testInstallStagedApexWithoutApexSuffix
Change-Id: Ice41f601dc42736ca0cdf2bad0817f0c00f50648
Allow Telephony to mark a SIM PhoneAccount as
emergency preferred, meaning that Telecom will
override a user's PhoneAccount preference for
emergency calls if the PhoneAccount has the
CAPABILITY_EMERGENCY_PREFERRED capability.
Bug: 131203278
Test: Manual testing, Telecom/Telephony unit testing
Merged-In: If70d917cfb3d825f375d282012b8788d69a2f144
Change-Id: I88b8bbfa444f5445b2f0d6a1542c6406a19b240f
These were the last few APIs that used the permission callback.
Completely remove it from the package manager and full implement
in the permission manager.
Bug: 135279435
Test: atest PermissionUpdateListenerTest
Test: android.content.pm.cts.PackageManagerTest
Test: android.permission2.cts.RestrictedPermissionsTest
Change-Id: Iab7c20215c907f4718f78a98fb96afec9fef6780
Also while doing this, it made sense to move the permission change
listener to the permission manager [it resulted in fewer hacks to
get the two sides to talk to one another].
Bug: 135279435
Test: atest PermissionUpdateListenerTest
Test: android.content.pm.cts.PackageManagerTest
Test: android.permission2.cts.RestrictedPermissionsTest
Change-Id: Ie08701dfe999cd435335103f4b4daeaa0b31ef10
Previously, Resources#getDrawable() would fail when trying to load a
ColorStateListDrawable from a ColorStateList defined in a resources
directory with a qualifier.
Bug: 137141830
Test: atest android.content.res.cts.ResourcesTest
Change-Id: I2ad57dd7cfa30de64653805d4ea209388ff90f41
This commit is mainly from I7a6a30bf8e8db9f2738594d187bb9148f138b8da, so
test cases and features are mostly same.
We change product_services partition name to "system_ext" because this
partition's purpose changes.
- installing a RRO package for framework from /system_ext/overlay
- installing apps from /system_ext/app
- installing priv-apps from /system_ext/priv-app
- installing permissions from
/system_ext/etc/[default-permissions|permissions|sysconfig]
Bug: 134359158
Test: `mma` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.system_ext library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.system_ext
=> confirmed that the package is a priv-app
Change-Id: Ibbccbba64156a7bc464ffb3785fb8fe69ebb973c
See another CL in the topic
Bug: 132428457
Test: builds
Change-Id: I87ba3fb539d0761c515adc8e2d2acc8dfc5e6a9a
Merged-In: If0bd3d368c7373ab0028211a8a4246a9821893af
Assume there is a XmlBlock [X] created by a AssetManager [A]
([A] will have mNumRefs = 2). After [A].close is called
(mNumRefs = 1) and then both [X] and [A] are going to be GCed,
if [A].finalize is called first (nativeDestroy), the later
[X].finalize will invoke [A].xmlBlockGone that triggers the
second nativeDestroy of [A] and leads to crash.
By clearing the mObject in AssetManager.finalize, the
decRefsLocked from other paths won't call nativeDestroy again.
Bug: 136721562
Test: atest AssetManagerTest
Test: Build and install CorePerfTests
adb shell am instrument -w -r --no-hidden-api-checks -e class \
android.app.ResourcesPerfTest#getLayoutAndTravese,android.graphics.perftests.RenderNodePerfTest \
com.android.perftests.core/androidx.test.runner.AndroidJUnitRunner
Change-Id: Ia938502d2443f5a6de6a3cabdb7ce1d41d3ff6d1
Now begins the parade of methods that can be migrated to the
permission manager service and be removed from the package
manager service.
We will still need to maintain some sub-set of APIs in the
package manager service due to unsupported app usage. When
we finally no longer support these AIDL methods, they can
be removed from package manager service.
Bug: 135279435
Test: Manual. Builds and runs
Change-Id: If12609ffdaeb75445d3ec9bcc7f946b8829ba769
This should resolve the confusion between internal name of APEXes that
comes from apex_manifest.json and packageName that comes from
AndroidManifest.xml.
Follow-up CLs:
* Rename package to module for all apexservice binder APIs.
* Rename package to module in apexd codebase.
Test: atest apexservice_test
Test: atest CtsStagedInstallHostTestCases
Bug: 132428457
Change-Id: If0bd3d368c7373ab0028211a8a4246a9821893af
Merged-In: If0bd3d368c7373ab0028211a8a4246a9821893af
(cherry picked from commit ec67395d7d)
Today, the package manager largely routes any permission related
method to the PermissionManagerService. But, PermissionManagerService
is a service in name only. Instead, we will make the
PermissionManagerService a real service and direct API calls directly
to it.
We will likely need to maintain all of the public permission APIs
that already exist on PackageManager. However, the public -> private
implementation will go directly to PermissionManagerService.
Bug: 135279435
Test: Manual. Device boots
Change-Id: Ia4992ba6d1f4b9050db98c7d7647d51a5d45fcbe
