| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the three backup related methods in PermissionManagerInternal
ready for system API. PermissionManagerInternal is currently used in
framework so it can't be removed without other changes yet. The other
listener methods are only used by PermissionPolicyService and will
become module internal.
Finally turn PermissionManagerInternal and
PermissionManagerServiceInternal into an interface from an abstract
class, and remove redundant modifiers after this.
Also refactors onUserCreated/Removed() to be system API ready.
Bug: 158736025
Test: presubmit
Change-Id: I335a7a37b737f6fa0faf0a2c34634d44199aee97
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose only start/stopShellPermissionIdentityDelegation() as API,
because there won't be a use case for UIDs other than the shell UID.
The caller checking is left in ActivityManagerService because only it
knows info about the ongoing intrumentations. So this new system
server API only delegates the permission identity of Shell to someone
else, but checking who can start the delegation to whom is the
responsibility of other parts of the system.
For now the API only delegates permissions checks since app ops won't
be updatable in this release, and it is a platform implementation
detail that ActivityManagerService also delegates app op checks via
the in platform AppOpsService interface at the same time. Once we
complete moving AppOpsService, this API will start delegating for app
ops (or whatever it will become) as well, and then the platform code
can just drop the app op related code and call this API only. Platform
code will have to drop those app op related code by then anyway since
the internal app op interface will no longer be available after the
move.
Bug: 158736025
Test: presubmit
Change-Id: I42839dacdf06e4d94682a46a0e692119de0bfdc0
|
| |
|
|
|
|
|
| |
Bug: 135279435
Test: atest android.content.pm.PackageManagerTests
Test: atest CtsCameraApi25TestCases
Change-Id: Id96093e4106edcd5302fd8aaa020d1ab83f68258
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
- 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
|
