Skip to main content
Stora LogoStora
Start free
Blog
Google Play

Google Play's Contacts Picker Deadline Is 24 Days Out — Here's the Fix

Google Play's new contacts permissions policy kicks in May 15, 2026. If you still request READ_CONTACTS, you're about to get flagged. Here's what to do.

Carlton Aikins3 min read

Google just quietly reset the clock on one of the most widely (and lazily) requested permissions in Android: READ_CONTACTS. The new Contacts Permissions policy was announced April 15, and the enforcement window is 30 days. That puts the real deadline at May 15, 2026 — three and a half weeks away.

If your app asks for full contacts access because the invite flow used to need it, you're now the kind of app Play Integrity is looking for.

what actually changed#

Under the new policy, apps can only request broad READ_CONTACTS access if they have a legitimate, ongoing reason — a CRM, a communication app, a contact-sync service — and they have to justify it through a Play Developer Declaration. Everything else has to migrate to the Android Contact Picker, which shows a system-provided UI, returns only what the user taps, and requires no runtime permission.

Two notes. When targeting Android 17 with the picker, you're supposed to remove READ_CONTACTS from your manifest entirely — not just stop calling it. Apps that declare it without a justified use case will still get flagged. And this is a review-time check: enforcement can include removal from Play, not just a warning.

why indie devs should care more than the enterprise crowd#

Big consumer apps have legal teams that read the Play Console emails. Indie apps are where this quietly ships broken.

Common failure pattern: you built an "invite a friend" flow eighteen months ago, pulled a snippet that asks for READ_CONTACTS, and forgot about it. The feature is load-bearing for activation but barely maintained. Your next update rolls through review, gets auto-flagged, and Tuesday's bug fix is sitting in a rejection queue. The fix is small — ~20 lines with ActivityResultContracts.PickContact — but you have to actually do it before the deadline bites.

the migration, short version#

Swap this:

kotlin
// old: broad permission + manual ContentResolver query
if (ContextCompat.checkSelfPermission(this, READ_CONTACTS) != PERMISSION_GRANTED) {
    requestPermissions(arrayOf(READ_CONTACTS), REQ_CODE)
}

For this:

kotlin
// new: no permission, picker returns one contact URI
val picker = registerForActivityResult(ActivityResultContracts.PickContact()) { uri ->
    uri?.let { readOneContact(it) }
}
picker.launch(null)

Then delete <uses-permission android:name="android.permission.READ_CONTACTS" /> from your manifest when you're targeting Android 17. If you need multiple contacts (invite flows), loop the picker. If you need the whole address book, file a declaration — and be ready to explain why.

the stora angle#

This is exactly the kind of silent policy change that Stora's compliance engine catches before you hit upload. When you wire a build through Stora, we parse your manifest, cross-reference it against the current Play and App Store policy set, and flag the risky permissions before the reviewer does. The contacts policy is already in the rule set. So are the location-button requirements and the account-transfer workflow rules that shipped in the same April 15 announcement.

The whole point is not paying tax on knowing the policies. You ship, we check.

the takeaway#

May 15 is real. Calendar it, migrate the invite flow, and pull READ_CONTACTS out of your manifest if you don't have a story for why it's there. Your future self, reading a Play Console rejection email at 11pm before a launch, will thank you.