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
Those annotations could be inferred by some tools (like Kotlin), but the
https://checkerframework.org/ doesn't check inherited annotations
complaining about all equals() invocations that get nullable argument.
The change was generated by running
find . -name \*.java | xargs sed -i 's/public boolean equals(Object /public boolean equals(@Nullable Object /'
in the frameworks/base directory and by automatically adding and
formatting required imports if needed. No manual edits.
Bug: 170883422
Test: Annotation change only. Should have not impact.
Exempt-From-Owner-Approval: Mechanical change not specific to any component.
Change-Id: I5eedb571c9d78862115dfdc5dae1cf2a35343580
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Exempt-From-Owner-Approval: Cherry-pick of no-op refactor into another branch
Merged-In: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
Change-Id: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
(cherry picked from commit 4697f76edd)
Bug: 170472470
Do not disable the permission caches inside the system server. This
is beneficial because permission checks require many binder calls, and
the cache, even though it is in-process, eliminates those calls.
1. Make the PermissionManager cache more effective by increasing the
maximum size to 2048. Experiments show that the high-water mark is
about 600.
2. Suppress cache content in the 'dumpsys cacheinfo' output. dumpsys
fails if the output is too large in a single process, and the new
caches push the system server cacheinfo over the limit. The
content can be added to the output by setting the new DETAILED
boolean in PropertyInvalidatedCache to true, but this flag should
never be committed with a value of true.
Test: two atest runs
* atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest#testGetPermissionGrantState
* atest FrameworksServicesTests:NetworkPolicyManagerServiceTest
Change-Id: I7d3c1f34b44216bb510319ca5b6aced1cc53e05d
The recently added AndroidFrameworkBinderIdentity Error Prone checker
examines code to ensure that any cleared identities are restored to
avoid obscure security vulnerabilities.
This change is a purely mechanical refactoring that adds the "final"
keyword to the cleared identity to ensure that it's not accidentally
modified before eventually being cleared. Here's the exact command
used to generate this CL:
$ find . -name "*.java" -exec sed -Ei \
's/ (long \w+ = .+?clearCallingIdentity)/ final \1/' \
{} \;
Bug: 155703208
Test: make
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I832c9d70c3dfcd8d669cf71939d97837becc973a
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Change-Id: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
* changes:
Revert "Give all non-package services the power to interact accr..."
Revert "Check cross-user interactions for permissions and app-op..."
Revert "Invalidate package/permission cache if cross-profile app..."
Revert "Add dedicated host side tests for permissions and appops"
Revert submission 12439864-PermAppOpsCrossUserCheck-Fixed
Reason for revert: Bug 169044600
Reverted Changes:
I95d015e01:Invalidate package/permission cache if cross-profi...
I2a8a84f57:Check cross-user interactions for permissions and ...
Ie8f0db231:Give all non-package services the power to interac...
I11af434a8:Test package/permission cache invalidation when IN...
Ib6d609a4d:Add dedicated host side tests for permissions and ...
Change-Id: Iea5eeded0ee5caf5383bb0e749133d4fef18d392
* changes:
Invalidate package/permission cache if cross-profile app is is changed
Check cross-user interactions for permissions and app-ops operations
Give all non-package services the power to interact accross users
1.
We want to be quite permissive here as without being able to check
permissions or appops nothing else works. Hence allow cross-user
interactions if any cross-user permission is granted.
2.
Also we need to prevent infinite recursion as we are checking permission
and appops inside of permission and app-op checks.
2.
Clear Binder.callingUid when checking permission inside system server
Makeing the binder call "checkPermission" usually sets
Binder.callingUid to the calling processes UID. Hence clearing the
calling UID is superflous. If the call is inside the system server
though "checkPermission" is not a binder all, it is only a method call.
Hence Binder.callingUid might still be set to the app that called the
system server. This can lead to problems as not every app can check the
same permission the system server can check.
E.g. the system server can check permission accross user boundaries,
most regular apps can't
Test: atest CtsPermissionHostTestCases CtsAppOpHostTestCases // execute the new paths for both full users and profiles
atest ManagedProfileTest#testCameraPolicy // a previous version of the patch caused a regression in this test
atest AccountManagerXUserTest // a previous version of the patch caused a regression in this test
Accessed clipboard from chrome in work profile
Fixes: 153996875
Change-Id: I2a8a84f574fbf07ab88ed991445830fa85aa4450
PackageNamePermissionQuery (and all that uses it) speaks
of uid, but it actually stores/queries a userId. We therefore
rename the variable/parameter from uid to userId, as appropriate.
Bug: 163651060
Test: still compiles (no functional changes were made)
Change-Id: I3db2263a3f960d7eda35466a2e9058fe6f27e49a
Bug: 162103383
Update 'dumpsys cacheinfo': add the number times a cache is cleared,
rename misses due to cache disabled/unset/corked to "skips", and fix the
logic counting cache invalidates.
Make the cache name distinct from the property. There is no change to
legacy caches (which continue to use the property as the name) but
caches that share the cache_key.package_info property now have distinct
names.
Add the property name to auto-corker debug messages.
Test: Boot and run 'dumpsys cacheinfo' to verify the output.
Change-Id: I3e3e500dc9a1559fd7ccdc49fb00292ab5f712c1
For example, if it's not enabled for managed profiles, the message would now be:
7-13 20:46:38.308 16176 16205 E PermissionControllerManager: No PermissionController package (com.google.android.permissioncontroller) for user 11
07-13 20:46:38.311 22224 22224 E AndroidRuntime: FATAL EXCEPTION: main
07-13 20:46:38.311 22224 22224 E AndroidRuntime: Process: com.afwsamples.testdpc, PID: 22224
07-13 20:46:38.311 22224 22224 E AndroidRuntime: java.lang.RuntimeException: Unable to start receiver com.afwsamples.testdpc.DeviceAdminReceiver: java.lang.IllegalStateException: No PermissionController package (com.google.android.permissioncontroller) for user 11
Instead of:
07-13 18:07:19.887 26168 26168 E AndroidRuntime: FATAL EXCEPTION: main
07-13 18:07:19.887 26168 26168 E AndroidRuntime: Process: com.afwsamples.testdpc, PID: 26168
07-13 18:07:19.887 26168 26168 E AndroidRuntime: java.lang.RuntimeException: Unable to start receiver com.afwsamples.testdpc.DeviceAdminReceiver: java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.pm.ComponentInfo android.content.pm.ResolveInfo.getComponentInfo()' on a null object reference
Bug: 161135695
Test: adb shell setprop persist.debug.user.package_whitelist_mode 1
Test: # then install the TestDPC
Change-Id: I8d27b59cd5b96735e1d5e22a341bf869158e278f
The reason is passed to app exit info so a given app can get more
information about why their app was killed in the event of permission
revoke.
Test: atest RevokePermissionTest ActivityManagerAppExitInfoTest#testPermissionChangeWithReason
Fixes: 159659620
Change-Id: Id711667eb2c1579ecb2a1b83a62af3cc7862d5f6
