In this change we introduce new system api to manage tracking apps for
inactivity when they hold one-time permissions. The api includes adding
a package, removing a package, and a callback to notify the app has gone
inactive and which permissions are considered one-time.
Also introduce a new permission flag so that it is possible to determine
if a currently granted permission is one-time.
Test: Manual
Bug: 136219229
Change-Id: Iac3cb776a0204c64953f0a03abe76c8e320c9e56
and revokeDefaultPermissionsFromLuiApps from PermissionManagerService to
Permmission Manager
Bug: 142019744
Test: Build
Change-Id: Ic39e1a66b650e7969242eb2116f342de488b1ca6
In AOSP the permission backup+restore is driven by the system server,
but some OEMs might drive it from an app. Hence allow a privilidged app
to backup + restore permission backups.
Test: atest CtsBackupTestCases
Fixes: 141007569
Change-Id: Ic89b476948872c491de8ea54b83667afc0183bb4
This is known to take 500ms and affects only UI,
so can be done async
Test: Ensure nothing looks badly broken; presubmit
Fixes: 139485700
Change-Id: I2b83b51ec5b002e08986019b4b6be3d681741544
Creating a SystemConfig from a non-system process is taking 500+ ms.
This CL instead exposes the needed split permissions from system_server
to optimize performance.
Tested locally and creating PermissionManager / retrieving SystemConfig
is now less than 1 ms.
Bug: 139828734
Bug: 139485700
Fixes: 139828734
Test: Added systrace / logs to PermissionController app and traced
runtime of onGrantDefaultRoles().
Change-Id: I111403e8dae3bc2b0acafc32e61aa5cd890fea29
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
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
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
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
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
So that we can implement different behavior between Android P and Q.
Test: Upgraded P->Q and booted fresh install of Q. Checked DB after boot
Bug: 131427665
Change-Id: I89f9dc1fc11129c95c03834e21628c6be75f2875
- saves ~3 allocation per ipc
- no longer need to [un]bundleize result
- will become typesafe down the road (b/132732312)
Test: atest android.permission.cts.PermissionControllerTest
Change-Id: I6cd9ec5ae31179474536f22f557afb0d9db6a4b9
Currently only for the ContextImpl.enforcePermission code paths and only
when 'secure debug_package_permission_check' is set.
This feature is disabled on user-builds.
Test: Enabled permission checking for my app and
- checked runtime permision denial
- permission denial because app is instant
Bug: 111075456
Change-Id: Ib85777db69ee490608e9dac32a3b97971c0ba215
The Build.VERSION_CODES.P0 was the stub for a potential new API level
after P. Now it's Q thus the usage for P0 field is not valid any more.
This CL also fixed the android.os.cts.BuildTest test failure for
cf_x86_phone-userdebug
Bug: 131601118
Test: presubmit test on ag/7204147
Change-Id: Iee474e95a35e051e6a3f4f96da5d82387d33d013
as this might be null. In PermissionControllerManager we need a context
that outlives the passed in context as we bind to a service that will
only get destroyed after a delay.
Test: atest PermissionControllerTest
Bug: 131356152
Change-Id: Iabeac669f6464b84a4b9e8f9b2a27959b116c25b
As otherwise the mainthread is overwhelmed and blocking.
Test: atest CtsPermissionTestCases:android.permission.cts.PermissionControllerTest
Fixes: 130738002
Change-Id: I1d6cbc60411802cef1c8aedbb6e89430e65b2aa9
This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
in order to support multiple binding flags
And supply BIND_ALLOW_BACKGROUND_ACTIVITY_STARTS for RemoteFillService.
Test: atest CtsAutoFillServiceTestCases
Test: atest AutofillManagerServiceTest
Bug: 126267782
Change-Id: Id5262d6a4e0fde0ad874020f783cfbf72fe201f4
I forgot to change the type when I moved this from being the albel to
being the name.
Fixes: 128994612
Test: Call API.
Change-Id: Ie2d7a48512015304fe748c834e60a1ad445c4276
Move isApplicationQualifiedForRole() and isRoleVisible() from
PermissionControllerService to RoleControllerService.
Bug: 127691087
Test: manual
Change-Id: Ic9277f9e737e59dceafffabbf1e19526db609e78
This allows us to expose both system-only and app available APIs for
role in RoleControllerService.
Bug: 127691087
Test: manual
Change-Id: I86fe3736fc28516aae25d48efe3ba599ffdf45d5
Also make sure that nullability
- is enforced during creating
- is enforced during un-parceling
Test: Looked at Settings screens that read this data
Fixes: 126702133
Change-Id: I8cdd3a5583f01276702307b40f65fa8d7ac49bf2
Only set nullability if super-method specified nullability at the same
place too.
Test: Built
Bug: 126701055
Change-Id: I08b9ac43ecb5f200d192a536449a880bc9a91f38
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
The default app shortcut in app info inside Settings needs to know if
a role is visible, and whether it is visible is controlled logic in
PermissionController, hence add this API.
Bug: 124452117
Bug: 124457823
Test: manual
Change-Id: I6058dea3bbda8b06d2fb9bab35268397227dd37b
This is much slower than the old way as we need to call into a different
process. On the other hand this handles the following cases correctly:
- foreground / background permissions
- pre-M apps
- split permissions
Test: CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testPermissionGrant,testPermissionPolicy,testPermissionMixedPolicies,testPermissionAppUpdate,testPermissionGrantPreMApp
Change-Id: I5cd139ad29e5b77b77b02e12c75eb774984a7759
Bug: 124128308
Also split some logic from PendingRequest into BasePendingRequest, so they're
not leaked into the async requests.
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Bug: 117779333
Change-Id: Ife9a3ab3a817944408caf9eae69dd75f48ab90c6
