System pickers and alternatives like Sharesheet are designed to support a privacy-oriented path for developers. Photos, Videos, Contacts, and other personal and sensitive data gated by restricted permissions should be treated with privacy best practices. Your app should only request and carry the sensitive permissions below if minimum scope alternatives are not sufficient to provide core app functionality.
Contacts Permission
In April 2026, we introduced our new Contact Permissions policy that governs the permissible use of the READ_CONTACTS permission. Apps that target Android 17 or later (API level 37+) may only request the READ_CONTACTS permission if the Android Contact Picker is not sufficient for your app to provide core functionality. We also provided guidance on the use of non-public contact data and reinforced that all Contacts are personal and sensitive data subject to the Google Play User Data policy.
Timeline
- April 15, 2026: We announced the Contacts Permission policy.
- September 2026: Developers with apps that carry
READ_CONTACTSpermission are prompted in Play Console to submit a declaration form to qualify for core functionality access or remove permission and utilize Contact Picker for their needs.- Action item: Consult your teams to understand if your app requires the
READ_CONTACTSpermission for core functionality purposes and if so, be prepared to explain why the minimum scope picker is not sufficient from a technical standpoint.
- Action item: Consult your teams to understand if your app requires the
- January 2027: Policy compliance is mandatory for all apps that target Android 17 or later (API level 37+). 30 day automatic extensions will be available in Console. After this date, all apps in scope are subject to enforcement if not compliant.
Declaration Guidance
All apps targeting Android 17 or higher and requesting READ_CONTACTS must complete a declaration in the Play Console to demonstrate access needs and justify why the Contact Picker is insufficient.
The declaration will require you to complete the following questions:
1. Which user-facing features in your app require READ_CONTACTS permission? (If your use case is non-user-facing or not listed below, select 'Other').
|
Use Case |
Description |
Examples (not exhaustive) |
|
Contact Management |
Used for managing all contacts. |
Showing all contacts, contact editing/organization, managing all contacts' birthdays |
|
Dialing or SMS sending |
Used to show users which contact they are calling or texting. |
Managing calls, displaying your contact list, and providing the user interface for the in-call screen |
|
Call History |
Used to show users all the calls they have received and which contact they belong to. |
Showing call history inside a dialer, or a parental control app that shows call history |
|
Customer Relationship Management (CRM) |
Functionalities that support businesses to keep track of business contact needs. |
Updating contact notes, or other contacts data for all contacts |
|
Call Screening |
Service designed to identify, block or filter incoming calls and SMS. |
Spam or call blocking that requires knowing all saved contacts |
|
Accessibility features |
Assistive tools that interact with contact lists to facilitate device usage for users with visual, auditory, or motor impairments. |
"Read aloud" features or "Call a specific contact" |
|
Personal Assistants |
AI-driven agents that require deep access to contacts databases for contextual user commands. |
"Send an email to" or "Call them at" |
|
Friend matching/search |
Used to facilitate social discovery by notifying the user which of their real-world contacts are already using the platform. |
Apps with social features, social discovery |
|
Backup and Restore/Connect to another device |
Used for the specific purpose of data preservation and enabling users to recover their contacts. |
Contact backup/restore, all user data backup/restore |
|
Auto-Correct/Auto-Complete |
Used for auto-correcting contact names or auto-completing names, email addresses or phone numbers. |
Keyboard autocorrect which needs to know all contact names, auto-completing by merging server side, and device contacts |
|
User-initiated device contact selection |
Explicitly used when a user initiates contacts selection. |
Referring/inviting a specific user, sharing a file with a specific user, blocking a specific contact on a gaming app |
|
Other |
||
2. Explain why Contacts Picker is not sufficient and you still need broad access via READ_CONTACTS.
Frequently asked questions
What are common use cases where the READ_CONTACTS permission is utilized?
READ_CONTACTS permission include friend finder/friend matching or lookup features, or apps that require a contact list to function as needed. Some examples of apps or features that typically would need access to contacts include:- Contact management apps
- Accessibility
- Server side access for friend matching
- Backing up contacts
- Auto complete/keyboards
What are common use cases where the READ_CONTACTS permission is not permissible
READ_CONTACTS permission for sharing files, collaborating, inviting/referring someone to join a service, choosing a contact to transact with, typically should not request the permission.What if I already have a custom contact picking experience, does that qualify for access to this permission?
Are there any exceptions to this policy?
Will the READ_CONTACT permission still be available for use?
How would I integrate the contact picker into my app?
Intent.ACTION_PICK_CONTACTS intent. This intent launches the picker and returns the selected contacts to your app. Unlike the legacy ACTION_PICK, the Contact Picker lets you specify multiple data fields your app requires at the same time. For details on how to launch Contact picker for your app, see Android Developer guidance here.What versions of Android is the contact picker compatible with?
Intent.ACTION_PICK intent to use the new Contact Picker interface. We recommend developers to use the Intent.ACTION_PICK_CONTACTS intent to benefit from the full capabilities offered by the new Contact Picker (multiple data types selection, work profile, etc.).Photo and Video Permissions
In October 2023, we introduced our new Photo and Video Permissions policy that governs the permissible use of the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions. Apps that target Android 13 or later (API level 33+) may only request the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions if system pickers (like the Android Photo Picker), are not sufficient for your app to provide core functionality. All user Photos are personal and sensitive data subject to the Google Play User Data policy.
Timeline
- May 28, 2025: Full policy compliance is mandatory for all developers, including those who requested an extension. After this date, all apps are subject to removal from Google Play if not compliant.