Google Play Contacts Policy 2027 for Capacitor

Google Play's new Contacts Permissions policy takes effect on January 27, 2027. Apps that target Android 17 (API level 37) or later may only declare READ_CONTACTS if the Android Contact Picker cannot cover their core functionality. If your Capacitor app only lets users pick a contact, you need to drop the permission, and with the Capacitor Contacts plugin that means passing the property option to pickContacts(...).

There is a catch that Google's announcement doesn't mention. Switching to the system contact picker does not by itself free you from READ_CONTACTS. Below Android 17, the picker hands your app an access grant so narrow that it contains no phone number, no email address, and no structured name (only a display name). This guide covers what the policy requires, why the picker alone falls short, and how to select a contact detail without ever asking for the permission.

Key Takeaways

• Google Play's Contacts Permissions policy was announced on April 15, 2026 and becomes effective on January 27, 2027.
• It applies to apps that target Android 17 (API level 37) or later. Those apps may only request READ_CONTACTS if the Android Contact Picker is not sufficient for their core functionality.
• Apps that still need broad access must submit a Play Console declaration naming the features that require it and explaining why the picker falls short.
• The contact picker grants read access to the picked contact URI only. That URI exposes no phone numbers, email addresses, or structured name, so reading contact details still requires READ_CONTACTS below Android 17.
• The property option of pickContacts(...) lets the user select a single phone number, email address, or postal address. It requires no permission on any Android version and is available since version 8.1.0 of the Capacitor Contacts plugin.
• On iOS, pickContacts(...) has never required a permission.

What Does Google Play's Contacts Permissions Policy Require?

The policy reserves READ_CONTACTS for apps that genuinely cannot work without the full address book. Google's wording is that apps which 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."

Three details decide whether this affects you:

• Who it applies to. Only apps that target Android 17 (API level 37) or later. Since Google Play raises the required target API level every year, that will be every actively maintained app soon enough.
• When it lands. Google announced the policy on April 15, 2026 and set the effective date to January 27, 2027. Pre-review checks in the Play Console start on October 27, 2026, so you will see warnings before enforcement begins.
• What the escape hatch costs. Apps that need ongoing access to the whole contact list keep it, but they have to file a Play Developer Declaration that names the user-facing feature and explains why the picker is technically insufficient. Automatic 30-day extensions are available through the Play Console.

A messaging app that syncs your address book to find friends has a case to make. A checkout screen that fills in a delivery address does not, and that second group is where most Capacitor apps sit.

Why Does the Contact Picker Still Need READ_CONTACTS?

Because the permission grant the picker returns is narrower than the data you asked for. When the user selects someone, the system grants your app read access to the picked contact URI, and that grant is exact: it covers that one URI and nothing below or beside it.

The problem is what lives at that URI. A row in the Contacts table holds an identifier and some metadata. It holds no phone numbers, no email addresses, and no structured name, because in Android's contacts model those live in the separate ContactsContract.Data table. Querying that table is a global read, and the grant does not extend to it. It does not extend to the contact's entities sub-directory either. Attempt it without the permission and the provider answers with a flat refusal:

Permission Denial: reading ContactsProvider2 uri content://com.android.contacts/contacts/1/entities requires android.permission.READ_CONTACTS

So "use the picker instead of the permission" is only half an instruction below Android 17. The picker gives you a contact you are allowed to identify but not allowed to read. There is no permission-free way to pull a whole contact record on those versions, which is why the plugin needs a different approach rather than a different intent.

How to Pick a Contact Without the READ_CONTACTS Permission

Ask the picker for a single contact property instead of a whole contact. The property option of pickContacts(...) launches the picker against the phone, email, or postal address table directly, so the user selects one specific value rather than a person:

import { ContactProperty, Contacts } from '@capawesome-team/capacitor-contacts';

const pickPhoneNumber = async () => {
  const { contacts } = await Contacts.pickContacts({
    property: ContactProperty.PhoneNumber,
  });

  return contacts[0]?.phoneNumbers?.[0]?.value;
};

This works because the picker now returns a data row URI, and the access it grants points at the row that actually holds the value. Your app reads it directly, on every Android version, without a permission in the manifest and without a runtime prompt. To install the Capacitor Contacts plugin, please refer to the Installation section in the plugin documentation.

ContactProperty offers three values, matching the three data tables the system picker can target:

The result is deliberately thin. You get the contact id, the new displayName property, and the property the user picked, and nothing else:

const { contacts } = await Contacts.pickContacts({
  property: ContactProperty.EmailAddress,
});

const contact = contacts[0];

console.log(contact.displayName); // 'John Doe'
console.log(contact.emailAddresses?.[0].value); // 'john.doe@example.com'

displayName is a read-only property added in version 8.1.0. It holds the formatted name the device itself shows for the contact, derived from CNContactFormatter on iOS and Data.DISPLAY_NAME on Android, and it is the only name the granted URIs expose. Setting it when creating or updating a contact has no effect, so keep using givenName and familyName for that.

