Your app asks for every contact so people can invite one friend. Google Play wants that changed by January 27

The date and what it covers

On January 27, 2027, Google Play's Contacts Permissions policy becomes mandatory for apps that target Android 17, API level 37, or higher. Google announced the policy on April 15, 2026, and Play Console has been asking developers to declare how they use contacts since September. If you need more time, Play offers a 30-day extension you can request yourself.

The rule is simple to state. Broad access to a person's contacts, through the READ_CONTACTS permission, is now for apps whose core purpose needs it. Everyone else should use the Android Contact Picker, which lets the person choose specific contacts to share with your app.

Google's policy names the everyday features that typically shouldn't request broad access: inviting friends, referrals, sharing something with a contact, and choosing a contact to send money to or transact with. That covers a lot of apps. Most apps don't need the address book. They need one name, chosen by the person holding the phone.

Who has to act

Open your app's manifest and search for READ_CONTACTS. If it isn't there, you're done with this policy.

If it is, ask what the permission actually powers. Be honest about it, because the declaration in Play Console will ask the same question.

Invite a friend, refer someone, share a link. Switch to the picker.

Pick who to pay or split a bill with. Switch to the picker. The person chooses the contact, and your app gets only that one.

Find friends who already use the app. This is a declared use case where broad access can still be justified, but you'll need to explain it, and you should ask whether a smaller version, like matching only contacts the person picks, would do.

Your app is a contact manager, dialer or CRM. Broad access is the point. Declare it accurately and keep your privacy policy in line with what you do.

Don't stop at your own code. Analytics, attribution, support chat and social login libraries sometimes add permissions through their own manifests, and the merged manifest in your build is what Play sees. Check the final merged version, not just the file your team edits, and ask each SDK vendor what it does with contacts if it requests them.

Nobody remembers why it's there. This is more common than you'd think, often left over from a feature that no longer exists or an SDK that wanted it. Remove it, test, and enjoy one fewer permission prompt. If removing it breaks something, you've just found the feature you forgot, and you can decide properly which path it needs.

Counting back from January 27

Here's an illustrative plan for a small team, counting back from the deadline.

Now, late October. Find every place the app reads contacts, including third-party SDKs. Write down what each one is for.

Early November. Decide, feature by feature: picker, declaration or removal. Agree the user-facing wording for any new prompts.

Mid November to early December. Build the picker path, plus the fallback for older Android versions. Update your privacy policy and Play's data safety form if what you collect changes.

December. Test on Android 17 and on older versions. Submit the update and the Play Console declaration with time to spare, since reviews and holidays both slow things down.

January 27, 2027. The policy is mandatory. If you're not ready, request the 30-day extension before then, not after.

The catch: older phones

The new Contact Picker is an Android 17 feature, and it isn't available on older versions. Many of your users won't be on Android 17 for a long time.

So you need two paths. On Android 17 and later, use the picker. On older versions, the safest option for invites and sharing is usually not to read contacts at all: let people share a link through the standard share sheet, type a phone number, or use the older single-contact picking that hands your app one contact the person selects. Decide this with your developer now. The fallback is often more work than the picker itself.

Think about the moment the person meets the change, too. Someone who used to see their whole contact list inside your app will now see the system picker instead. A short line of text before it opens, such as "choose who you'd like to invite," prevents confusion and a few support emails. Test the wording with two or three people who use the feature today.

Whatever you build, keep the experience the same in spirit. The person chooses who to share with, and your app never sees the rest.

Why this is good for your app anyway

Asking for the whole address book has always cost something. People hesitate at that permission prompt, some deny it, and some uninstall. Data you don't collect is data you don't have to protect, explain in a privacy policy or disclose after a breach.

The picker also makes the invite flow more honest. Instead of a screen full of contacts with checkboxes pre-ticked, the person picks who they actually want to invite. It also means your app holds no copy of people who never agreed to be in it. That tends to produce invitations people are glad to receive, which is better for your app than a mass message that gets reported as spam.

There's an iOS parallel too. Apple has offered limited contact access since iOS 18, so if you're changing the Android flow, it's a good moment to check that your iPhone app asks for no more than it needs.

Put this into practice

This week, search your Android code for READ_CONTACTS and list every feature that uses it. Mark each one: picker, declare or remove. Book the build work for November, so December can be testing and submission. Ask your developer for a short written note of what changed, so the next person who touches the manifest knows why the permission is gone. Put January 27 on the team calendar with a reminder two weeks earlier to decide whether you need the extension.

If you'd like help auditing your app's permissions or rebuilding an invite or payment flow around the picker, that's the work our mobile applications team does. Talk to us.

Related work: Spin Market.