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.
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
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.