Practically, this changes how you design the interaction. Instead of one "Choose a contact" button followed by a disambiguation dialog when someone has four phone numbers, you send the user straight into a picker that lists the numbers. Fewer taps for them, no permission prompt for you.

What Changes on Android 17?

Android 17 makes plain contact picking permission-free on its own. Apps targeting API level 37 get their ACTION_PICK intent automatically upgraded to the new system contact picker, which returns a picker session URI following the ContactsContract.Data schema. The plugin detects that URI and reads it directly, so a call to pickContacts(...) without the property option also stops needing READ_CONTACTS there.

That does not make the property option redundant. Your app still runs on Android 16 and below, where the old behavior applies, and you cannot ship a manifest that declares READ_CONTACTS on old devices but not on new ones. As long as you support anything below Android 17, the property option is what lets you leave the permission out entirely.

When Do You Still Need READ_CONTACTS?

Whenever your app reads the address book without the user pointing at a specific entry. Every method that queries contacts on its own terms falls in this group:

• getContacts(...) and getContactById(...), which read the address book directly.
• countContacts(), getGroups(), and getAccounts().
• Anything that syncs, backs up, or matches the full contact list against a server.

If your app does one of these as a core feature, the policy does not shut you out. Keep the permission and file the declaration. What the policy targets is the app that declares READ_CONTACTS to power a single "pick a friend" screen, and that app now has a cheaper option.

Two methods need no permission at all and are worth knowing about: displayCreateContact(...) hands the whole creation flow to the system UI, and on iOS pickContacts(...) has always run without one, because CNContactPickerViewController returns the selected contact to the app without touching the contacts entitlement.

How to Migrate Your Capacitor App

Work through it in this order:

1. Find every contacts call in your codebase. Search for Contacts. and sort the hits into two buckets: user-driven selection, and everything else.
2. Rewrite the selection calls. Replace pickContacts() with a property variant and adjust the code that consumes the result, since it now receives one value instead of a full contact object.
3. Decide about the rest. If the second bucket is empty, you are done and the permission can go. If it isn't, check whether those features are genuinely core to your app or leftovers you can drop.
4. Remove the permission. Delete `from yourAndroidManifest.xml. LeaveWRITE_CONTACTS` alone if you create or update contacts, as this policy does not cover it.
5. Test on a real device. Build with the permission removed and run every flow that touches contacts. A missing grant surfaces as a Permission Denial in Logcat, not as a friendly error, so watch the log while you click through.
6. File the declaration if you kept the permission. Do it before pre-review checks start on October 27, 2026 rather than in the week before the January deadline.

FAQ

When does Google Play's Contacts Permissions policy take effect?

January 27, 2027. Google announced it on April 15, 2026, and pre-review checks in the Play Console begin on October 27, 2026, which gives you roughly three months of warnings before enforcement. Automatic 30-day extensions can be requested through the Play Console.

Does the policy apply if my app targets Android 16?

Not yet. The policy covers apps that target Android 17 (API level 37) or later. Google Play raises the minimum target API level for updates every year, though, so an app that is still maintained will reach API 37 on its own schedule. Migrating early costs less than migrating under a deadline.

Does this affect my app on iOS?

No. This is a Google Play policy and applies to Android only. On iOS, pickContacts(...) never required the contacts permission, and the property option behaves the same way there, returning the id, the displayName, and the selected property.

Can I still read a full contact after the user picks one?

Only with READ_CONTACTS below Android 17. The picker's grant covers the picked contact URI, which carries no phone numbers, email addresses, or structured name, and reading those means querying the ContactsContract.Data table, which the grant does not cover. From Android 17 on, the upgraded system picker returns a data-schema URI that the plugin reads without the permission.

What happens if I keep READ_CONTACTS without filing a declaration?

Once the policy is effective, apps targeting Android 17 or later that declare the permission without an approved declaration are subject to enforcement, which in practice means your app updates get blocked in the Play Console. The declaration itself asks which user-facing features need the permission and why the Android Contact Picker is technically insufficient.

Does the property option work on older Android versions?

Yes. Picking against the phone, email, or postal address table is not an Android 17 feature. The picker returns a data row URI it grants access to on every supported Android version, which is exactly what makes the option a safe way to remove the permission from your manifest today.

Conclusion

The migration is smaller than the policy makes it sound. For most Capacitor apps it comes down to one option on one method call and one line deleted from the Android manifest. What takes the thinking is the audit: knowing which of your contacts calls are user-driven selection and which ones read the address book on their own, because only the second group needs a declaration.

For a full tour of the plugin's API, from permissions to accounts and groups, read Exploring the Capacitor Contacts API. If you have questions, join the Capawesome Discord server, and subscribe to the Capawesome newsletter to stay up to date with new plugins and guides.