Android contact picker: Play deadline moves to 27 Jan 2027

Google Play's contacts deadline is no longer 28 October 2026. The help page that announced it now says 27 January 2027, with a 30-day automatic self extension in Play Console, and it only applies to apps targeting API level 37. If you ship React Native or Flutter on Android, the android contact picker is still the work to start now: Play Console pre-review checks that flag contacts and location issues begin on 27 October. By the end of this post you will know which date applies to you, what the picker changes in code, and which cross-platform libraries actually support it.

The key dates, as of 25 October 2026

Date	What happens	Source
15 April 2026	Contacts and location policies announced	Android Developers Blog
September 2026	Play Console prompts apps carrying READ_CONTACTS to declare or remove it	Play Console Help
27 October 2026	Pre-review checks start flagging contacts and location issues	Android Developers Blog
November 2026	Precise location declaration becomes available	Play Console Help
27 January 2027	Contacts and location compliance mandatory for apps targeting API 37+	Policy deadlines table

How 28 October became 27 January

The Wayback Machine shows the change happening in steps. The 16 April 2026 capture of the contacts help page reads "October 28, 2026: Policy compliance is mandatory for all apps that target Android 17 or later (API level 37+)." By the 23 August capture that line said "January 2027", with "30 day automatic extensions" added. The 2 October capture pins it to "January 27, 2027" and a "30-day automatic self extension".

Some secondary coverage never caught up. A stora.sh post from 24 April still calls 28 October "the hard one", and treats a 30-day window ending around 15 May as a soft horizon. Neither date appears on Google's current pages. If your compliance plan was built from a blog post in the spring, check it against the policy deadlines table, which lists the contacts and location changes against 27 January 2027.

The strongest argument for waiting is real: nothing is enforced until January, and only for apps targeting API 37. But the pre-review checks run from 27 October whatever the enforcement date, and the declaration asks your team to explain, in writing, why the picker is not enough. That answer takes longer to agree than the code takes to write.

Does the policy apply if you target API 36?

No, not yet. Google's help page says compliance is mandatory for apps that target Android 17 or later (API level 37+). Play's current requirement is that new apps and updates target API level 36 from 31 August 2026, with extensions to 1 November 2026, which we covered in our target API level 36 deadline post. That page does not yet give a date for API 37, so we won't guess one.

The catch is that the target bump and this policy will land together. When your team moves to API 37, the READ_CONTACTS declaration and the location rules arrive in the same release, so planning the picker migration now keeps it out of that critical path.

What the android contact picker changes in code

The new picker is launched with ContactsPickerSessionContract.ACTION_PICK_CONTACTS and returns a Session URI. Google's Contact Picker guide (updated 16 October 2026) says that URI "grants temporary read access to the selected data", and the cursor follows the ContactsContract.Data schema. This is the documented multi-select sample, trimmed:

val pickContactIntent = Intent(ACTION_PICK_CONTACTS).apply {
    putExtra(EXTRA_USE_SYSTEM_CONTACTS_PICKER, true)
    putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
    putStringArrayListExtra(
        EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS,
        arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
    )
    putExtra(EXTRA_PICK_CONTACTS_MATCH_ALL_DATA_FIELDS, false)
}
pickContact.launch(pickContactIntent)

Three details from the guide matter in review. Session URIs reject custom selection and selectionArgs and throw if you pass them. Access is temporary, so you have to persist what you need before the process dies. And account metadata is stripped from results to prevent fingerprinting.

Does the contact picker work below Android 17?

No. Google's FAQ says the Android Contact Picker is not backported to previous versions. For apps targeting Android 17, the system automatically upgrades the existing Intent.ACTION_PICK to the new interface. On older devices, the classic ACTION_PICK still grants temporary read access to the picked item, but Android's common intents guide warns that reading phone numbers or emails from a whole-contact pick generally needs READ_CONTACTS. To try the new UI before you retarget, the picker guide says you can add EXTRA_USE_SYSTEM_CONTACTS_PICKER to an ACTION_PICK intent on an Android 17 device.

Android contact picker in React Native and Flutter

This is where cross-platform teams get caught, because the native module decides what your app asks for. We checked the libraries we would normally reach for when building React Native apps and Flutter apps.

Library	Android behaviour we found	Verdict
expo-contacts (SDK 58)	Picker launches Intent.ACTION_PICK with Contacts.CONTENT_TYPE, then loads the contact by ID	No documented Android 17 support
react-native-contacts	README requires READ_CONTACTS; no picker without it	Not a picker migration path
system_contact_picker 0.0.4 (Flutter)	System picker and Session URI on Android 17; legacy ACTION_PICK on API 28-36, no contacts permission declared	Supports the new picker

For React Native we found no library that documents ACTION_PICK_CONTACTS support. The expo-contacts Android source launches ACTION_PICK, which Android 17 will upgrade, then reads the contact back by ID; the Expo docs still tell bare projects to add READ_CONTACTS and WRITE_CONTACTS. We have not tested that path on an Android 17 device, so treat it as unverified. The react-native-contacts README asks for READ_CONTACTS outright. Until that changes, a small native module wrapping the Kotlin above is the honest answer.

Flutter is further along. system_contact_picker uses the system picker on Android 17, supports 1 to 100 selections, and falls back to single-contact ACTION_PICK on older versions. It is at version 0.0.4 with 513 downloads on pub.dev, so pin it and read the source before relying on it.

Do you need to remove READ_CONTACTS?

Yes, unless contacts are core to your app. Google's April post says apps using contacts for sharing or inviting should remove READ_CONTACTS entirely if targeting Android 17. The help page lists uses that do not qualify: sharing files, collaborating, inviting or referring someone, or choosing a contact to transact with. A custom contact picker does not qualify either.

Permitted uses include contact management, dialling or SMS, call history, CRM, call screening, accessibility, backup and restore. If yours is one, the Play Console declaration asks two questions: which user-facing features need READ_CONTACTS, and why the Contact Picker is not sufficient. Plan the write side as well: a 21 October 2026 post says apps targeting the next Android release will lose direct writes under WRITE_CONTACTS, with standard insert and edit intents as the replacement.

The location button rule arrives on the same day

Location follows the same timeline. The location button help page sets compliance for 27 January 2027, with 30-day self extensions, and says the button grants precise location "for a single session only". If your app uses precise location only for one-off actions such as finding a store, the location button guide shows the manifest change:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton" />
<uses-permission android:name="android.permission.USE_LOCATION_BUTTON" />

The button ships in Jetpack core-locationbutton 1.0.0-alpha01, which the guide calls experimental; on Android 16 and lower it falls back to the standard permission prompt. Apps that need persistent precise location, such as live tracking, file a declaration explaining why coarse location or the button is not enough instead.

If your app targets API 37 next year, run the pre-review checks on your next build after 27 October and treat every contacts or location flag as a ticket. If you want a second pair of eyes on the migration, our mobile app development team works in React Native, Expo and Flutter.