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.
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.
Frequently asked questions
In what cases can the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions be accessed?
What kinds of apps would need "broad access to photos?"
What if I have a custom photo picking experience, does that qualify for access to these permissions?
Are there any exceptions to this policy?
Will my app need to remove the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions from my app manifest?
Why opt for a "picker" experience?
How easy is it to integrate the photo picker into my app?
What versions of Android is the photo picker compatible with?
Must I use the Android photo picker or can my app use other picker integrations?
What if a user does not grant my app broad access to media files?
Contacts Permission
In April 2026, we introduced our new Contacts Permission 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 27, 2027: Policy compliance is mandatory for all apps that target Android 17 or later (API level 37+). 30-day automatic self extension 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_CONTACTS 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.).Manage Contacts Permission
In October 2026, we introduced our new MANAGE_CONTACTS policy that governs the permissible use of the MANAGE_CONTACTS permission. Apps may only request the MANAGE_CONTACTS permission if the available platform intents for creating and modifying contact data do not suffice for your app's core functionality. Contacts are personal and sensitive data subject to the Google Play User Data policy.
Timeline
- October 29, 2026: We announced the
MANAGE_CONTACTSpolicy. - Summer 2027: Developers with apps that need
MANAGE_CONTACTSpermission are prompted in Play Console to submit a declaration form to qualify for core functionality access or utilize available platform intents for their needs.- Action item: Consult your teams to understand if your app requires the
MANAGE_CONTACTSpermission for core functionality purposes and if so, be prepared to explain why the platform intents are not sufficient from a technical standpoint.
- Action item: Consult your teams to understand if your app requires the
- August 2027: Policy compliance is mandatory for all apps. 30 day automatic extensions will be available in Console. After this date, all apps in scope are subject to enforcement if not compliant.
Frequently asked questions
What are common use cases for the new MANAGE_CONTACTS permission?
My app only needs to create or edit a single contact (for example, adding a contact from a chat thread). What should I do?
You will need to transition to platform intents instead of requesting direct Write permissions. You should use:
ACTION_INSERTto prompt the user to create a new contactACTION_EDITto modify an existing contactACTION_INSERT_OR_EDITfor hybrid workflows
These platform intents launch a standardized, highly reliable system editor where the user remains in control to review and confirm the change. If applicable, apps can pre-fill contact fields such as (name, phone number, etc) for easy creation.
Does my app still need to request READ_CONTACTS if it gets the new MANAGE_CONTACTS permission?
MANAGE_CONTACTS permission is a high-level special app access that covers full programmatic read, write, and deletion capabilities. If your app qualifies for MANAGE_CONTACTS, you only need to declare and request this single permission.Are there any exceptions to this policy?
Can I still use the WRITE_CONTACTS permission?
WRITE_CONTACTS no longer grants the ability to create, modify, or delete contacts. The system won't show the permission request dialog. Attempts to write to the Contacts Provider will throw a SecurityException. Your app should handle this exception rather than assume a write succeeded.What if I already have a custom contact creation/editing interface, does that qualify my app for MANAGE_CONTACTS permission?
Local Network Permission
In October 2026, we introduced our new Local Network Permission policy that governs the permissible use of the ACCESS_LOCAL_NETWORK permission. Apps that target Android 17 or higher (API level 37+) may only request the ACCESS_LOCAL_NETWORK permission if it is necessary for their core functionality and if device pickers (like NsdManager) are not sufficient to provide core functionality.
Timeline
- October 29, 2026: We announced the Local Network Permission policy.
- June 2027: Developers with apps that carry the
ACCESS_LOCAL_NETWORKpermission will be prompted in Play Console to submit a declaration form to qualify for core functionality access, or remove the permission and use a picker option for their needs.- Action item: Consult your teams to understand if your app requires the
ACCESS_LOCAL_NETWORKpermission for core functionality purposes and, if so, be prepared to explain why a device picker is not sufficient from a technical standpoint.
- Action item: Consult your teams to understand if your app requires the
- August 25, 2027: Policy compliance will be mandatory for all apps that target Android 17 or higher (API level 37+). A 30-day automatic self-extension will be available in Play 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 ACCESS_LOCAL_NETWORK must complete a declaration in Play Console to demonstrate access needs and justify why a device picker is insufficient.
The declaration will require you to answer the following questions:
- Which user-facing features in your app require the
ACCESS_LOCAL_NETWORKpermission? (If your use case is non-user-facing or not listed in the following table, select Other).
|
Use Case |
Description |
Examples (not exhaustive) |
|
|
1 |
Peer-to-peer (P2P) interaction |
Used for direct data exchange or communication between devices on a local network. |
Local multiplayer gaming, device-to-device file transfer. |
|
2 |
Smart device and IoT control |
Used to discover, configure, and control smart devices connected to a local network. |
Smart home hubs, connected appliances, lighting controls, printing service plugin. |
|
3 |
Network infrastructure and diagnostics |
Used to configure network hardware, map network topology, or troubleshoot local network connectivity. |
Router or mesh Wi-Fi setup apps, Wi-Fi analyzers, network diagnostic tools. |
|
4 |
Media casting |
Used for user-initiated streaming or media casting to local network devices |
Wireless speakers, smart TVs. |
| Other |
|||
- Explain why a device picker is not sufficient and you still need broad access through
ACCESS_LOCAL_NETWORK.
Frequently Asked Questions
What are common use cases where the ACCESS_LOCAL_NETWORK permission is utilized?
ACCESS_LOCAL_NETWORK permission include control of IoT devices such as smart light bulbs, or apps that require peer-to-peer connections to function as needed.Are there any exceptions to this policy?
Will the INTERNET permission still be available for use?
Yes, the INTERNET permission is still available and allows applications to open network sockets. For apps targeting Android 16 and lower, the INTERNET permission will continue to provide access to the local network.
Which device picker should I use for general device and service discovery?
What versions of Android is the NsdManager device picker compatible with?
NsdManager device picker is available on all devices running Android 13 or higher (API level 33+) with up-to-date Google Play system updates. For media casting, are there any voluntary, opt-in alternatives to requesting the ACCESS_LOCAL_NETWORK permission?
ACCESS_LOCAL_NETWORK permission, but using the System Output Switcher is not required.