It looks like there is some case where AbstractRemoteService would #run the
same PendingRequest the second time which violates AsyncTask assumption.
Fixes: 135986503
Test: atest android.permission.cts.PermissionControllerTest
Change-Id: I2d072714ee0fad3c365ff7eb191d690056c0931a
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
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
Most of the commands of PermissionControllerManager should go to the
calling user. If not - and the alternate user is running - we should
use the recommended way to talk to alternate users. This recommended way
is to create a package context for the user and call the method on this
new context.
Hence
- At a time we can have more than one RemoteService (one per user)
- Connect to the user declared in Context#getUser instead of the calling
user
Test: Called methods on work-profiles and saw alternate
PermissionController apps to be spawned.
Change-Id: I9ed87db1f658f18b69d19b39ba9f96361ec5af82
- Split system-server internal interface in two. One accessible only
inside of the services part of system server. One accessible
everywhere. This is necessary as the second part needs to be
accessible by the PermissionBackupHelper. But the former uses internal
data structures that should not be moved into android.permission.
- Remove old delayed permission restore code from
PermissionManagerService and Settings. This code now lives in
permission controller
- Keep the logic to remember which users still have delayed permissions
left. It is quite expensive to call into permission controller for
ever install of an app, hence this check is necessary. Currently this
mirrors the original logic. This can be improved further later.
Test: Built
Change-Id: Ibc1d5183c361dc55896882db1f7b765e1bee6e84
On Android backup restoration first restores and inital state. Then with
the packages getting downloaded the leftover "delayed" backup gets
restored bit by bit.
This currently just created plumming mirroring the previously implemented
behavior.
Bug: 116738135
Test: Built
Change-Id: I528b5f76dfca5bbdc9f69d6402b23b3d2ef11706
Settings DefaultAppShortcutPreference needs this info to determine
whether to show the shortcut to default apps on the app info page.
Bug: 110557011
Bug: 123238935
Test: manual
Change-Id: I3ffa62eb199ba9c761bf09a556443f685f6b6b50
As runtime permissions are complex, all runtime permission code is
consolidated into the permission controller app.
Hence the package manager service's permission backup code is now
calling into the PermissionControllerManager which is a interface to the
permission controller app.
Bug: 120907838
Test: Triggered a backup and checked the result via the debugger.
Change-Id: I633162189b728921d902050eee125b4b40b618fd
Regular ...Manager-s connect to the system server hence there is no
problem establishing a permanent connection via
ServiceManager.getServiceOrThrow.
(1)
PermissionControllerManager connects to an app, hence the binding has to
be dynamic. This is done my using the local RemoteService class.
(2)
...Manager-s are per context. Hence when the context goes away all
service connection started for this service are supposed to also be
cleaned up. There is no callback when the context goes away.
(1) and (2) lead to RemoteService connection to still be bound while the
context goes away which causes a service connection leak.
This change emulates the behavior of regular managers by creating a
permanent RemoteService tied to the application context. Of course
interanlly RemoteService itself binds and unbinds dynamically. Still,
now the RemoteService is not bound to a context that goes away and no
connection is leaked.
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
(this test failed before as settings was crashing due to leaked
remote service connections)
Change-Id: I5b8a4c62070fcce6e390897d046c4b28998e3952
As this has already evolved from just presenting data. In the future any
permission related calls to the permission controller will be added here.
As the calls are protected by different permissions the binding will not
require a permission anymore, but each individual call checks the
permission.
Bug: 120221960
Test: Looked at settings UI showing data from this interface
Change-Id: I6b4a5c3b7ee17b145e11e2c1b6e11a8a232bffed
Consolidate all permission related code in a single java package.
Test: atest SettingsLibRoboTests
Looked at Settings AppInfo UI (uses RuntimePermissionPresenter)
Bug: 120221960
Change-Id: If135e984a8273e9bed80cab9fbf2d70f40a05c7f
This needs to be available before package manager service is ready,
hence set it as soon as possible.
In the future we should also allow access to this mapping from other
processes than the system server.
Test: Built
Change-Id: If4240e5522e175ea9b341e4951ce261f17bbaadc
Instead of defining split permissions in Java file, we now move them to XML allowing us define vendor specific split permissions.
Test: Activity recognition is split correctly and auto granted when below split targetSdk.
Bug: 111411340
Change-Id: Ia5b3f47b73c9feea924373268a4eee142f555091
... as requested per API review.
- Sets require iteration via iterators
- Sets are more expensive to construct
- The advantage of sets (faster .contains) is not used
- The system ensures uniqueness of the entires in the list
Test: Built
Bug: 116798569
Change-Id: I2c3b5c6801b78e0bf942073bde1e90299aee39f6
The Permission Controller app (a mainline module) needs to be able to
read the SPLIT_PERMISSIONS. Hence this array needs to be exposed at
least as system-api. We need to make sure that the PackageParser,
PackageManager and Permission Controller app agree on which permissions
are split, hence it is best to define them at a single location.
I think exposing the split permissions to developers is useless and
potentially confusing. The app should never request a permission that
was split. The app should just behave as if split permissions do not
exist. The Permission Controller / Package Manager deal with the
split permissions and add them when needed. Hence I don't think we
should expose this data to 3rd parties.
Bug: 110953302
Test: requested permissions
Change-Id: I6951c52979c89ee5c13a4a14da125e1a01f2e234
