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

Permissions on Android

As described on the app permissions overview page, Android app permissions protect restricted data and restricted actions.

Android's app permissions build upon a central design point of the Android security architecture. By default, no app has permission to perform any operations that would adversely impact other apps, the operating system, or the user.

This page helps you evaluate whether your app needs to request permissions. This page also provides an overview to how Android permissions work, including the different types of permissions. Other pages explain how to declare permissions, request runtime permissions, and restrict how other apps can interact with your app's components.

Evaluate whether your app needs to declare permissions

Before you declare permissions in your app, consider whether you need to do so.

Every time the user tries an app feature that requires a runtime permission, your app has to interrupt the user's work with a permission request. The user then must make a decision. If the user doesn't understand why your app requests a particular permission, they could deny the permission or even uninstall your app.

Consider whether another installed app might be able to perform the functionality on your app's behalf. In these cases, you should delegate the task to another app using an intent. In doing so, you don't need to declare the necessary permissions because the other app declares the permission instead.

Alternatives to declaring permissions

This section describes several use cases that your app can fulfill without declaring the need for any permissions.

Show nearby places

Your app might need to know the user's approximate location. This is useful for showing location-aware information, such as nearby restaurants.

Some use cases require a rough estimate of a device's location, to within about 1.25 miles (2 km). In these situations, you can declare the ACCESS_COARSE_LOCATION permission. It's better to not declare the permission, and instead ask the user to enter an address or a postal code.

Other use cases require a more precise estimate of a device's location. Only in those situations, it's OK to declare the ACCESS_FINE_LOCATION permission.

Take a photo

Users might take pictures in your app, using the pre-installed system camera app.

In this situation, don't declare the CAMERA permission. Instead, invoke the ACTION_IMAGE_CAPTURE intent action.

Record a video

Users might record videos in your app, using the pre-installed system camera app.

In this situation, don't declare the CAMERA permission. Instead, invoke the ACTION_VIDEO_CAPTURE intent action.

Open another app's media or documents

Your app might show content that another app created, such as photos, videos, or text files.

In this situation, don't declare the READ_EXTERNAL_STORAGE permission. Also, don't directly access shared or external storage devices using methods like getExternalStorageDirectory(), which are deprecated as of Android 10 (API level 29). Instead, use the device's media store to open media files, and the Storage Access Framework to open documents and other files.

Identify the device that is running an instance of your app

A particular instance of your app might need to know which device it's running on. This is useful for apps that have device-specific preferences or messaging, such as different playlists for TV devices and wearable devices.

In this situation, don't access the device's IMEI directly. In fact, as of Android 10 (API level 29), you cannot do so. Instead, do one of the following:

  • Get a unique device identifier for your app's instance using the Instance ID library.
  • Create your own identifier that's scoped to your app's storage. Use basic system functions, such as randomUUID().

Pair with a device over Bluetooth

Your app might offer an enhanced experience by transferring data to another device over Bluetooth.

To support this functionality, don't declare the ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATIION, or BLUETOOTH_ADMIN permissions. Instead, use companion device pairing.

Pause media when your app is interrupted

If the user receives a phone call, or if a user-configured alarm occurs, your app should pause any media playback until your app regains audio focus.

To support this functionality, don't declare the READ_PHONE_STATE permission. Instead, implement the onAudioFocusChange() event handler, which runs automatically when the system shifts its audio focus. Learn more about how to implement audio focus.

Filter phone calls

To minimize unnecessary interruptions for the user, your app might filter phone calls for spam.

To support this functionality, don't declare the READ_PHONE_STATE permission. Instead, use the CallScreeningService API.

Get user approval

In order for your app to access restricted data and perform restricted actions, you must declare the appropriate permissions. Some permission, known as install-time permissions, are automatically granted when your app is installed. Other permissions, known as runtime permissions, require your app to go a step further and request the permission at runtime.

Types of permissions

Android categorizes permissions into different types, including install-time permissions, runtime permissions, and special permissions. Each permission's type indicates the scope of restricted data that your app can access, and the scope of restricted actions that your app can perform, when the system grants your app that permission.

