Permissions updates in Android 11

Android 11 gives users the ability to specify more granular permissions for location, microphone, and camera. This release also offers support to help developers audit data access and associate data access with particular features within your app.

One-time permissions

Dialog overlays the app content
Figure 1. Permissions dialog that includes Only this time option.

In Android 11, whenever your app requests a permission related to location, microphone, or camera, the user-facing permissions dialog contains an option called Only this time, as shown in Figure 1. If the user selects this option in the dialog, your app is granted a temporary one-time permission. Your app can access the related data only while one of the following remains true:

  • Your app's activity has been visible ever since the user granted the one-time permission.
  • Your app was visible when the user granted the permission and has been running a foreground service ever since then. As long as the foreground service keeps running, your app will retain the permission even if the user moves your app to the background.

If neither condition is true, you need to ask the user for the permission again, regardless of target SDK version.

WebView location access

If your app includes an instance of WebView, it's possible for users to allow continual access to location within the WebView object itself but restrict your app's location permission to Only this time. In this case, show a screen or dialog that explains the difference between the web permission and the app-wide system permission.

Permission dialog visibility

Android 11 discourages repeated requests for permissions in a specific permission group. If the user taps Deny twice for a specific permission during your app's lifetime of installation on a device, this action implies "don't ask again" for the corresponding permission group.

The system also defines behavior for responding to actions that emulate a tap of the Deny option:

  • If the user presses the back button to dismiss the permission dialog, this doesn't count as a "deny" action.
  • If the user is taken to system settings from your app using requestPermissions() and then presses the back button, this does count as a "deny" action.

Data access auditing

To provide more transparency into how your app and its dependencies access private data from users, Android 11 introduces data access auditing. By having insights from this process, you can better identify and rectify potentially unexpected data access. Your app can register an instance of AppOpsManager.AppOpsCollector, which can perform actions each time one of the following events occurs:

  • Your app's code accesses private data. To help you determine which logical part of your app invoked the event, you can audit data access by feature.
  • Code in a dependent library or SDK accesses private data.

Data access auditing is invoked on the thread where the data request takes place. This means that, if a 3rd-party SDK or library in your app calls an API that accesses private data, data access auditing allows your AppOpsCollector to examine information about the call. Usually, this collector object can tell whether the call came from your app or the SDK by looking at the app's current status, such as the current thread's stack trace.

Log access of data

To perform data access auditing using an instance of AppOpsManager.AppOpsCollector, implement the callback logic in the component where you intend to audit data access, such as within an activity's onCreate() method.

The onAsyncNoted() and onSelfNoted() methods are called in specific situations:

  • onAsyncNoted() is called if the data access doesn't happen during your app's API call. The most common example is when your app registers a listener and the data access happens each time the listener's callback is invoked.

    The AsyncNotedOp argument that's passed into onAsyncNoted() contains a method called getMessage(). This method provides more information about the data access. In the case of the location callbacks, the message contains the system-identity-hash of the listener.

  • onSelfNoted() is called in the very rare case when an app passes its own UID into noteOp().

Audit data access by feature

Your app might have several primary use cases, such as allowing users to capture photos and share these photos with their contacts. If you develop such a multi-feature app, you can define feature contexts within private data auditing. The featureId context is returned back in the objects passed to the calls to onNoted(). This helps you more easily track data access back to logical parts of your code.

To define feature contexts in your app, complete the steps in the following sections.

Create feature contexts

In the onCreate() method of the activity where you access data, such as the activity where you request location or access the user's list of contacts, call createFeatureContext(), passing in the logical name of the feature.

Include feature contexts in access logs

Update your AppOpsManager.AppOpsCollector callback so that your app's logs include the names of the features that you've defined.