As part of [improving app quality](https://android-developers.googleblog.com/2022/10/raising-bar-on-technical-quality-on-google-play.html) and protecting user privacy, we recommend you minimize the permissions usage in your apps. This helps users discover and use high-quality apps that provide a safe and secure user environment. Requesting permissions from users interrupts the user flow, and users can deny your request. In addition, each time you declare a new permission, you must [review how your app requests and shares user data](https://developer.android.com/guide/topics/data/collect-share). Some [particularly sensitive permissions and APIs](https://support.google.com/googleplay/android-developer/answer/9888170) require you to provide in-app disclosure of your data access, collection, use, and sharing. There are multiple alternative ways to minimize permission usage: - Use lower fidelity alternatives for user data permission access where applicable, such as requesting coarse location data instead of precise when it is unnecessary. - Use pickers and permission alternatives which grant access to sensitive permissions in scoped circumstances such as the [photo picker](https://developer.android.com/training/data-storage/shared/photo-picker), [contact picker](https://developer.android.com/about/versions/17/features/contact-picker), and [location button](https://developer.android.com/guide/topics/permissions/private-alternatives/location-button) - Call APIs which allow your app to perform the chosen functionality without declaring permissions. - Invoke specific intents or event handlers to perform functionality, instead of declaring permissions. - The system provides [built-in contracts](https://developer.android.com/reference/androidx/activity/result/contract/ActivityResultContracts) for different file operations and also supports [custom contracts](https://developer.android.com/training/basics/intents/result#custom). If you must declare a permission, always [respect the user's decision](https://developer.android.com/training/permissions/requesting#handle-denial) 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. Each location use case has its own unique set of requirements for precision and length of access, with most only needing a rough approximation of the user's whereabouts. If you're implementing functionality in your app that depends on user location, consider the following options to help you select the right access approach. - If your app functionality requires precise location, but only at a given moment during app usage such as "Search near me" or auto filling an address for ecommerce, using the [location button](https://developer.android.com/guide/topics/permissions/private-alternatives/location-button) is likely the best option for you to reduce both user friction and reliance on the broader scope permission. - If your app frequently needs location, declare the [`ACCESS_COARSE_LOCATION`](https://developer.android.com/reference/android/Manifest.permission#ACCESS_COARSE_LOCATION) permission. The permission provides a device location estimate from location services, as described in the documentation about [approximate location accuracy](https://developer.android.com/training/location/permissions#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 may 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`](https://developer.android.com/reference/android/Manifest.permission#ACCESS_FINE_LOCATION) permission. > [!NOTE] > **Note:** Even if your app functionality requires precise location, it is important to recognize that users may refuse to grant access or only grant coarse location permission, so be sure to consider how best to gracefully degrade the app experience in those scenarios. ## Create and access files Android lets you create and access files without needing to declare any permissions related to storage or sensors. ### 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](https://developer.android.com/training/data-storage/shared/photopicker). 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: - If you access media files that your app created, your app already has access to these files in the [media store](https://developer.android.com/training/data-storage/shared/media#media_store). - If you access media files that other apps created, [use the Storage Access Framework](https://developer.android.com/training/data-storage/shared/documents-files). ### 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`](https://developer.android.com/reference/android/Manifest.permission#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: - If the user created the document in your app, [access it directly](https://developer.android.com/training/data-storage/app-specific#external-access-files). - If the user created the document in another app, use the [Storage Access Framework](https://developer.android.com/training/data-storage/shared/documents-files). ### 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`](https://developer.android.com/reference/android/provider/MediaStore#ACTION_IMAGE_CAPTURE) intent action. > [!NOTE] > **Note:** If your app declares Manifest.permission.CAMERA permission and is not granted, then the action results in a `SecurityException`. ### 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`](https://developer.android.com/reference/android/provider/MediaStore#ACTION_VIDEO_CAPTURE) intent action. > [!NOTE] > **Note:** If your app declares Manifest.permission.CAMERA permission and is not granted, then the action results in a `SecurityException`. ## 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](https://developers.google.com/instance-id/guides/android-implementation) library. - Create your own identifier that's scoped to your app's storage. Use basic system functions, such as [`randomUUID()`](https://developer.android.com/reference/java/util/UUID#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](https://developer.android.com/guide/topics/connectivity/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](https://developers.google.com/pay/payment-card-recognition/debit-credit-card-recognition) library. ## 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](https://developers.google.com/identity/sms-retriever/overview). > [!NOTE] > **Note:** The SMS Retriever API will not work in situations where your app doesn't control the format of the SMS message used for authentication. In this case, use the [SMS User Consent API](https://developers.google.com/identity/sms-retriever/user-consent/overview) to streamline SMS verification by allowing the app to prompt the user to grant access to the content of only a single SMS message. On other devices, if your app targets Android 8.0 (API level 26) or higher, generate an app-specific token using [`createAppSpecificSmsToken()`](https://developer.android.com/reference/android/telephony/SmsManager#createAppSpecificSmsToken(android.app.PendingIntent)). Pass this token to another app or service that can send a verification SMS message. ### Verify a user's phone number In order to allow your app to securely verify a user's phone number, the recommended solution is the [Digital Credentials API](https://developer.android.com/identity/digital-credentials/phone-number-verification). Using this API either directly, or through a wide range of compatible aggregators, lets you reliably verify user account information without requesting sensitive device permissions. For a Firebase solution, see [Firebase Phone Number Verification](https://firebase.google.com/docs/phone-number-verification). Alternatively, you can verify a user's phone number using a one-time passcode, using the [SMS Retriever API](https://developers.google.com/identity/sms-retriever/overview). ### 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](https://developers.google.com/identity/phone-number-hint/android) 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`](https://developer.android.com/reference/android/telecom/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`](https://developer.android.com/reference/android/content/Intent#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. ## 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()`](https://developer.android.com/reference/android/media/AudioManager.OnAudioFocusChangeListener#onAudioFocusChange(int)) event handler, which runs automatically when the system shifts its audio focus. Learn more about how to [implement audio focus](https://developer.android.com/guide/topics/media-apps/audio-focus). ## Scan barcodes Android includes support for the [Google Code Scanner API](https://developers.google.com/ml-kit/vision/barcode-scanning/code-scanner), powered by Google Play services, which lets you decode barcodes without declaring any camera permissions. This API helps preserve user privacy and makes it less likely that you need to create a custom UI for your barcode-scanning use case. The API scans the barcode and only returns the scan results to your app. Images are processed on-device, and Google doesn't store any data or scan results. If your app needs to support complex use cases or barcode formats, or if it requires a custom UI, use the [ML Kit barcode scanning API](https://developers.google.com/ml-kit/vision/barcode-scanning/android) instead. ## Reset unused permissions Android provides multiple ways to reset unused runtime permissions to their default, denied state. Read [design guidance](https://developer.android.com/training/permissions/requesting#reset-unused-permissions). ## Request runtime permissions Once you've evaluated that your app needs to declare and request runtime permissions, follow a specific workflow to do so. Read [design guidance](https://developer.android.com/training/permissions/requesting#workflow_for_requesting_permissions). ## Explain why your app needs permissions Using `requestPermissions()` displays a dialog indicating which permissions your app wants to use but doesn't explain why, which might be puzzling to the user. For more details and recommendations on how and when to show this dialog, read [design guidance](https://developer.android.com/training/permissions/requesting#explain). ## Handle permission denials Your app should help users understand the implications of denying a permission before and after they choose to do so. Read [design guidance](https://developer.android.com/training/permissions/requesting#handle-denial).