summaryrefslogtreecommitdiff
path: root/core/java/android/app/AppOpsManagerInternal.java
Commit message (Collapse)AuthorAgeFilesLines
* RESTRICT AUTOMERGE Use chain start token in performOpTransactionNate Myren2022-12-141-9/+14
| | | | | | | | Bug: 258672042 Test: atest CtsPermission4TestCases Change-Id: I1d484ed7c72d4ae73f4cbec47522a18ae9088f6e (cherry picked from commit 297388e374f0a1e5b7f52961a81246c2fecb81e6) Merged-In: I1d484ed7c72d4ae73f4cbec47522a18ae9088f6e
* Don't block intent if op is restricted due to togglesEvan Severson2021-07-211-0/+8
| | | | | | Test: Create sdk 22 and 30 test apps and use the MEDIASTORE intents Bug: 192635623 Change-Id: I250a5e398e72919ec8217e87b76273082e781f63
* Merge "Add global app op restrictions" into sc-devTreeHugger Robot2021-06-291-0/+6
|\
| * Add global app op restrictionsEvan Severson2021-06-281-1/+7
| | | | | | | | | | | | | | | | | | Instead of managing across all users we can restrict globally and fast fail if the restriction is set Test: atest CtsSensorPrivacyTestCases Bug: 191016260 Change-Id: Ida1a2d1734b7e3d40818485062bec0f96270bc4b
* | Fix finishOp for HotwordDetectionServiceAhaan Ugale2021-06-251-1/+17
|/ | | | | | | | | | | | | | We currently specially handle the HotwordDetectionService uid in AppOpsPolicy. But CheckOpsDelegate doesn't currently include finishOp, so that doesn't work for the hotword service. This change adds finishOp to the interface and implements it in AppOpsPolicy to be consistent with the other ops. Bug: 190011174 Test: manual - no error in logs for finishOp Test: manual - privacy indicator works as expected (with another wip change) Change-Id: I77907092a917362aacd0d5562e54abd6f3c3d47b
* Switch media fw permissions checks to AttributionSourceSvet Ganov2021-06-011-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for excluding tags from restrictionsSoonil Nagarkar2021-05-141-3/+6
| | | | | | | | | Allow user restrictions to provide an excluded map of packages and tags rather than just packages. Bug: 187421886 Test: manual Change-Id: I8f90ba6cdd288068664b352fdb540d0f11fe3dfc
* Pipe start op throught app ops policy and delegateSvet Ganov2021-04-211-0/+24
| | | | | | | | | | | | | bug: 185504196 Test: atest CtsAppOpsTestCases atest CtsPermissionTestCases atest CtsPermission2TestCases atest CtsPermission3TestCases atest CtsPermission4TestCases atest CtsPermission5TestCases Change-Id: I5869a3e9719830f59624519f2d54f0765119cf5f
* Make note/startOperation return SyncNotedAppOp, add modeNate Myren2021-04-021-6/+6
| | | | | | | | | Use the SyncNotedAppOp when collecting self/sync ops in AppOpsManager. Also adds "mode" to SyncNotedAppOp Fixes: 184111263 Test: Atest AppOpsServiceTest Change-Id: Ia20c7054d06e241cbe017a641d728e11c7eccd06
* Runtime permission attribution improvementsSvet Ganov2021-03-291-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Prevent developer provided strings from being uploaded through statsd.Stanislav Zholnin2020-06-191-4/+4
| | | | | | | | | | | - in situation when developer provides message when op is noted, do not report it through stack trace collection infrastructure - collect only statcktraces for OP_FLAG_SELF and OP_FLAG_TRUSTED_PROXIED to match collection of appops counts Test: atest android.app.appops.cts.RuntimeMessageCollectionTest Fixes: 159433071 Change-Id: I1ab56a530832873a1f1f68aba5ab6eabc9e8a17a
* Don't mutate permission state when setting app op from PermissionPolicyService.Hai Zhang2020-02-131-6/+8
| | | | | | | | | | | | | | | | Previously the REVOKED_COMPAT flag may be updated when PermissionPolicyService is setting app op mode, however it should not do so because the app op mode is coming right from the permission state it was seeing. Mutating permission state would lead to incorrect permission state when PermissionPolicyService and PermissionController are running concurrently, and by no longer mutating permission state in PermissionPolicyService, the app op state will eventually arrive at the correct state even when there's some concurrency. Bug: 149267332 Bug: 136503238 Test: manual Change-Id: I9b02bc3f42a20ba441d5af9fd1b8a9729d8d0480
* Don't callback twice for app op changes in PermissionPolicyService.Hai Zhang2020-02-031-0/+13
| | | | | | | | | | | | | | If an app op change is made while syncing app ops from permissions, we know it's being set to our desired state and don't need to be notified again. This cuts the performance cost to at least half of what it was, and prevents potential looping. Bug: 136503238 Bug: 147673896 Bug: 146039935 Bug: 148706747 Test: manual Change-Id: I643472800c0dfbf96c202093a697f0a72eee0780
* FGS background start restriction.Hui Yu2020-01-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Background started foreground service shall not have while-in-use permissions including location, camera and microphone. Many exemptions have been applied including: --FGS started by widget. --FGS started by notification. --FGS started by IME or other visible app. --FGS started by ROOT_UID, SYSTEM_UID, NFC_UID. 2. Add a phenotype key KEY_DEFAULT_BACKGROUND_FGS_STARTS_RESTRICTION_ENABLED to turn on/off this feature (default is on). 3. In dogfood, if a background started FGS with while-in-use permission (any of location/camera/microphone) run into this restriction, the FGS will not been granted these permission. we show a toast message to alert user and ask them to write a bugreport using instruction at go/r-bg-fgs-restriction. So we can have a statistic how many apps will be impacted by this feature. These is a flag Settings.Global.FOREGROUND_SERVICE_STARTS_LOGGING_ENABLED to turn on/off the toast message (default is on, in dogfood) Bug: 136219221 Test: atest android.app.cts.ActivityManagerProcessStateTest atest android.app.cts.ActivityManagerApi29Test.java atest android.app.cts.ActivityManagerFgsBgStartTest Change-Id: Ibc8aaa6839a69136f9311bfacdbab9705b31b6a7
* Collect AsyncNotedAppOp in same call as noteOpPhilip P. Moltmann2020-01-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This reduces the overhead of collecting noted app-ops to the same amount of binder calls as if we would not have the feature Before (conceptionally): --------------------------------- mode = service.noteOp() if (mode == allowed && shouldCollectAsyncOp) { fixup(message) service.noteAsyncOp() } ---------------------------------- After (conceptionally): ---------------------------------- if (shouldCollectAsyncOp) { fixup(message) } mode = service.noteOp(shouldCollectAsyncOp, message) ---------------------------------- Bug: 136505050 Test: atest CtsAppOpsTestCases Change-Id: If1b535a7c4b0f431f251c5d06cdf496c34920e23
* Add feature contextPhilip P. Moltmann2019-10-171-4/+7
| | | | | | | | | | | | | | | Currently only used by app-ops, but can be used by other modules too. AppOps will collect app-ops based on feature. Only the most basic parts of app-ops are supporting features yet. The rest will be added later. Test: atest CtsAppOpsTestCases atest RunSettingsLibRoboTests atest com.android.server.wm.ActivityStarterTests m -j doc-comment-check-docs Bug: 136595429 Change-Id: Ia664f4ff1c1c2ceea721d76dc491ec50c237e9ce
* Remove unnecessary internal APIs.Philip P. Moltmann2019-05-071-29/+0
| | | | | Test: Built Change-Id: I5391ac4989d7d5712982f5608f9fc28cf7935b00
* Remove setAllPkgModesToDefaultPhilip P. Moltmann2019-04-151-8/+0
| | | | | | Bug: 124731615 Test: Built Change-Id: Ia4d92791145a92fa0c89cf26fc9f627cf7dda559
* Don't check pkg<->uid when called from internalPhilip P. Moltmann2019-03-121-0/+15
| | | | | | | | | | | The PermissionManagerService calls AppOpsService before the package manager is up. Hence AppOpsService cannot verify package properties. This is not needed in the calls from PermissionManagerService as this component can be trusted to provide correct data. Fixes: 127470436 Test: Upgraded from P->Q with a pre-M installed Change-Id: Ide529f13ab2cc3b7551e99c94935c0cb537a817b
* Reset per-pkg app-ops for runtime permissionsPhilip P. Moltmann2019-01-271-1/+9
| | | | | | | | | | | | | | | | ... on every boot. These should never have been set, but we allow settings them via the shell. - Also previously a bug set per-pkg app-ops. - Also set the app-op correctly when a fg/bg permission looses it's bg permission. Test: Set per-pkg app-opp. Rebooted and saw log message. atest --test-mapping frameworks/base/services/core/java/com/android/server/pm/permission/:presubmit Change-Id: If3b56fc08783ea99b4dba70c5fa275b94411ce94 Fixes: 123177944
* Set UID appops mode instead of package appops modePhilip P. Moltmann2018-12-201-5/+1
| | | | | | | | | | In PermissionManagerService and DefaultPermissionGrantPolicy. This mirrors what the permission controller is doing. Better make sure all modules changing app-ops for runtime permissions do it the same way. Test: Looked at pre-grants after boot, changed permissions after boot Change-Id: I88386ec6842324b28ab408ea5cd113c9cc7de9fe
* Make sure unsafeCheckOpRaw ops check raw opsSvet Ganov2018-12-191-2/+3
| | | | | | | | Test: manual bug:119323172 Change-Id: Ic21d03af3a08bdca76821f2bc644482e7e5a1300
* Split permissions inherit state from their parentsPhilip P. Moltmann2018-11-081-0/+18
| | | | | | | | | | | | | | | | | The old hack to grant permissions on upgrade was removed. The new code applies to - platfrom upgrade - initial package installation - package update Inheriting the grant state is the default behavior for split permissions. Special cases will be added later. Also make sure to revoke the permission once the app declares that it is aware of the permission. Test: atest CtsPermissionTestCases:SplitPermissionTest Change-Id: Ie51971530607f0b585cf7a3e11b01b11a28e1de9
* Allow UiAutomation to adopt the shell permission indentitySvet Ganov2018-07-031-0/+43
| | | | | | | | | | | | | | | | | | | | | For testing we often need to run shell commands. This can be done today via running a shell command from an instrumentation test started from the shell. However, this requires adding shell commands which are not in the API contract, involve boilerplate code, require string parsing, etc. This change allows an instrumentation started from the shell to adopt the shell UID permission state. As a result one can call APIs protected by permissions normal apps cannot get by are granted to the shell. This enables adding dedicated test APIs protected by signatures permissions granted to the shell. Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases -t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions bug:80415658 Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
* Allow device/profile owners to change app ops modes.Dianne Hackborn2018-05-141-0/+33
This allows them to continue to have this capability the same as before we locked down access to it. Bug: 78480444 Test: manual Change-Id: If2b0722945235eb67676ace3f54efaa71a64bcde