Key points:
- Android’s own Contact Picker page confirms a standardized picker interface, live on Android 17 (API level 37) and higher, as a privacy-preserving alternative to READ_CONTACTS.
- Apps don’t need to declare or request READ_CONTACTS in the manifest at all when using the Contact Picker, per Android’s own page.
- Reporting describes Play Console now prompting a declaration form this month for apps that still request READ_CONTACTS, asking why the picker isn’t enough. Not independently confirmed on an official Play Console Help page for this piece, since that page is unreachable from here.
- Reported enforcement dates for full compliance vary across sources. Check your own Play Console’s Policy Deadlines page for your app’s real date.
A permission that used to be a simple checkbox now needs a written reason. Android’s own page confirms the technical fix exists. Reporting says Play Console already asks developers to justify skipping it.
What Android’s own page confirms
Android’s own Contact Picker page is direct about how it works. On Android 17 (API level 37) or higher, apps get a standard, browsable picker. A user picks specific contacts. The app only sees the fields it asked for. Phone number or email. Nothing more. No full address book. And no manifest line for READ_CONTACTS at all, if the picker covers your use case.
| Question | What’s confirmed | What’s reported, not confirmed here |
|---|---|---|
| Does the Contact Picker exist? | Yes, Android’s own page | n/a |
| Minimum OS for it? | Android 17, API level 37 | n/a |
| Play Console declaration prompt live now? | n/a | Yes, per multiple outlets |
| Full enforcement deadline | n/a | Reported dates vary by source |
Why the declaration step is the part to plan for
Reporting describes something Android’s own page doesn’t cover. A Play Console declaration form. Apps that still request READ_CONTACTS reportedly get asked to explain, in real detail, which feature needs it. And why the picker can’t do the job instead. That’s a real process step. Not just a policy line to read once and forget.
The exact enforcement date is where sources disagree. One report ties it to an October deadline, linked to Android 17 targeting rules. Another names a January 2027 compliance date. Rather than guess and risk being wrong for your app, check your own Play Console’s Policy Deadlines page directly.
Real-world scenario: A messaging app’s team had used READ_CONTACTS for years. It let users find friends already on the app. They treated it as a fixed, settled part of their manifest. Reading Android’s own Contact Picker page showed the picker could cover this exact case. A user picks who to invite. The app never sees the full address book. They rebuilt the friend-finder flow around the picker instead. When their own Play Console later prompted a declaration for the old permission, they had already removed the need for it. Nothing left to justify.
What to actually do about it
- Check your own Play Console for a declaration prompt. Reporting says this is already showing up for apps with READ_CONTACTS. Don’t wait to spot it by accident.
- Test whether the Contact Picker actually covers your feature. Android’s own page lists real capabilities: search, profile switching, multi-selection. Many “we need the whole address book” assumptions fall apart under an actual test.
- Check your own Policy Deadlines page for your exact date. Reported enforcement dates conflict across outside sources. Only your own Play Console has the real number for your app.
- Don’t treat a manifest permission as fixed forever. A feature built around broad access years ago may not need it today. Not with a real picker now available.
AppRankr’s Rank Tracker tracks your real Google Play visibility. A permissions policy shift doesn’t move your rank on its own. But a rejected update over an undeclared permission can stall everything else you’re tracking.