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.

We're interested in hearing your feedback! Please take this short survey to let us know how you're using the feature. In particular, tell us about use cases impacted by this feature.

One-time permissions

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. If the user selects this option in the dialog, your app is granted a temporary one-time permission.

Your app can then access the related data for a period of time that depends on your app's behavior and the user's actions:

  • While your app's activity is visible, your app can access the data.
  • If the user brings your app to the background, your app can continue to access the data for a short period of time.
  • If you launch a foreground service while the activity is visible, and the user then moves your app to the background, your app can continue to access the data until that foreground service stops.
  • If the user revokes the one-time permission, such as in system settings, your app cannot access the data, regardless of whether you launched a foreground service. As with any permission, if the user revokes your app's one-time permission, your app's process terminates.

Note: If your app already follows best practices related to permissions, you don't need to change your app to support one-time permissions. In particular, make sure you always check that your app has a permission before trying to access information that's guarded by that permission, and complete the following process if your app is requesting the permission for the first time, or if the user has revoked the permission:

  1. Call shouldShowRequestPermissionRationale(). If this method returns true, show a UI element in your app that explains to the user why your app needs the permission.
  2. Request the permission.

Dialog shown when requesting permission again

When the user next opens your app and your app then requests a permission related to location, microphone, or camera again, the user is prompted again. Table 1 shows several examples of the dialog that the user might see:

Table 1. Types of dialogs that user sees when requesting a one-time permission again
Target SDK version Type of permission requested Dialog that user sees
Android 10 or lower All available location permissions simultaneously Figure 3
Dialog overlays the app content
Figure 1. Permissions dialog that includes Only this time option.
The second dialog presents a link called Allow in settings
Figure 2. Sequence of dialogs that user sees if an app targets Android 10 and requests foreground and background location permissions separately
The first dialog presents a link called Allow in settings
Figure 3. Sequence of dialogs that user sees if an app targets Android 10 or lower and requests all available location permissions together

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.