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.
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:
shouldShowRequestPermissionRationale(). If this method returns true, show a UI element in your app that explains to the user why your app needs the permission.
- 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:
|Target SDK version||Type of permission requested||Dialog that user sees|
|Android 10 or higher||
|Android 10 or lower||All available location permissions simultaneously||Figure 3|
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
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
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
onSelfNoted() methods are called in specific
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.
AsyncNotedOpargument 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.
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
featureId context is returned back in the objects passed to the
This helps you more easily track data access back to logical parts of your
To define feature contexts in your app, complete the steps in the following sections.
Create feature contexts
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
passing in the logical name of the feature.
Include feature contexts in access logs
AppOpsManager.AppOpsCollector callback so that your app's logs
include the names of the features that you've defined.