Android 17's New Contacts & Location Rules Land Today

Google's Android Developers Blog laid the groundwork for this back in April, but October 28, 2026 is the date the two biggest pieces actually took effect: the stricter Contacts Permissions policy and the new location-button requirement, both confirmed independently by Android Authority's coverage of the rollout. For apps targeting Android 17 (API level 37) or later, broad READ_CONTACTS access is no longer the default move — Google Play now requires that the Android Contact Picker be the first option, and any app that still needs full contacts access has to file a Play Console declaration naming the specific feature and explaining why the picker cannot cover it. The companion change applies the same logic to location: one-time precise-location requests for things like "find the nearest store" now have to route through Android 17's dedicated location button rather than a standard system permission dialog, unless the app can justify persistent, always-on access instead.

Neither change is cosmetic, and neither is optional busywork for a later sprint. Enforcement for apps targeting Android 17 is scheduled for January 27, 2027, with Google offering a 30-day automatic grace extension in Play Console — which sounds generous until a team realizes that picker migration, declaration paperwork, and re-testing every permission-gated flow is not a one-afternoon fix once an app has years of accumulated contact-sync or location-tagging features bolted onto it. Teams that treat this as "we'll deal with it closer to January" are the ones who end up filing a rushed, under-documented Play Console declaration the week before the deadline — exactly the kind of submission Google's review process is built to flag and bounce back.

Why this is bigger than a permissions dialog swap

The Contact Picker and the location button are both designed to remove an app's ability to see data it never needed in the first place — the picker hands back only the contact the user selected, not the whole address book; the location button returns one GPS fix, not a standing subscription to the user's movements. That is a real architectural change for any feature built assuming broad access: "find friends already using this app," "tag this photo with where it was taken," or "auto-fill delivery address" all need to be re-implemented against a narrower data contract, not just re-skinned with a new permission prompt. Getting that redesign right — and getting the Play Console declaration right for the handful of features that legitimately still need broader access — is exactly the kind of platform-level work that benefits from a team that has shipped against Google's shifting permission model before, which is why bringing in a dedicated Android development team for the migration tends to be faster than having a generalist mobile squad learn the new contract live against a January deadline.

What to check this week, not next quarter

The practical order of operations: first, inventory every place the app currently requests READ_CONTACTS or ad-hoc fine-location access and classify each as picker-replaceable or genuinely persistent. Second, for anything picker-replaceable, scope the UI and data-flow changes — this is usually smaller than teams fear, since the picker is a drop-in system component rather than a custom build. Third, for the handful of flows that need to keep broad access, draft the Play Console declaration now, with a specific feature name and a concrete reason the picker or the location button falls short, rather than a generic justification that invites a second review round.

• Audit every READ_CONTACTS and fine-location call site before scoping anything — most apps have more of these than the product team remembers.
• Budget real QA time: permission-flow regressions are easy to miss because the "happy path" test accounts often already granted access under the old model.
• File Play Console declarations for genuinely persistent-access features early; a rejected declaration close to the January 27, 2027 enforcement date leaves no runway to appeal.
• Treat the 30-day grace extension as a buffer for the unexpected, not as the default timeline — build to be done well before it.

A permission policy change is rarely just a permission policy change. It is a forced audit of every assumption a feature made about the data it was allowed to see.