Google Play Contacts Permissions in 2026: A Step-by-Step Tutorial to Migrate to the Contact Picker

On April 15, 2026, Google Play announced a new Contacts Permissions policy. The Policy Deadlines table lists it under Permissions and APIs that Access Sensitive Information, with deadline 2027-01-27. The published sentence is short: apps that do not need broad access must use the Android Contact Picker. If you still ship READ_CONTACTS on a build that targets Android 17 (API 37) or later, Play expects a Console declaration that explains why the picker is not enough — or you remove the permission before enforcement. KappS is writing this as a Console and policy walkthrough, not as a substitute for the live Help pages.

What you are solving today: decide whether the product truly needs the entire address book. If it does not, migrate to the Contact Picker, drop READ_CONTACTS, and clear the Play Console prompt. If the picker cannot serve core functionality, prepare the Contacts declaration — which user-facing features need broad access, and why the picker is insufficient — before 2027-01-27. Recheck current Play Console Help for the exact form labels and any later notes — this tutorial only restates what those Help pages publish.

What Play published (deadline, scope, announcement)

Three official pages say the same thing in different lengths:

The Policy Deadlines row dated 2027-01-27: “We're introducing the Contacts Permissions policy to govern broad access of users' contacts. Apps that don't need broad access must use the Android Contact Picker, a more secure, easy-to-integrate alternative that minimizes data collection and improves user safety. Announced 2026-04-15.”
The April 15, 2026 policy announcement uses the same wording and points you back to Policy Deadlines. Play said you would have at least 30 days from that date to start updating — the enforcement date on the table is still January 27, 2027.
Permissions and APIs that Access Sensitive Information repeats the new policy and marks it effective January 27, 2027. The preview of the updated article adds the Android 17 rule: apps that target Android 17 or later (API 37+) may only request READ_CONTACTS if the Contact Picker is not sufficient for core functionality, and they must submit a Play Console declaration.

Understanding Restricted Permissions with minimum scope alternatives publishes the working timeline:

April 15, 2026 — policy announced.
September 2026 — developers whose apps carry READ_CONTACTS are prompted in Play Console to submit a declaration (qualify for core-functionality access) or remove the permission and use the Contact Picker. Help’s action item: ask the team whether the permission is required for core functionality, and if so, be ready to explain why the minimum-scope picker is not technically sufficient.
January 27, 2027 — compliance is mandatory for apps that target Android 17 or later (API 37+). A 30-day automatic self extension will be available in Console. After that date, in-scope apps that are not compliant are subject to enforcement.

All user contacts are personal and sensitive data under the User Data policy. The preview policy also says apps may not disclose or publish non-public contacts data unless authorized by the individual data subjects — the contacts themselves, not only the device owner.

Step 1 — Decide whether you need READ_CONTACTS

Do not start in Console. Start with the product. Help’s test is whether the Android Contact Picker is sufficient for core functionality. If the user can pick one or a few contacts and hand you a name, phone, or email, that is a picker job — not an address-book permission.

Use cases Help lists as typically not permitted for READ_CONTACTS:

Sharing a file with someone
Collaborating
Inviting or referring someone to join a service
Choosing a contact to transact with

Use cases Help lists as common reasons the permission is still used (you still have to justify them):

Contact management apps (showing, editing, or organizing all contacts)
Accessibility features that must interact with the contact list
Server-side friend matching / “who of my contacts is already on this platform”
Backing up contacts, or backing up / restoring user data to another device
Auto-correct / auto-complete (keyboards that need all contact names)
Dialing or SMS UI, call history, call screening, CRM notes across all contacts, personal-assistant commands that need the contacts database

Two published limits matter before you keep the permission:

A custom contact-picking UI does not qualify. Help’s FAQ: a custom picker “does not qualify as a reason to retain Contacts access.”
Private and enterprise device-management apps are exempt from this policy requirement. That exception is written for those app types — not for a consumer invite button.

