Google is committed to advancing racial equity for Black communities. See how.

App permissions overview

Android builds upon system security features by allowing users to grant or deny different app permissions. These permissions protect access to the following:

  • Restricted data, such as system state and a user's contact information.
  • Restricted actions, such as connecting to a paired device and recording audio.

This guide provides an overview of app permissions for developers who are getting started with Android. For more information about how to declare and request permissions, view the in-depth permissions guide. For a complete list of Android app permissions, view the permissions API reference page.

Install-time and runtime permissions

The system grants some permissions to your app automatically when the user installs your app. These permissions are known as normal permissions or install-time permissions.

The system requires your app to request other permissions at runtime. These permissions are known as dangerous permissions or runtime permissions. Many runtime permissions grant your app access to a special type of restricted data, known as private user data. Examples of private user data include location and contact information.

Users are shown different UIs for install-time permissions and runtime permissions:

  • An app store presents an install-time permission notice to the user when they view an app's details page.
  • The system presents a runtime permission prompt to the user when an app requests a runtime permission. Users usually grant or deny access to your app's runtime permissions while they are interacting with your app.

Figure 1 illustrates this difference:

The left image shows a list of an app's install-time permissions. The
    right image shows a pop-up dialog that contains 2 options: allow and deny.
Figure 1. Users see different UIs for install-time permission notices (left) and runtime permission prompts (right).

Support Android's privacy goals

App permissions help Android support the following goals related to user privacy:

Control

The user has control over the data that they share with apps.

To support this goal in your app, allow users to continue interacting with your app, even when they deny a permission that your app requests at runtime. Your app should gracefully degrade to provide as much functionality as possible without having access to the information that's associated with the denied permission.

Transparency

The user understands what data an app uses, and why the app accesses this data.

Because the system shows a dialog when your app requests a runtime permission, users are aware that your app is requesting access to their data. Your app's UI should it make it clear to users why your app needs access to the information that's associated with the requested permission.

Data minimization

An app accesses and uses only the data that's required for a specific task or action that the user invokes.

When users grant a permission to your app, access the minimal amount of data that's required to provide functionality that benefits the user. For example, if you need to access location information, request the ACCESS_COARSE_LOCATION permission instead of the ACCESS_FINE_LOCATION permission if possible.

Best practices

To use permissions effectively in your app, follow these best practices:

  • Request a minimal number of permissions in your app. When the user requests a particular action in your app, your app should request only the permissions that it needs to complete that action.
  • Associate runtime permissions with specific tasks and actions in your app. Request permissions as late into the flow of your app's use cases as possible.

    For example, if your app allows users to send audio messages to others, wait until the user has navigated to the messaging screen and has pressed the Send audio message button. After the user presses the button, your app can then request access to the microphone.

Workflow for using permissions

To use permissions in your app, follow this process:

  1. In your app's manifest file, declare the permissions that your app might need to request. By declaring install-time permissions, your app can access the restricted data and perform the restricted actions associated with these install-time permissions after the user installs your app. If your app declares any runtime permissions, continue to the next step.
  2. Design your app's UX so that specific actions in your app are associated with specific runtime permissions. Users should know which actions might require them to grant permission for your app to access private user data.
  3. Wait for the user to invoke the task or action in your app that requires access to specific private user data. At that time, your app can request the runtime permission that's required for accessing that data.
  4. Check whether the user has already granted the runtime permission that your app requires. If so, your app can access the private user data. If not, continue to the next step.
  5. Check whether your app should show a rationale to the user, explaining why your app needs the user to grant a particular runtime permission. If the system determines that your app shouldn't show a rationale, continue to the next step directly, without showing a UI element.

    If the system determines that your app should show a rationale, however, present the rationale to the user in a UI element. This rationale should clearly explain what data your app is trying to access, and what benefits the app can provide to the user if they grant the runtime permission. After the user acknowledges the rationale, continue to the next step.

  6. Request the runtime permission that your app requires in order to access the private user data. The system displays a runtime permission prompt, such as the one shown in Figure 1.

  7. Check the user's response, whether they chose to grant or deny the runtime permission.

  8. If the user granted the permission to your app, you can access the private user data. If the user denied the permission instead, gracefully degrade your app experience so that it provides functionality to the user, even without the information that's protected by that permission.

Figure 2 illustrates the workflow and set of decisions associated with this process:

Figure 2. Diagram that shows the workflow for using permissions on Android.