Install-time permissions

Install-time permissions give your app limited access to restricted data, and they allow your app to perform restricted actions that minimally affect the system or other apps. When you declare install-time permissions in your app, the system automatically grants your app the permissions when the user installs your app.

Android includes several sub-types of install-time permissions, including normal permissions and signature permissions.

Normal permissions

These permissions allow access to data and actions that extend beyond your app's sandbox. However, the data and actions present very little risk to the user's privacy, and the operation of other apps.

The system assigns the "normal" protection level to normal permissions, as shown on the permissions API reference page.

Signature permissions

If the app declares a signature permission that another app has defined, and if the two apps are signed by the same certificate, then the system grants the permission to the first app at install time. Otherwise, that first app cannot be granted the permission.

The system assigns the "signature" protection level to signature permissions, as shown on the permissions API reference page.

Runtime permissions

Runtime permissions, also known as dangerous permissions, give your app additional access to restricted data, and they allow your app to perform restricted actions that more substantially affect the system and other apps. Therefore, you need to request runtime permissions in your app before you can access the restricted data or perform restricted actions.

The system assigns the "dangerous" protection level to runtime permissions, as shown on the permissions API reference page.

Special permissions

Special permissions correspond to particular app operations. Only the platform and OEMs can define special permissions. Additionally, the platform and OEMs usually define special permissions when they want to protect access to particularly powerful actions, such as drawing over other apps.

The Special app access page in system settings contains a set of user-toggleable operations. Many of these operations are implemented as special permissions.

Each special permission has its own implementation details. The instructions for using each special permission appear on the permissions API reference page. The system assigns the "appop" protection level to special permissions.

Permission groups

If several permissions relate to a similar capability or feature of an app or device, the system might represent these permissions as a permissions group. These permission groups help the system minimize the number of system dialogs that are presented to the user when an app requests closely-related permissions.

View an app's permissions

To view the set of permissions that an app declares, complete the steps in one of the following sections.

Device or emulator

To use a device or emulator to view the set of permissions that an app declares, complete the following steps:

  1. Open an app's App info screen.
  2. Select Permissions. The App permissions screen loads.

    If an app has declared at least one permission from a given permission group, that permission group appears on this screen.

Command line

To use the command line to view the set of permissions that an app declares, run the following command:

adb shell pm list permissions -s

The command output shows a set of permission groups. If an app has declared at least one permission from a given permission group, that permission group appears in the output.

All Permissions:

Network communication: view Wi-Fi state, create Bluetooth connections, full
internet access, view network state

Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone numbers


Restrict how other apps can interact with your app

Permissions aren't only for requesting system functionality. Your app's system components can restrict which other apps can interact with your app, as described on the page about how to restrict interactions with other apps.

Automatic grants of new permissions

Over time, new restrictions may be added to the platform such that, in order to use certain APIs, your app must request a permission that it previously did not need. Because existing apps assume access to those APIs is freely available, Android may apply the new permission request to the app's manifest to avoid breaking the app on the new platform version (thereby, enabling your app to inherit the permission). Android makes the decision as to whether an app might need the permission based on the value provided for the targetSdkVersion attribute. If the value is lower than the version in which the permission was added, then Android adds the permission.

For example, the READ_EXTERNAL_STORAGE permission is enforced beginning with API level 19 to restrict access to the shared storage space. If your targetSdkVersion is 18 or lower, this permission is added to your app on newer versions of Android.

Caution: If a permission is automatically added to your app, your app listing on Google Play lists these additional permissions even though your app might not actually require them. To avoid this and remove the default permissions you don't need, always update your targetSdkVersion to be as high as possible. You can see which permissions were added with each release on the Versions pages.

Additional resources

  • Permissions that imply feature requirements: Information about how requesting some permissions implicitly restricts your app to devices that include the corresponding hardware or software feature.
  • <uses-permission>: API reference for the manifest tag that declares your app's required permissions.
  • Device compatibility: Information about how Android works on different types of devices and an introduction to how you can optimize your app for each device or restrict your app's availability to different devices.
  • Android security overview: A detailed discussion about the Android platform's security model.