Walk the real binary, not the store listing copy:

Does the feature need every contact, or a user-chosen subset?
Is the access ongoing (sync, backup, matching, call screening), or transactional (share, invite, pick a recipient)?
If the user refuses READ_CONTACTS, can the same feature continue through the picker or manual entry? Restricted Permissions policy already requires a reasonable effort to accommodate users who decline.
Is the feature promoted on the Play listing? Sensitive-permissions policy says you may only request access that is necessary for current, promoted features — not for unimplemented or undisclosed ones.

If the honest answer is “we only need the contacts the user picks,” stop here and migrate. Keeping READ_CONTACTS for convenience will not pass the declaration’s second question.

Step 2 — Migrate to the Android Contact Picker

Play’s restricted-permissions Help and the Android Contact Picker docs describe the same tool. The picker is a system UI: the user browses contacts, your app asks only for the fields it needs (phone, email, postal), and you receive read access to the selected data — not the whole address book.

Published integration facts (do not invent extra APIs):

Play Help says to launch the picker with Intent.ACTION_PICK_CONTACTS. Android’s feature page names the same action as ContactsPickerSessionContract.ACTION_PICK_CONTACTS.
Unlike legacy ACTION_PICK, the new picker lets you request multiple data fields at once (Play Help). Android documents this as extras such as EXTRA_REQUESTED_DATA_FIELDS / EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, using MIME types from ContactsContract.CommonDataKinds (phone, email, structured postal).
The picker is not backported. It exists on Android 17 (API 37) or later. For apps that target Android 17+, the system automatically upgrades existing Intent.ACTION_PICK to the new UI. Help still recommends switching to ACTION_PICK_CONTACTS for multi-field selection, work-profile switching, and the rest of the new extras.
You can test the new UI on an Android 17 device even if the app still targets a lower SDK, by adding the boolean extra EXTRA_USE_SYSTEM_CONTACTS_PICKER to ACTION_PICK (Android docs).
On success the system returns RESULT_OK and a Session URI with temporary read access. Android’s best-practice line: persist the data immediately if you need it after the process dies. Do not treat the session URI as a durable handle on the address book.
Request only the fields you need. If you only send SMS, request the phone MIME type so the picker can hide contacts that have no number.

Then remove READ_CONTACTS from the manifest (and from any leftover library merge) on the Android 17+ target. Shipping the picker and keeping the permission is the opposite of what Help asks for invite/share/pick-a-recipient flows.

If you already use ACTION_PICK, targeting 17+ gets you the new UI without a rewrite. Update to ACTION_PICK_CONTACTS when you need the session URI, work/personal profile switching, or multi-field extras. That is the published compatibility path — not a KappS-invented shortcut.

Step 3 — Update Play Console declarations

Two Help articles describe Console work. Use the labels that appear in your account; do not invent a second “Contacts” toggle if Console does not show one.

Contacts-specific prompt (Restricted Permissions Help). In September 2026, apps that still carry READ_CONTACTS are prompted in Play Console to submit a declaration or to remove the permission and use the Contact Picker. Help says that declaration will ask:

Which user-facing features require READ_CONTACTS? Pick from the published use-case list (contact management, dialing or SMS, call history, CRM, call screening, accessibility, personal assistants, friend matching/search, backup and restore, auto-correct/auto-complete, user-initiated device contact selection, or Other). If the feature is not user-facing or not listed, Help says to select Other.
Explain why the Contact Picker is not sufficient and why you still need broad access via READ_CONTACTS.

Selecting “user-initiated device contact selection” (invite, share, block one person) is Help’s example of a picker-shaped use case. That row is not a loophole for keeping the permission.

Permissions Declaration Form (Declare permissions Help). Permission requests are evaluated during the release process after you add an Android App Bundle. If the bundle requests high-risk or sensitive permissions and Play does not already have a declaration, Console shows the Permissions Declaration Form. Official points, without extra buttons:

