summaryrefslogtreecommitdiff
path: root/core/java/android/permission/PermissionManager.java
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'android-13.0.0_r63' of ↵George Zacharia2023-08-021-2/+1
|\ | | | | | | | | | | | | | | https://android.googlesource.com/platform/frameworks/base into t13.0-r52 Android 13.0.0 release 63 Change-Id: I89d2c7a713cd97f805f07f604090a6d779117575
| * Watch uid proc state instead of importance for 1-time permissionsEvan Severson2023-05-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The system process may bind to an app with the flag BIND_FOREGROUND_SERVICE, this will put the client in the foreground service importance level without the normal requirement that foreground services must show a notification. Looking at proc states instead allows us to differentiate between these two levels of foreground service and revoke the client when not in use. This change makes the parameters `importanceToResetTimer` and `importanceToKeepSessionAlive` in PermissionManager#startOneTimePermissionSession obsolete. Test: atest CtsPermissionTestCases + manual testing with mic/cam/loc Bug: 217981062 (cherry picked from https://googleplex-android-review.googlesource.com/q/commit:0be78fbbf7d92bf29858aa0c48b171045ab5057f) Merged-In: I7a725647c001062d1a76a82b680a02e3e2edcb03 Change-Id: I7a725647c001062d1a76a82b680a02e3e2edcb03
* | frameworks: Exempt location packages from location indicatorsChirayu Desai2022-10-221-0/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: Chirayu Desai <chirayudesai1@gmail.com> Date: Wed Feb 9 03:46:53 2022 +0530 frameworks: Exempt location packages from location indicators * Otherwise it gets pretty spammy config_locationProviderPackageNames: * Pretty obvious, location providers, e.g. GMS config_locationExtraPackageNames: * Pixel 6 IMS package * https://cs.android.com/android/_/android/platform/frameworks/base/+/ffb94e69c3fc308d6d4164e2309f74442282fc84 * This grants location permissions, however we're excluding these apps from location indicators - they already have location permissions! * https://cs.android.com/search?q=config_locationExtraPackageNames&sq= * It isn't used for much else, so it's fine to re-use it for this TODO: Figure something out for user-installed UnifiedNlp plugins Test: 1. Open app with location access such as OrganicMaps, verify apps shown as using location 2. No more regular in background location indicators from UnifiedNlp, or Nearby Change-Id: I395335b858a2ec8fc4879139afcdaa590523d994 Author: Timi Rautamäki <timi.rautamaki@gmail.com> Date: Wed May 4 12:31:56 2022 +0000 PermissionManager: fix NPE in getIndicatorExemptedPackages sLocationProviderPkgNames and sLocationExtraPkgNames can be null because they're static. Also rename them from member to static variable to follow code style. Change-Id: I7d08e02047ccf183cc75ce18b3ebd2086b2831b3 Change-Id: Ib16c4b2e182f273bf2a22884180913763dc6a9a7
* Fix printing duplicate logs to save on batteryManjeet Rulhania2022-03-261-2/+10
| | | | | | | | | Adding state to remember if a log for missing activity manager is already printed or not. Bug: 202092164 Test: Manual Change-Id: Ia945a7396d06f7e8a3fc12359583970faed06a72
* Add conditional permission check annotation to checkPermission methodsNate Myren2022-03-211-0/+15
| | | | | | | | | | Per API council feedback, reflect that the first app in an AttributionSource chain must have UPDATE_APP_OPS_STATS to do a trusted blame Fixes: 222094627 Test: build Change-Id: I63513ca70ddebe0fd5a05d4414f88985bc3fcad4
* Self-revocation: Call PermissionControllerManager directly from ContextThomas Vannet2022-03-161-14/+0
| | | | | | | | | | | | | | | | This fixes a bug where self-revocation didn't work in multi-user settings. Now the correct context is used throughout the call stack and the permission for the calling user will be revoked. Also added a checked IllegalArgumentException (previously unchecked SecurityException) when trying to revoke a permission that is not currently granted. Test: manual using two users and atest android.permission.cts.RevokeOwnPermissionTest Bug: 218788609 Change-Id: I3dce34b8b956b4d1eb0ac1e34b6fdbf1795aa269
* Merge "Add attribution to PermGroupUsage and indicators"Ganesh Olekar2022-02-171-2/+13
|\
| * Add attribution to PermGroupUsage and indicatorsGanesh Olekar2022-02-171-2/+13
| | | | | | | | | | | | | | Bug: 200280741 Test: atest com.android.systemui.privacy.PrivacyDialogTest Change-Id: I1dcd7bea997605f3caaac742419476f4e0ac2fdf CTS-Coverage-Bug: 220157796
* | Add information to grant permissions intent for continue messagesNate Myren2022-02-091-0/+17
|/ | | | | | | | | | | After first launch, remember T+ apps which had the review required flag cleared on launch, until a grant permission request comes in. Also modifies some behavior of the upgrade code grants. Bug: 194833441 Test: atest NotificationPermissionTest Change-Id: Iafef8348e6cdb05fb214382b945cc7886beaff4b
* Add killed delay param to startOneTimePermissionSessionThomas Vannet2022-02-031-5/+30
| | | | | | | | | | | | | | | This param controls how long to wait before revoking permission after every process has been killed. Deprecate previous API and update all known uses of the deprecated API. Use updated API for self-revocation feature. If multiple one-time permission sessions are started for the same package with different parameters, always use the shortest parameters. Test: atest android.permission.cts.RevokeOwnPermissionTest, atest android.permission.cts.OneTimePermissionTest Bug: 210387494 Change-Id: I0c0e21b3b48dd31f0c267d5c8b89336714835289
* Merge "create systemApi checkPermissionForStartDataDelivery in ↵Nate Myren2022-01-251-0/+36
|\ | | | | | | PermissionManager"
| * create systemApi checkPermissionForStartDataDelivery in PermissionManagerNate Myren2022-01-101-0/+36
| | | | | | | | | | | | | | | | | | This allows us to check attribution for started ops in tests, and support starting in system apps Test: atest CameraMicIndicatorsPermissionTest Bug: 212434116 Change-Id: Iacdf1d339588cd680c20b3fb55ada9cedb2e70b0
* | Rename selfRevokePermissions to revokeOwnPermissionsOnKillThomas Vannet2022-01-211-3/+3
| | | | | | | | | | | | | | | | Test: atest android.permission.cts.RevokeOwnPermissionTest Bug: 215555831 Bug: 210575642 Bug: 210387494 Change-Id: I94e29f66d13ac76669fab2ccc08879c30c26b7ea
* | Add self revocation public APIThomas Vannet2022-01-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Test: Manual test using a non-privileged app, atest android.permission.cts.SelfRevokeRuntimePermissionTest When calling the API, the permission (along with any other permissions from the same group) for the current package is downgraded to a one-time permission, and a one-time permission session is started. Bug: 210387494 Change-Id: I9f061cbc8c3db720127c96200fe94a644246b6d7
* | Allow shell to revoke notification permission without killNate Myren2022-01-101-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Add the revokePostNotificationPermissionWithoutKillForTest API, which will allow the shell to revoke the POST_NOTIFICATIONS permission without killing this app. Gate this permission behind the REVOKE_POST_NOTIFICATIONS_WITHOUT_KILL permission, which is signature|privileged, accessible only to the shell. Ignore-AOSP-First: Contains information about unreleased features Test: manual Bug: 194833441 Change-Id: I3177d1aeb338591c1d736aa6b4f073b6db6227e7
* | Merge "Prepare PropertyInvalidatedCache for SystemApi"Lee Shombert2022-01-061-3/+3
|\ \ | |/ |/|
| * Prepare PropertyInvalidatedCache for SystemApiLee Shombert2022-01-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug: 152453213 Tag: #refactor This commit prepares PropertyInvalidatedCache to function as a system api. Specifically, the methods recompute() and bypass() which may be overridden by clients are now public (instead of protected). This forces an update to all existing clients, to accommodate the change in method visibility. Two small changes have been made as cleanup: 1. The awkwardly named debugCompareQueryResults() is now resultEquals(), which is more or less consistent with how other equality tests are named in Android. This name change affects two clients. 2. PackageManager has changed to use resultEquals() instead of maybeCheckConsistency(). This provides a simpler and more consistent use of the APIs. maybeCheckConsistency() has been made private. Test: atest PropertyInvalidatedCacheTests Change-Id: I4110f8e887a4fd8c784141e8892557a9d1b80a94
* | Merge "Intent action to review permission decisions"Jordan Jozwiak2022-01-051-0/+22
|\ \
| * | Intent action to review permission decisionsJordan Jozwiak2021-12-221-0/+22
| |/ | | | | | | | | | | | | | | | | Action will open the PermissionController screen to review recent permission decisions. Currently only supported on Auto. Bug: 194240664 Test: adb shell am start -a android.permission.action.REVIEW_PERMISSION_DECISIONS Change-Id: Ic37e0b69632d38596b707cd7b1a17fbb89bfa547
* / Javadoc on Method from api reviewWilliam Escande2022-01-031-1/+2
|/ | | | | | | | | | Add some specific info on checkPermissionForDataDeliveryFromDataSource javadoc. Fix: 204179567 Bug: 195144968 Test: build (it's only javadoc) Change-Id: I6d4e5b9e06bf990b5e40eb727259dc79753d5eef
* Merge "Only initialize PermissionUsageHelper lazily or when requested"Nate Myren2021-11-021-6/+25
|\
| * Only initialize PermissionUsageHelper lazily or when requestedNate Myren2021-11-021-6/+25
| | | | | | | | | | | | | | | | | | This fixes a memory leak caused by automatically registering a PermissionUsageHelper on PermissionManager instantiation. Bug: 204222680 Test: manual Change-Id: I94c6da3dd89e8b158552e94c94e4d0fb3f5d6f0d
* | Add checkPermissionForDataDeliveryFromDataSourceWilliam Escande2021-10-071-0/+33
|/ | | | | | | | | | | Api is used by Bluetooth and we need to stop using the hidden call to permissionChecker Add associated CTS test Bug: 195144968 Tag: #refactor Test: Build Change-Id: I854b7b5e3d95589bf0d3df307829e3f85e31aee1
* Expose PermissionChecker as system API.Hai Zhang2021-09-141-0/+84
| | | | | | | | | | | | | | | | | Only the most basic two APIs are exposed here, which happens to be the ones required by USB module so that we can unblock them before IC. The other overloads and variants can be exposed later when we have a proper decision on how to expose this entire class as an API. The constant values are hard-coded because they have to be compile constants to be included in API, while referencing the PermissionChecker fields doesn't count as such. More details are available in Buganizer comments. Bug: 195353742 Test: atest android.permission5.cts.PermissionCheckerTest Change-Id: I156c3be0e4c45c95a65bfa9117fb6b850b95238d
* Do not cache wildcard users (PermissionManager)Lee Shombert2021-08-021-0/+5
| | | | | | | | | | | | | | | | | | Bug: 186778818 PropertyInvalidatedCache queries that contain wildcard user IDs are no longer cached. Some simple multi-user tests show that no current caches use wildcard user IDs, so the change has no effect on performance. The bypass() mechanism is used to avoid the cache when necessary. The change is preemptive - there are no known uses of these caches with wildcard user IDs. Test: atest * FrameworksServicesTests:UserManagerServiceCreateProfileTest Change-Id: I60be14ae33fcd6e2e8df30c279311f6ffdf7711c
* Pass metadata as AttributionSourceSource.Jeff Sharkey2021-07-271-2/+2
| | | | | | | | | | | | | | | These two PermissionManager methods are using AttributionSource as metadata only, and aren't interested in the remote caller enforcing that the claimed UID matches the caller, since they're not actually being used for permission enforcement. Thus we pass the metadata using the AttributionSourceState holder object and reconstruct on the remote side, entirely avoiding the enforceCallingUid() check. Bug: 193842956 Test: atest CtsPermission5TestCases Change-Id: I576b6feb8cc2b0586b4341268866d8027689293f
* Optimize AttributionSource tokens - baseSvet Ganov2021-07-101-2/+9
| | | | | | | | | | | | | | | | | | For cases where the attribution soruce doesn't need to be registered as trusted we are now using a shares static token since the only purpose of the token in these cases is for watching the source process dying as opposed to that and security for registered cases. bug: 192415943 Test: CtsPermissionTestCases CtsPermission2TestCases CtsPermission3TestCases CtsPermission4TestCases CtsPermission5TestCases Change-Id: I93fde9ca1cacada7929761533dcae11b2736ce1e
* Create Attribution Chains in HistoricalOpsNate Myren2021-06-231-10/+25
| | | | | | | | | | Add a historical flag to signify that attribution chains should be assembled. Assemble the chains, filter out middle nodes, and attach the last visible node to the start as a proxy info Bug: 158792096 Test: manual Change-Id: I8fbd8f438c62b28fd90039440e86224c624dea79
* Support AttributionSource chains in PermissionUsageHelperNate Myren2021-06-041-4/+2
| | | | | | Test: manual Bug: 184963112 Change-Id: Idca4ccdaab1f243b754ef15888ea679788bfdd9b
* Switch media fw permissions checks to AttributionSourceSvet Ganov2021-06-011-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attribution source is the abstraction to capture the data flows for private data across apps. Checking permissions for an attribution source does this for all apps in the chain that would receive the data as well as the relevant app ops are checked/noted/started as needed. Teach speech recognition service about attribution chains. If an implementation does nothing the OS would enforce permisisons and do blame as always. This apporach leads to double blaming and doesn't support attribition chains where app calls into the default recognizer which calls into the on device recognizer (this nests recursively). If the implementer takes advantage of the attribution chain mechanims the permissions for the entire chain are checked at mic access time and all apps are blamed only once. Fixed a few bugs around finishing ops for attribution chains. Also ensured that any app death in a started attribution chain would lead to finishing the op for this app bug: 158792096 Test: (added tests for speech reco) atest CtsMediaTestCases atest CtsPermissionTestCases atest CtsPermission2TestCases atest CtsPermission3TestCases atest CtsPermission4TestCases atest CtsPermission5TestCases atest CtsAppOpsTestCases atest CtsAppOps2TestCases Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4 Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
* Fix nullability of the group name parameter in queryPermissionsByGroup().Hai Zhang2021-04-301-1/+1
| | | | | | Change-Id: Id503da0fe4f16a92997634089fc052d58e78f9df Fixes: 141452667 Test: presubmit
* Revert "Prepare AttributionSource to expose to native"Adam Bookatz2021-04-261-4/+0
| | | | | | | | | | | | | Revert "Prepare AttributionSource to expose to native - native" Revert submission 14225527-bug-158792096-04/16/21-1 Reason for revert: b/186467053 Reverted Changes: I16740cc2d:Prepare AttributionSource to expose to native - na... I4e050e78b:Prepare AttributionSource to expose to native Change-Id: I83e4091231241c2211edf5745735f4ee993c6680
* Prepare AttributionSource to expose to nativeSvet Ganov2021-04-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Separate the internal state of AttributionSource from the class to make it a simple AIDL we can translate automatically to native - keeping Java and native parts in sync. This would allow writing a thin native lib for checking attribution source permissions which would be used to teach camera and audio about attributions. Deinfe an AIDL interface for passing around an attribution source and opr performing permission checker oprations allowing native and Java permission checks on attribution chains to be handled. The Java side permission checker functions are in a dedicated permisison checker service on top of which sits the PermissionChecker. We expose similar PermissionChecker native APIs sitting on top of the same remote interface. The nice thing is that we have native and Java permisison checkers in sync sharing remoting code and being close in shape. For now the PermissionChecker in Java is divorced from the PermissionManager but in T we will consider how to unify them, either by an extension object on the PermmissionManager or APIs on the PermissionManager, or another approach, and then migrate clients off the PermissionChecker APIs. bug: 158792096 Test: atest CtsPermission5TestCases Change-Id: I4e050e78b2361cbf524cc213802e0fef5b487f67
* Do not hold indicators for apps that become pausedFabian Kozynski2021-04-151-0/+18
| | | | | | | | | | | | | If an app op becomes "paused" (microphone muted or disabled by toggle), remove the indicator immediately as opposed to holding for 5s. Also, pass the value that we are using for mic muted to PermissionManager, so they are in sync. Test: atest SystemUITests Test: manual Fixes: 184891081 Change-Id: I4d46fc6e1cefa45c0d718cc01f40c8f060dafee7
* Exclude only system and device intelligence roles from indicatorsNate Myren2021-04-071-12/+35
| | | | | | | | | | | Converts both the AppOpsControllerImpl and the PermissionUsageHelper to use the same static method when filtering which packages to show. The only packages which are filtered are 6 device intelligence roles, and the system package. These values are updated at most every 15 seconds Fixes: 184141707 Test: manual Change-Id: I9dc44197a2ff3df7783b37f450ada4ef2fb1ca6f
* Hookup renounced permissionsSvet Ganov2021-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | Propagate renounced permissions from context params to the context attribution source. Throw if one tries to request at runtime a renounced permission. Also make the AttributionSource take null for the setters to ease usage, otherwise folks should always check for null before calling a builder method. Additionally, we allow apps that have UPDATE_APP_OPS_STATS to register arbitrary trusted AttributionSource for testing. Note that this permission allows abritrary app op operations, thus we are not relaxing the security model. bug: 158792096 Test: atest CtsPermission5TestCases Change-Id: I4330684bb8695fb998cf31e9363b94ad981ba2cc
* Runtime permission attribution improvementsSvet Ganov2021-03-291-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an app is proxying access to runtime permission protected data it needs to check whether the calling app has a permission to the data it is about to proxy which leaves a trace in app ops that the requesting app perofmed a data access. However, then the app doing the work needs to get the protected data itself from the OS which access gets attributed only to itself. As a result there are two data accesses in app ops where only the first one is a proxy one that app A got access to Foo through app B - that is the one we want to show in the permission tracking UIs - and one for the data access - that is the one we would want to blame on the calling app, and in fact, these two accesses should be one - that app A accessed Foo though B. This limitation requires fragile one off workarounds where both accesses use the same attribution tag and sys UI has hardcoded rules to dedupe. Since this is not documented we cannot expect that the ecosystem would reliably do this workaround in apps that that the workaround in the OS would be respected by every OEM. This change adds a mechaism to resolve this issue. It allows for an app to create an attribution context for another app and then any private data access thorugh this context would result in a single app op blame that A accessed Foo though B, i.e. we no longer have double accounting. Also this can be nested through apps, e.g. app A asks app B which asks app C for contacts. In this case app B creates an attribution context for app A and calls into app C which creates an attribution context for app B. When app C gets contacts the entire attribution chain would get a porper, single blame: that C accessed the data, that B got the data from C, and that A got the data form B. Furthermore, this mechanism ensures that apps cannot forget to check permissions for the caller before proxying private data. In our example B and C don't need to check the permisisons for A and B, respectively, since the permisisons for the entire attribution chain are checked before data delivery. Attribution chains are not forgeable preventing a bad actor to create an arbitrary one - each attribution is created by the app it refers to and points to a chain of attributions created by their corresponding apps. This change also fixes a bug where all content provider accesses were double counted in app ops due to double noting. While at this it also fixes that apps can now access their own last ops. There was a bug where one could not pass null getting the attributed ops from a historical package ops while this is a valid use case since if there is no attribution everything is mapped to the null tag. There were some app op APIs not being piped thorough the app ops delegate and by extension through the app ops policy. Also now that we have nice way to express the permission chain in a call we no longer need the special casing in activity manager to handle content provider accesses through the OS. Fixed a bug where we don't properly handle the android.os.shell calls with an invlaid tag which was failing while the shell can do any tag. Finally, to ensure the mechanims is validated and works end-to-end we are adding support for a voice recognizer to blame the client app for the mic access. The recognition service can create a blaming context when opening the mic and if the mic is open, which would do all permission checks, we would not do so again. Since changes to PermissionChercker for handling attribution sources were made the CL also hooks up renounced permissoins in the request permission flow and in the permission checks. bug:158792096 bug:180647319 Test:atest CtsPermissionsTestCases atest CtsPermissions2TestCases atest CtsPermissions3TestCases atest CtsPermissions4TestCases atest CtsPermissions5TestCases atest CtsAppOpsTestCases atest CtsAppOps2TestCases Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
* Merge "Extend permission pregrant tracing utility" into sc-devEugene Susla2021-03-241-2/+10
|\
| * Extend permission pregrant tracing utilityEugene Susla2021-03-231-2/+10
| | | | | | | | | | | | | | Bug: 182579819 Test: manual Change-Id: I142d1c4470fe4f4b7c9ef52c23cf8dfc86fec792
* | Add Permission Indicator methods/classes to Test ApiNate Myren2021-03-231-0/+2
|/ | | | | | | | Also sets lastAccessTime = now for running ops Test: atest PermissionIndicatorAppOpUsageTest Bug: 172868375 Change-Id: I2a616f624640e0f219e33d6fa8ebf55559e24e1a
* Remove R QPR attribution hacksNate Myren2021-03-161-0/+22
| | | | | | Bug: 172868375 Test: manual Change-Id: I5e731bb821e879f6c314604912f13800ca668aa4
* Remove role exempt flagEvan Severson2021-02-251-15/+0
| | | | | | | | There is no use for this currently. Bug: 158311343 Test: atest CtsPermission{1,3}TestCases Change-Id: I102b30ccb3354e248e4e6be304c6dfe6135ba2a6
* Finish swapping packageName and permissionName.Hai Zhang2021-01-061-6/+6
| | | | | | | | | | | 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
* Merge "Remove IPermissionManager usage inside PackageManagerService."TreeHugger Robot2021-01-071-1/+1
|\
| * Remove IPermissionManager usage inside PackageManagerService.Hai Zhang2020-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Add most basic aspects of permission usage to PermissionManager"Nate Myren2021-01-061-0/+18
|\ \ | |/ |/|
| * Add most basic aspects of permission usage to PermissionManagerNate Myren2020-12-161-0/+18
| | | | | | | | | | | | | | | | | | 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
* | Use allowlist in permission internally.Hai Zhang2020-12-171-5/+5
|/ | | | | | | | | Now that our new APIs are named properly, clean up our naming internally as well. Bug: 158736025 Test: presubmit Change-Id: If70f8b012dec2d4f80e7fa1d36c47f6fbe370e81
* Move permission methods in PackageManager to PermissionManager.Hai Zhang2020-12-101-4/+706
| | | | | | | | | | | | | | | | | | | | | 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
* Move a subset of PermissionManager APIs into LegacyPermissionManager.Hai Zhang2020-12-101-156/+12
| | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 14:32:35 +0000