--- description: Google Play's new Contacts Permissions policy takes effect January 27, 2027. Learn how to pick contacts in a Capacitor app without READ_CONTACTS. title: Google Play Contacts Policy 2027 for Capacitor - Capawesome image: https://capawesome.io/docs/assets/images/social/blog/capacitor-google-play-contacts-policy-2027.png --- [Skip to content ](#google-play-contacts-policy-2027-for-capacitor) [📲 Introducing **Build Sharing** — get your builds onto testers' devices with a link & QR code. No account required. ](/blog/share-mobile-app-builds-with-testers/) * [ SDKs ](/docs/sdks/) * [ Formbricks ](/docs/sdks/capacitor/formbricks/) * [ Geocoder ](/docs/sdks/capacitor/geocoder/) * [ Google Sign-In ](/docs/sdks/capacitor/google-sign-in/) * [ Grafana Faro ](/docs/sdks/capacitor/grafana-faro/) * [ Gyroscope ](/docs/sdks/capacitor/gyroscope/) * [ Haptics ](/docs/sdks/capacitor/haptics/) * [ Home Indicator ](/docs/sdks/capacitor/home-indicator/) * [ In-App Browser ](/docs/sdks/capacitor/in-app-browser/) * [ Install Referrer ](/docs/sdks/capacitor/install-referrer/) * [ Intercom ](/docs/sdks/capacitor/intercom/) * [ Intune ](/docs/sdks/capacitor/intune/) * [ Keep Awake ](/docs/sdks/capacitor/keep-awake/) * [ libSQL ](/docs/sdks/capacitor/libsql/) * [ Light Sensor ](/docs/sdks/capacitor/light-sensor/) * [ Live Update ](/docs/sdks/capacitor/live-update/) * [ Localization ](/docs/sdks/capacitor/localization/) * [ Mail Composer ](/docs/sdks/capacitor/mail-composer/) * [ Managed Configurations ](/docs/sdks/capacitor/managed-configurations/) * [ Maps Launcher ](/docs/sdks/capacitor/maps-launcher/) * [ Media Session ](/docs/sdks/capacitor/media-session/) * [ ML Kit ](/docs/sdks/capacitor/mlkit/) * [ Navigation Bar ](/docs/sdks/capacitor/navigation-bar/) * [ Network ](/docs/sdks/capacitor/network/) * [ NFC ](/docs/sdks/capacitor/nfc/) * [ Node.js ](/docs/sdks/capacitor/nodejs/) * [ OAuth ](/docs/sdks/capacitor/oauth/) * [ Passkeys ](/docs/sdks/capacitor/passkeys/) * [ Password Autofill ](/docs/sdks/capacitor/password-autofill/) * [ PDF Generator ](/docs/sdks/capacitor/pdf-generator/) * [ PDF Viewer ](/docs/sdks/capacitor/pdf-viewer/) * [ Pedometer ](/docs/sdks/capacitor/pedometer/) * [ Permissions ](/docs/sdks/capacitor/permissions/) * [ Phone Dialer ](/docs/sdks/capacitor/phone-dialer/) * [ Photo Editor ](/docs/sdks/capacitor/photo-editor/) * [ Photo Manipulator ](/docs/sdks/capacitor/photo-manipulator/) * [ PixLive ](/docs/sdks/capacitor/pixlive/) * [ PostHog ](/docs/sdks/capacitor/posthog/) * [ Printer ](/docs/sdks/capacitor/printer/) * [ Privacy Screen ](/docs/sdks/capacitor/privacy-screen/) * [ Proximity Sensor ](/docs/sdks/capacitor/proximity-sensor/) * [ Purchases ](/docs/sdks/capacitor/purchases/) * [ RealtimeKit ](/docs/sdks/capacitor/realtimekit/) * [ Root Detection ](/docs/sdks/capacitor/root-detection/) * [ Screen Brightness ](/docs/sdks/capacitor/screen-brightness/) * [ Screen Orientation ](/docs/sdks/capacitor/screen-orientation/) * [ Screen Reader ](/docs/sdks/capacitor/screen-reader/) * [ Screenshot ](/docs/sdks/capacitor/screenshot/) * [ Secure Preferences ](/docs/sdks/capacitor/secure-preferences/) * [ Settings Launcher ](/docs/sdks/capacitor/settings-launcher/) * [ Shake ](/docs/sdks/capacitor/shake/) * [ Silent Mode ](/docs/sdks/capacitor/silent-mode/) * [ SIM ](/docs/sdks/capacitor/sim/) * [ SMS Composer ](/docs/sdks/capacitor/sms-composer/) * [ Speech Recognition ](/docs/sdks/capacitor/speech-recognition/) * [ Speech Synthesis ](/docs/sdks/capacitor/speech-synthesis/) * [ Share Target ](/docs/sdks/capacitor/share-target/) * [ Square Mobile Payments ](/docs/sdks/capacitor/square-mobile-payments/) * [ SQLite ](/docs/sdks/capacitor/sqlite/) * [ Superwall ](/docs/sdks/capacitor/superwall/) * [ System WebView ](/docs/sdks/capacitor/system-webview/) * [ Tauri ](/docs/sdks/capacitor/tauri/) * [ Text Interaction ](/docs/sdks/capacitor/text-interaction/) * [ Text Zoom ](/docs/sdks/capacitor/text-zoom/) * [ Thermal State ](/docs/sdks/capacitor/thermal-state/) * [ Toast ](/docs/sdks/capacitor/toast/) * [ Torch ](/docs/sdks/capacitor/torch/) * [ Vault ](/docs/sdks/capacitor/vault/) * [ Volume ](/docs/sdks/capacitor/volume/) * [ Wallet ](/docs/sdks/capacitor/wallet/) * [ Wifi ](/docs/sdks/capacitor/wifi/) * [ YouTube Player ](/docs/sdks/capacitor/youtube-player/) * [ Zip ](/docs/sdks/capacitor/zip/) * [ Cordova ](/docs/sdks/cordova/) * [ Cloud ](/docs/cloud/) * [ Integrations ](/docs/cloud/live-updates/integrations/) * Concepts * Reference * [ Troubleshooting ](/docs/cloud/live-updates/troubleshooting/) * [ FAQ ](/docs/cloud/live-updates/faq/) * [ Native Builds ](/docs/cloud/native-builds/) * [ Set Up Environments ](/docs/cloud/native-builds/environments/) * [ Set Up Native Configurations ](/docs/cloud/native-builds/native-configurations/) * [ Auto-Increment Build Numbers ](/docs/cloud/native-builds/auto-incrementing-build-numbers/) * [ Configure the Web Build Script ](/docs/cloud/native-builds/web-build-script/) * [ Build from a Monorepo ](/docs/cloud/native-builds/monorepo/) * [ Use pnpm, Yarn, or bun ](/docs/cloud/native-builds/package-managers/) * [ Install Private npm Packages ](/docs/cloud/native-builds/npm-private-registry/) * [ Override the Java Version ](/docs/cloud/native-builds/override-java-version/) * [ Custom iOS Provisioning Profiles ](/docs/cloud/native-builds/custom-ios-provisioning-profiles/) * [ Build without Git ](/docs/cloud/native-builds/build-without-git/) * [ Access Git Behind a Firewall ](/docs/cloud/native-builds/firewall-access/) * [ Integrations ](/docs/cloud/native-builds/integrations/) * Reference * [ Troubleshooting ](/docs/cloud/native-builds/troubleshooting/) * [ FAQ ](/docs/cloud/native-builds/faq/) * [ App Store Publishing ](/docs/cloud/app-store-publishing/) * [ Submit a Build ](/docs/cloud/app-store-publishing/submit-a-build/) * [ Submit Automatically After a Build ](/docs/cloud/app-store-publishing/submit-automatically/) * [ Troubleshooting ](/docs/cloud/app-store-publishing/troubleshooting/) * [ FAQ ](/docs/cloud/app-store-publishing/faq/) * [ Automations ](/docs/cloud/automations/) * [ Reference ](/docs/cloud/automations/reference/) * [ Troubleshooting ](/docs/cloud/automations/troubleshooting/) * [ FAQ ](/docs/cloud/automations/faq/) * [ Assist ](/docs/cloud/assist/) * [ CLI ](/docs/cloud/cli/) * APIs and SDKs * [ Webhooks ](/docs/cloud/webhooks/) * [ Integrations ](/docs/cloud/integrations/) * Notifications * Account * [ Organization ](/docs/cloud/organizations/) * [ Two-Factor Enforcement ](/docs/cloud/organizations/two-factor-authentication/) * [ Network Restrictions ](/docs/cloud/organizations/network-restrictions/) * [ Audit Logs ](/docs/cloud/organizations/audit-logs/) * [ Billing ](/docs/cloud/organizations/billing/) * [ License Keys ](/docs/cloud/license-keys/) * [ AI ](/docs/ai/) * [ Insiders ](/docs/insiders/) * [ Billing & Plans ](/docs/insiders/billing-and-plans/) * [ FAQ ](/docs/insiders/faq/) * [ License ](https://capawesome.io/legal/eula/) * [ Support ](/docs/support/) * [ Contributing ](/docs/contributing/) * Contributing code * [ Code of Conduct ](/docs/contributing/code-of-conduct/) * [ Questions ](https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion#creating-a-discussion) * [ Blog ](/blog/) * Categories * [ Try Capawesome ](#try-capawesome) * [ Conclusion ](#conclusion) * Related links # Google Play Contacts Policy 2027 for Capacitor[¶](#google-play-contacts-policy-2027-for-capacitor "Permanent link") 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](/docs/sdks/capacitor/contacts/) that means passing the `property` option to [pickContacts(...)](/docs/sdks/capacitor/contacts/#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. [ ![Build and deploy your Capacitor app with Capawesome Cloud](https://capawesome.io/assets/banners/cloud-build-and-deploy-capacitor-apps.png?t=1) ](https://capawesome.io/) ## Key Takeaways[¶](#key-takeaways "Permanent link") * Google Play's [Contacts Permissions policy](https://support.google.com/googleplay/android-developer/answer/16926792) 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(...)](/docs/sdks/capacitor/contacts/#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(...)](/docs/sdks/capacitor/contacts/#pickcontacts) has never required a permission. ## What Does Google Play's Contacts Permissions Policy Require?[¶](#what-does-google-plays-contacts-permissions-policy-require "Permanent link") 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](https://support.google.com/googleplay/android-developer/answer/16926792) 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](https://support.google.com/googleplay/android-developer/answer/16935362) 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?[¶](#why-does-the-contact-picker-still-need-read%5Fcontacts "Permanent link") 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: `[](#%5F%5Fcodelineno-0-1)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[¶](#how-to-pick-a-contact-without-the-read%5Fcontacts-permission "Permanent link") Ask the picker for a single contact property instead of a whole contact. The `property` option of [pickContacts(...)](/docs/sdks/capacitor/contacts/#pickcontacts) launches the picker against the phone, email, or postal address table directly, so the user selects one specific value rather than a person: `[](#%5F%5Fcodelineno-1-1)import { ContactProperty, Contacts } from '@capawesome-team/capacitor-contacts'; [](#%5F%5Fcodelineno-1-2) [](#%5F%5Fcodelineno-1-3)const pickPhoneNumber = async () => { [](#%5F%5Fcodelineno-1-4) const { contacts } = await Contacts.pickContacts({ [](#%5F%5Fcodelineno-1-5) property: ContactProperty.PhoneNumber, [](#%5F%5Fcodelineno-1-6) }); [](#%5F%5Fcodelineno-1-7) [](#%5F%5Fcodelineno-1-8) return contacts[0]?.phoneNumbers?.[0]?.value; [](#%5F%5Fcodelineno-1-9)}; ` 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](/docs/sdks/capacitor/contacts/#installation) section in the plugin documentation. [ContactProperty](/docs/sdks/capacitor/contacts/#contactproperty) offers three values, matching the three data tables the system picker can target: | Value | Selects | Read from | | ----------------------------- | ----------------------- | --------------- | | ContactProperty.PhoneNumber | A single phone number | phoneNumbers | | ContactProperty.EmailAddress | A single email address | emailAddresses | | ContactProperty.PostalAddress | A single postal address | postalAddresses | The result is deliberately thin. You get the contact `id`, the new `displayName` property, and the property the user picked, and nothing else: `[](#%5F%5Fcodelineno-2-1)const { contacts } = await Contacts.pickContacts({ [](#%5F%5Fcodelineno-2-2) property: ContactProperty.EmailAddress, [](#%5F%5Fcodelineno-2-3)}); [](#%5F%5Fcodelineno-2-4) [](#%5F%5Fcodelineno-2-5)const contact = contacts[0]; [](#%5F%5Fcodelineno-2-6) [](#%5F%5Fcodelineno-2-7)console.log(contact.displayName); // 'John Doe' [](#%5F%5Fcodelineno-2-8)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?[¶](#what-changes-on-android-17 "Permanent link") 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(...)](/docs/sdks/capacitor/contacts/#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?[¶](#when-do-you-still-need-read%5Fcontacts "Permanent link") 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(...)](/docs/sdks/capacitor/contacts/#getcontacts) and [getContactById(...)](/docs/sdks/capacitor/contacts/#getcontactbyid), which read the address book directly. * [countContacts()](/docs/sdks/capacitor/contacts/#countcontacts), [getGroups()](/docs/sdks/capacitor/contacts/#getgroups), and [getAccounts()](/docs/sdks/capacitor/contacts/#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(...)](/docs/sdks/capacitor/contacts/#displaycreatecontact) hands the whole creation flow to the system UI, and on iOS [pickContacts(...)](/docs/sdks/capacitor/contacts/#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[¶](#how-to-migrate-your-capacitor-app "Permanent link") 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 your `AndroidManifest.xml`. Leave `WRITE_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[¶](#faq "Permanent link") ### When does Google Play's Contacts Permissions policy take effect?[¶](#when-does-google-plays-contacts-permissions-policy-take-effect "Permanent link") 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?[¶](#does-the-policy-apply-if-my-app-targets-android-16 "Permanent link") 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?[¶](#does-this-affect-my-app-on-ios "Permanent link") No. This is a Google Play policy and applies to Android only. On iOS, [pickContacts(...)](/docs/sdks/capacitor/contacts/#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?[¶](#can-i-still-read-a-full-contact-after-the-user-picks-one "Permanent link") 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?[¶](#what-happens-if-i-keep-read%5Fcontacts-without-filing-a-declaration "Permanent link") 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?[¶](#does-the-property-option-work-on-older-android-versions "Permanent link") 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. ## Try Capawesome[¶](#try-capawesome "Permanent link") Removing a permission is much easier before a deadline turns it into a release blocker. Subscribe below to get new Capacitor guides like this one as they are published. [Subscribe to the Capawesome Newsletter](https://capawesome.io/newsletter/) ## Conclusion[¶](#conclusion "Permanent link") 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](/blog/exploring-the-capacitor-contacts-api/). If you have questions, join the [Capawesome Discord server](https://discord.gg/VCXxSVjefW), and subscribe to the [Capawesome newsletter](https://capawesome.io/newsletter/) to stay up to date with new plugins and guides. August 13, 2026 Back to top ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Google Play Contacts Policy 2027 for Capacitor", "description": "Google Play\u0027s new Contacts Permissions policy takes effect January 27, 2027. Learn how to pick contacts in a Capacitor app without READ_CONTACTS.", "image": "https://capawesome.io/assets/banners/cloud-build-and-deploy-capacitor-apps.png", "datePublished": "2026-08-13T00:00:00+00:00", "dateModified": "2026-08-13T00:00:00+00:00", "author": [ { "@type": "Person", "name": "Robin Genz", "url": "https://github.com/robingenz" } ], "publisher": { "@type": "Organization", "name": "Capawesome", "url": "https://capawesome.io", "logo": { "@type": "ImageObject", "url": "https://capawesome.io/assets/images/logo.svg" } }, "articleSection": "Capacitor", "keywords": ["Capacitor", "Guides", "SDKs"], "isPartOf": { "@type": "Blog", "@id": "https://capawesome.io/blog/#blog" }, "mainEntityOfPage": "https://capawesome.io/blog/capacitor-google-play-contacts-policy-2027/", "url": "https://capawesome.io/blog/capacitor-google-play-contacts-policy-2027/" } { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://capawesome.io/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://capawesome.io/blog/" }, { "@type": "ListItem", "position": 3, "name": "Google Play Contacts Policy 2027 for Capacitor", "item": "https://capawesome.io/blog/capacitor-google-play-contacts-policy-2027/" } ] } {"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "What Does Google Play's Contacts Permissions Policy Require?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "Why Does the Contact Picker Still Need READ_CONTACTS?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "What Changes on Android 17?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "When Do You Still Need READ_CONTACTS?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "When does Google Play's Contacts Permissions policy take effect?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "Does the policy apply if my app targets Android 16?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "Does this affect my app on iOS?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "Can I still read a full contact after the user picks one?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "What happens if I keep READ_CONTACTS without filing a declaration?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}, {"@type": "Question", "name": "Does the property option work on older Android versions?", "acceptedAnswer": {"@type": "Answer", "text": "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."}}], "url": "https://capawesome.io/blog/capacitor-google-play-contacts-policy-2027/"} ```