If an active bundle (including Open, Closed, or Internal testing) still needs a declaration, an alert appears on the left menu under App content. You cannot publish app changes — including Store listing, pricing, and distribution — until you create a release that includes a declaration or removes the permissions.
On the App content page, the form’s expandable list shows previously declared permissions (checkmark) and newly requested ones (alert). If a newly requested permission is not supposed to be in the declaration, Help says to remove that bundle and upload one with the correct permission set before you continue.
Specify core functionality from the supported use cases, provide review instructions if needed, a video demonstration (YouTube preferred), and — if signed-in functionality is restricted — test credentials that are not production user accounts. Confirm the declaration checkboxes, then finish preparing and rolling out the release.
After you complete the form and roll out, Play runs an extended review that “may require up to several weeks.” A rejected request is emailed to the account owner and the contact email. If you must ship urgently, Help’s path is to remove the sensitive permissions and roll out a new release for standard policy review.

If Console only shows the Contacts prompt described in the restricted-permissions article, answer those two questions. If it shows the full Permissions Declaration Form on App content, follow that form and the Declare permissions article. This page does not invent a third screen.

Publishing API users: Help says a release that requests undeclared high-risk or sensitive permissions returns an error. Complete the form in the Play Console web UI once; after approval you can use the API again. Any new permission requires a revised form in the UI.

Step 4 — What fails review or gets the app enforced

Play publishes outcomes. Do not substitute folklore:

Picker would have been enough. Invite, share, collaborate, or “pick a recipient” while still holding READ_CONTACTS is the example Help calls not permissible. A custom in-app picker does not save that declaration.
No declaration on an Android 17+ READ_CONTACTS build. After January 27, 2027, in-scope apps that are not compliant are subject to enforcement. Help also publishes a 30-day automatic self extension in Console — an extension is not a permanent exception.
App content alert ignored. Declare permissions Help: you cannot publish listing or release changes until you address an active Permissions Declaration alert, including unused test tracks that still carry the permission. Deactivate unused Open / Closed / Internal tracks that are not compliant.
Sensitive data used off-purpose. Contacts are User Data. Restricted Permissions require you to honor a denial, avoid forcing consent for a non-critical permission, and keep a reasonable alternative. Sensitive-permissions policy forbids selling that data or using it for undisclosed features.
Non-public contacts published without the contact’s authorization. The preview policy states that rule separately from the picker migration.

If Console shows a new Contacts questionnaire after you read this, follow the live Help article linked from that form. This page does not invent extra buttons, extra API levels, or extra dates beyond 2026-04-15 (announced), September 2026 (Console prompt), and 2027-01-27 (Policy Deadlines / mandatory for Android 17+).

A 10-minute checklist

List every feature that reads contacts. Mark each one picker-shaped (invite, share, pick a recipient) or broad-access (manage all contacts, backup, friend matching, call screening, accessibility, keyboard).
If every feature is picker-shaped, implement ACTION_PICK_CONTACTS, persist the Session URI results immediately, and remove READ_CONTACTS from the Android 17+ manifest.
If a feature truly needs the whole book, write the technical reason the picker cannot do that job — before anyone opens Console.
Open Play Console. If September’s prompt or an App content alert is waiting, complete the published declaration or upload a bundle that no longer requests the permission.
Deactivate unused test tracks that still request READ_CONTACTS without a declaration.
Confirm the store listing only promotes features that match the access you still request.
Re-read current Policy Deadlines and Restricted Permissions Help before you rely on the 30-day self extension.

The one-line version

If the app targets Android 17+ and does not need the entire address book, Play’s Contacts Permissions policy — announced April 15, 2026, deadline 2027-01-27 — requires the Android Contact Picker instead of READ_CONTACTS; keep broad access only when you can declare a published core use case and explain why the picker is not enough.