Minimize your permission requests

Stay organized with collections Save and categorize content based on your preferences.

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 might deny the permission or even uninstall your app.

In addition, each time you declare a new permission, you must review how your app requests and shares user data. Some particularly sensitive permissions and APIs require you to provide in-app disclosure of your data access, collection, use, and sharing.

Consider whether you need the permission in the first place, or if the there is an alternative way to support the functionality in your app. The system provides built-in contracts for different file operations and also supports custom contracts.

If you must declare a permission, always respect the user's decision and provide a way to gracefully degrade your app's experience.

This page 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 only require a rough estimate of a device's location. In these situations, do one of the following, depending on how often your app needs location-aware information:

  • If your app frequently needs location, declare the ACCESS_COARSE_LOCATION permission. The permission provides a device location estimate from location services, as described in the documentation about approximate location accuracy.
  • If your app needs location less often, or only once, consider asking the user to enter an address or a postal code instead.

Other use cases require a more precise estimate of a device's location. Those situations are the only times when it's OK to declare the ACCESS_FINE_LOCATION permission.

Create and access files

Android lets you create and access files without needing to declare any permissions related to storage or sensors.

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 media files

Your app might allow users to choose from their photos and videos, such as for message attachments or profile pictures.

To support this functionality, use the photo picker. The photo picker doesn't require any runtime permissions to use. When a user interacts with the photo picker to select photos or videos to share with your app, the system grants temporary read access to the URI associated with the selected media files.

If your app needs to access media files without using the photo picker, you don't need to declare any storage permissions:

Open documents

Your app might show documents that the user created, either in your app or in another app. A common example is a text file.

In this situation, declare the READ_EXTERNAL_STORAGE only for compatibility with older devices. Set the android:maxSdkVersion to 28.

Depending on which app created the document, do one of the following:

Identify the device that's 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, you can't 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.

Automatically enter a payment card number

Google Play services offers a library that lets you automatically enter a payment card number. Instead of declaring the CAMERA permission, you can use the debit and credit card recognition library.

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.

Manage phone calls and text messages

Android and Google Play services offer libraries that let you manage phone calls and text messages without needing to declare any permissions related to phone calls or SMS messages.

Enter a one-time passcode automatically

To streamline a two-factor authentication workflow, your app might automatically enter the one-time passcode that is sent to a user's device to verify their identity.

To support this functionality on devices powered by Google Play services, don't declare the READ_SMS permission. Instead, use the SMS Retriever API.

On other devices, if your app targets Android 8.0 (API level 26) or higher, generate an app-specific token using createAppSpecificSmsToken(). Pass this token to another app or service that can send a verification SMS message.

Enter the user's phone number automatically

To provide more efficient sales or support, your app might allow the user to enter their device's phone number automatically.

To support this functionality on devices powered by Google Play services, don't declare the READ_PHONE_STATE permission. Instead, use the Phone Number Hint library.

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.

Place phone calls

Your app might offer the ability to place a phone call by tapping a contact's information.

To support this functionality, use the ACTION_DIAL intent action rather than the ACTION_CALL action. ACTION_CALL requires the install-time permission CALL_PHONE, which prevents devices that can't place calls, such as some tablets, from installing your application.

Previous
About permissions
Next
Declare app permissions