Google Play's policy deadline table is easy to ignore until a review rejection lands. One date should be on every Android product calendar right now: January 27, 2027 . On that day, four related changes hit together — Contacts Permissions, Location Permissions, SMS/call-log use cases, and geofencing as a foreground-service justification. Announced April 15 and July 15, 2026, they are not surprises. They are a forced product redesign for any app that still treats broad contacts or continuous precise location as defaults.
Contacts: prefer the Contact Picker over broad access
Play is introducing a Contacts Permissions policy that governs broad access to users' contacts. Apps that do not need broad access must use the Android Contact Picker — a more secure, easier-to-integrate alternative that minimizes data collection. For most B2B flows (invite a teammate, CC a manager, pick a site contact), you never needed READ_CONTACTS . You needed one or two selections. Rebuild those flows around the picker now, and document any remaining broad-access case with a real product justification your Play Console declaration can defend.
Location: location button as the recommended minimum for precise location
Play is updating Location Permissions so the location button is the recommended minimum scope for precise location, aligned with user-data and sensitive-permissions requirements. Product implication: stop asking for continuous precise location at first launch for features that only need a one-shot pin. Prefer approximate location where it works, escalate to precise only when the user taps an in-context location control, and explain why before the system dialog. Field-service and logistics apps can still justify background or frequent location — but the UX and declaration must match the actual need.
Same-day companions: SMS/call-log and geofencing FGS
Also on January 27, 2027: SMS and call-log. Account verification via phone call is no longer a permitted use case for READ_CALL_LOG . Use the Digital Credentials API (directly or through a provider built on it) or the SMS Retriever API instead. Geofencing foreground services. Geofencing is removed as an approved foreground-service use case. Developers should use the Geofence API for that workload instead of stretching an FGS declaration. These look like separate policies. Operationally they are one permissions cleanup program: reduce sensitive grants, prefer platform pickers and purpose-built APIs, and rewrite Play declarations to match the code.
A twelve-week engineering checklist
1. Permission inventory. Export every dangerous permission from the merged manifest and map each to a screen. Kill dead grants. 2. Contacts rewrite. Replace multi-select contact sync with Contact Picker for invite and share flows. If you sync a directory, prove why and gate it behind a clear enterprise setting. 3. Location UX. Add an in-product location button for precise needs; default to approximate or deferred prompts. 4. Verification. Migrate call-log based verification to Digital Credentials or SMS Retriever. 5. Geofencing. Move geofence monitoring off FGS justifications onto the Geofence API and update Play Console declarations. 6. Store listing and Data safety. Align Data safety answers, permission declarations, and in-app copy before you submit the deadline build.
// Prefer Contact Picker for invite flows (conceptual)
val pickContact = rememberLauncherForActivityResult(
ActivityResultContracts.PickContact()
) { uri -> /* resolve display name + optional email only */ }
fun onInviteTeammate() {
// Do NOT request READ_CONTACTS for this path
pickContact.launch(null)
}
// Precise location only after an in-context location button
fun onUsePreciseLocationClick() {
// show rationale -> request ACCESS_FINE_LOCATION once
}Why B2B apps get caught
Enterprise apps often inherit consumer permission patterns: sync the whole address book "for convenience," keep precise location always on "for dispatch," and leave old verification SDKs in place. Play reviewers do not care that your users are employees. They care that the declared use cases match policy. January 27, 2027 is far enough to do this calmly in two release trains — and close enough that waiting until December is how you scramble.
Founder takeaway
Put January 27, 2027 on the roadmap: Contact Picker by default, location button for precise location, no call-log verification, and Geofence API instead of geofencing-as-FGS. Align code, UX copy, and Play declarations together. Teams that treat this as a policy footnote will learn about it from a rejected update when sales already promised a January feature.
Design and legal partners you need in the room
Permissions redesigns fail when engineering changes the manifest alone. Product design must rewrite empty states and button labels so the Contact Picker and location button feel intentional. Legal and privacy need to refresh Play Data safety answers and privacy policy language so they match the new collection surface. QA needs device-matrix tests for denied permissions, partial grants, and Android version differences. For B2B apps distributed through managed Play or MDM, confirm whether enterprise policies already grant contacts or location. A managed configuration can hide a policy violation until a consumer-track build is reviewed. Test both distribution paths.
Build a "permissions scoreboard" in your issue tracker: each dangerous permission, owning squad, replacement API, target release, and Play declaration status. Review it weekly until January 27, 2027. Deadlines like this slip when they live only in a blog bookmark.
Operationally, treat this topic as a named owner problem: someone updates the runbook, someone verifies the deadline or launch assumptions against primary sources, and someone reports status in the weekly product meeting. Ambiguity is what turns a manageable change into a scramble. Write down the decision, the date you will re-check sources, and the customer-facing language you will use if asked before the next milestone.
