Location indicator has its own flag, so it is being removed from the hub
teamfood. Also, showing all system usages (except the system app) for
the hub teamfood.
Bug: 172868375
Test: atest PrivacyDialogControllerTest, PrivacyItemControllerFlagsTest
Change-Id: Iad5b141f600a0bf830d5b2ef5169ed90533914cb
Restrict the admin of a fully-managed device or managed profile from
granting sensors-related permissions.
The admin of a managed profile cannot control permission grants for
sensors-related permissions at all.
The admin of a fully-managed device can opt-out of having said control
by providing a provisioning extra.
This change passes the boolean flag in ActiveAdmin indicating whether
the admin has control over sensor permission grants into the permission
controller.
Manual testing:
* Install TestDPC
* Create a work profile using TestDPC.
* Get the BasicLocation app by checking out
https://github.com/android/location-samples and building it from there.
* Install the app onto the device but do not start it.
* In TestDPC, Find "Manage app permissions", choose "Basic Location Sample"
from the drop-down menu.
* Toggle each of the "ACCESS_COARSE_LOCATION" and
"ACCESS_BACKGROUND_LOCATION" to "Allow".
* Observe that no notification appears.
* Start the BasicLocation app and observe the runtime permission prompt
shows up.
Bug: 158735247
Test: Manual (more to be added).
Test: cts (see topic)
Change-Id: I12d9f7e24ad4bc09651a5e5f60b864298506c2c4
Add the wifi call special case, where if a call is ongoing while a
carrier privileged app is using microphone, the phone call usage is
removed. Ensure the phone mic op is listened for, add code to find the
predictor app, and show it, if the user is in a teamfood. Filter the
system app out, since the system app can be a location provider
Fixes: 178701757
Test: Manual
Change-Id: Ic1bf7f28c99bc0f596492332f7b4656c3bd7d25e
Ensure the user context map is editable, and remove hardcoded enable.
Fixes: 178616169
Test: manual
Change-Id: I54d721be7712a2efcc3695bae5ae7e44920a40ed
Porting the proxy usage and mic special attribution cases from the
PermissionController to the PermissionManager
Bug: 172868375
Test: manual
Change-Id: I2af850c9cd709541abf862377b67153a1c477c94
Ensure that it is checked if an app op is running before filtering it
due to an old "lastAccessTime".
Fixes: 177089983
Test: manual
Change-Id: Ibeb344ad691994a93bde1a93794093d7d4fc920c
When assembling the op list, create a copy, do not use the existing
camera op list, as that list is final. Also return an empty list when
indicators are disabled, not null.
Fixes: 177005228
Test: Manual
Change-Id: I281085c12f0706836098fc2f16d196887596170e
Package is the subject and permission is the attribute, so naturally
package should come first. However, some APIs in the early days
weren't declared this way. Now that our new APIs are designed
properly, clean up our ordering internally as well.
Bug: 158736025
Test: presubmit
Change-Id: I47cab14bb80afcdb7e868fe75a375a4705606d9d
Because we are moving permission into mainline and AIDL can't be an
API.
Most usages are replaced with calling through PermissionManager
instead.
For checkPermission() and checkUidPermission(), they are not intended
to be exposed as cross-process APIs because people should use
Context.check*Permission() instead. So they are made in-process APIs.
resetRuntimePermissions() is moved to IPackageManager because it is
only used by PackageManagerShellCommand and is implemented by calling
resetRuntimePermissions() in a loop.
Bug: 158736025
Test: presubmit
Change-Id: I8285abddbfb3c4011a8acbc2e2ebfc30715c6f9a
Now that our new APIs are named properly, clean up our naming
internally as well.
Bug: 158736025
Test: presubmit
Change-Id: If70f8b012dec2d4f80e7fa1d36c47f6fbe370e81
Add the basic API for getting permission usage for mic, camera, and
location. Does not use special attribution yet. Mostly untested
Bug: 172868375
Test: Basic manual tests
Change-Id: Icb268b820557d62125e9307d6ffcf7046ab9b490
A number of permission-related methods were implemented in
ApplicationPackageManager by calling the IPermissionManager AIDL
interface. However since we are moving permission into module, the
AIDL inteface can't be an API and the implementions must be moved.
This change moves these methods into PermissionManager, with the
javadoc and interface from PackageManager and the implementation from
AppliationManager. The javadoc remains mostly the same except for
style and typo fixes. The API interface also remains the same except
for inclusive language changes since we are defining new one and have
a chance to fix them now.
We have to lazily get the PermissionManager instance because the
context passed in may be null for an instrumentation use case.
Bug: 158736025
Test: presubmit
Change-Id: I1c28433ca6200679a41e3518354fe03b866621b5
And move their implementation from PermissionManagerService to
LegacyPermissionService.
The DefaultPermissionGrantPolicy related methods are not APIs, and
are thus moved to LegacyPermissionManager and their usages are updated
to use LegacyPermissionManager.
The checkDeviceIdentifierAccess() method is also moved into
LegacyPermissionManager, because it's merely an application of
permission checking, not the permission management infra itself, and
there isn't great benefit in updating it. However since it is an API,
we still have to keep a delegate for it on PermissionManager, and make
the delegated method @SystemApi.
Bug: 158736025
Test: presubmit
Test: LegacyPermissionManagerServiceTest
Change-Id: Ic838f3685427217c8e0477551c3373258408983f
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
isPermissionEnforced() always returns true and is only exposed on AIDL
and there is actually no API, so it is directly removed.
setPermissionEnforced() currently doesn't affect anything so its
remaining implementation is removed as well, and we consider all
permissions enforced when needed for compatibility of dumping.
Bug: 158736025
Test: presubmit
Change-Id: I0584553ac0171147b6f131b5359ddb2964113a1d
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
Default apps (browser, dialer and home) are by no means a concept of
permission, so they should not be exposed as permission
manager API. Instead, they should be accessed via role manager API.
This change moves getDefaultBrowser() and setDefaultBrowser()'s AIDL
interface and implementation into RoleManagerService. Package manager
has a number of special behaviors regarding these default apps, so we
can not pretend that package manager doesn't know about these
roles. After all, we can say permission and role are at the same level
in the system after recent refactoring that split permission and
package. So package manager is reusing the public role API now.
The new methods moved to RoleManagerService needs to be system APIs on
RoleManager, because IRoleManager cannot be a system API and we need
to delegate method calls to it from ApplicationPackageManager.
The other methods directly calling into DefaultPermissionGrantPolicy
should be moved/refactored as well, depending on whether we want to
mainline it, in a later change.
Bug: 158736025
Test: presubmit
Change-Id: I84b9519a084e410875a3c3e88b33e9a612e7de98
- Remove IPermissionManager.getAppOpPermissionPackages() and its usage
because we are not going to expose it as a new API on
PermissionManager.
- Make PermissionManagerServiceInternal.getAppOpPermissionPackages()
unchecked because it's an internal API. Internal APIs should be by
default unchecked and checks should be done manually when
necessary.
- The parameters and return value of
PermissionManagerServiceInternal.getAppOpPermissionPackages() are
also made non-null to be a good API, and EmptyArray.STRING is
returned in the empty case so there won't be a performance penalty.
IPackageManager.getAppOpPermissionPackages() will return an empty
array for null permissionName before calling
PermissionManagerServiceInternal.getAppOpPermissionPackages() for
compatibility, and clients should handle returned empty arrays as
good as null.
- Use PermissionManagerServiceInternal.getAppOpPermissionPackages()
only to support the @UnsupportedAppUsage of
IPackageManager.getAppOpPermissionPackages() and perform checks
there.
Bug: 158736025
Test: presubmit
Change-Id: I0f96e898daa4cf40706430f1b7fbd5737a1f97f8
I.e. permissions and permission groups should stay inside a cert-group
so that there cannot be accidential security bugs in apps.
Test: atest CtsPermissionTestCases
CtsPermission2TestCases
CtsAppSecurityHostTestCases
Fixes: 146211400 (No backport possible, all changes are for S+ apps
only)
Change-Id: I19c2f3e216ea57a9e25c65e276f87425aeb1c038
