Android is locking down the address book. Here is what to change.

Google Play requires a declaration for broad contacts access from 27 January 2027, and direct contact writes end in 2027. Most apps should move to the system picker now.

Google is moving Android contacts behind system screens. On 21 October 2026 it announced that apps targeting the next Android release, due in 2027, will lose the ability to write to the address book with WRITE_CONTACTS. That comes on top of a Google Play policy that already limits reading: from 27 January 2027, apps that target Android 17 and still request READ_CONTACTS need an approved Play Console declaration.

If your app invites friends, splits a bill, saves a contact from a chat or scans a business card, this is about you. Most apps can drop both permissions and end up with a cleaner flow. The catch is that Google sets the clock, not your roadmap.

What changed, and what is already in force

There are two separate moves. The first is Google Play's Contacts Permissions policy, announced on 15 April 2026. It is published and has an enforcement date: compliance is mandatory from 27 January 2027 for apps targeting Android 17 (API level 37) or later, with a 30-day self-extension in Play Console. Since September 2026, Play Console has been asking apps that carry READ_CONTACTS to file a declaration or remove the permission.

The second is a platform change that is announced but not shipped. Apps targeting the 2027 Android release will get a SecurityException or a permission denial when they write contacts directly. A new special access permission, MANAGE_CONTACTS, arrives in Android 17 QPR2 in Q4 2026 for the few apps that need bulk access, and Play will ask those apps for a declaration no earlier than that 2027 release. These are Android and Google Play rules, so they apply in every market, not only the EU or the US.

Who has to change

Google is direct about what does not qualify. Apps that read contacts only to share files, collaborate, invite or refer someone, or pick a person to pay should typically not request READ_CONTACTS. Having your own contact-picking screen is not a reason to keep it.

What can qualify, if you explain why the picker falls short: contact managers, dialers, call screening, CRMs, accessibility tools, backup and restore, keyboards with autocomplete, friend matching, and AI personal assistants that need deep contact access to act on commands. If you are building an assistant, that last item is good news, but expect to justify it in writing.

Why waiting does not work

Both rules apply once your app targets the new Android version, which can sound optional. It is not. Play requires new apps and updates to target a recent API level, and that bar moved from Android 15 in 2025 to Android 16 on 31 August 2026. Sooner or later a routine release raises your target, and a contact feature that worked last sprint starts failing in production.

What a product team has to change

• Reading: replace READ_CONTACTS with the Contact Picker (ACTION_PICK_CONTACTS). Users choose specific people and fields, and your app gets temporary read access to only those. Save what you need straight away, because the access expires.
• Writing: replace direct inserts with ACTION_INSERT, ACTION_EDIT or ACTION_INSERT_OR_EDIT. The system shows a standard editor and needs no permission. Custom data types are silently dropped, so check what you pass.
• Calling and messaging: stop writing call or message actions into the address book and publish them through People Directory, which also arrives in Q4 2026.
• Data: if your backend stores uploaded address books, decide what it still needs when users share only the people they pick. Fewer stored contacts also means less data about people who never signed up.
• Release planning: the picker exists only on Android 17 and later. Apps that already use ACTION_PICK get it automatically once they target Android 17, but test older devices as well.

Apple went the same way earlier. Since iOS 18, people can give an app access to a limited set of contacts, and Apple provides ContactAccessButton and a contact access picker to add more. If you ship on both platforms, design one flow around choosing the people you need, not asking for everything.

If contacts are a feature rather than the product, plan to give up broad access.

When broad access is still worth asking for

If your growth depends on friend matching, or you sync contacts with a CRM in the background, the declaration route is open. Write the justification before Play asks: which feature, why the picker cannot do it, and what you store. We would still build the picker path first, so the feature keeps working if the review goes against you or a user says no. This is platform policy rather than law, but if contact data is central to your business model, have counsel check how you describe it to users.

What to do this week

• Search the code and the merged manifest for READ_CONTACTS, WRITE_CONTACTS and ContactsContract.RawContacts.CONTENT_URI, since a third-party SDK can add a permission you never wrote.
• Open Play Console and check for a pending contacts declaration.
• List every contact feature and mark it as picker, intent, or genuine broad access.
• Ship the migration in the same release that raises your target to Android 17, not after it.

For most products the replacement APIs are small. The real risk is finding out about this change from a crash report instead of a sprint plan.