Skip to main content
Blog
android

Google Play just quietly rewired contacts access. You have about three weeks.

Google's April 15 Play policy update changes how Android apps request contacts, location, and account transfers. Here's what indie devs need to do now.

Carlton Aikins3 min read

Last week Google updated the Play Store developer policies in a way that's going to quietly break apps shipping for years. No headline change. No new API to learn. But ignore it and your next update will start bouncing.

What actually changed#

On April 15, Google rolled out four policy updates at once. The two that matter most for indie devs:

Contacts Permissions. READ_CONTACTS is now a restricted permission. If your app doesn't genuinely need the whole contact list, you're expected to use the Android Contact Picker — the system UI that lets a user pick one contact without handing over their entire address book. If you target Android 17 (API 37+), this is mandatory on October 28, 2026. Declare or delete.

Location Permissions. Same pattern. Google is pushing the "location button" as the minimum scope for precise location. If you just need a one-shot "where am I right now" — a check-in, a pin drop, a delivery address — you don't need full foreground location anymore. Use the button. Less scary in the dialog, fewer review headaches.

There's also an Account Transfer change (after May 27, transfers must go through the official Play Console workflow) and clarifications around Health Connect data types including new restricted categories.

Why this matters if you're shipping#

Here's the uncomfortable part. A lot of indie Android apps have READ_CONTACTS sitting in their manifest from a feature they built in 2019. An "invite a friend" flow. A contact suggestion picker in a messaging app. A one-time phone number lookup.

That permission still works. It still gets granted. And it's now a liability.

If a reviewer notices your app requests the full contact list and all you do with it is show a "who do you want to share this with?" sheet, you are on the wrong side of this policy. The fix is usually mechanical — swap your custom picker for ACTION_PICK with ContactsContract.Contacts.CONTENT_URI, delete the permission from your manifest, and move on. But you have to actually look.

The 30-day window on the announcement (ending around May 15) is the soft compliance horizon. The hard one — when targeting Android 17 forces your hand — is October 28. If you ship often, the soft window is the one to plan around.

The Stora angle#

This is exactly the kind of thing Stora's compliance engine is built to catch. When you run a submission through Stora, it scans your manifest and your privacy declarations and flags permissions that look over-scoped for the features you've described in your listing. If you declare READ_CONTACTS but your app description says "share your receipts with a friend," that's a Contact Picker migration waiting to happen, and the engine will say so before you hit upload.

It'll also flag the location permission case — foreground precise location declared on an app whose only location touchpoint is "tag this note with a place" is exactly the pattern Google is pushing you off of.

Do this now#

Open your manifest. Look at every dangerous permission. Ask: does my app actually need the full dataset, or would a system picker do? If the picker works, make the swap. Submit the leaner version. Sleep better.

The policies that get you rejected aren't the dramatic ones. They're the ones that quietly become true six months after you last looked.