<MT />
Back to Blog
Google PlayAndroidindie appsprivacyContact Pickerlocation buttonPlay Console

Google Play's January 27 Deadline: Contact Picker and Location Button Checklist for Indie Apps

T

Muhammad Tayyab

October 7, 2026·15 min read
Close-up of a hand holding a black Android smartphone — photo by Daniel Romero via Unsplash

Play's Contacts and Location policy updates hit January 27, 2027. Console pre-review flags start October 27. Decision guide, what to swap, and a rejection-week checklist for indie Android builders.

# Google Play's January 27 Deadline: Contact Picker and Location Button Checklist for Indie Apps

Google announced new Contacts Permissions rules and an updated Location Permissions policy on April 15, 2026. The live Policy Deadlines table and the Permissions policy page both put mandatory compliance on January 27, 2027 (not October 28 — some older indexed copies of Google's pages still show that date). Apps that don't truly need broad contact access must use the Android Contact Picker (or another privacy-oriented path like Sharesheet). Apps that only need one-time precise location must use the location button when they target Android 17+.

The near-term date that matters for launches is sooner: Play Console pre-review checks start October 27 and can flag contacts or location permission issues before you submit for review (Android Developers Blog).

This is a practical checklist for Western and global indie Android builders: does this hit your app, what to swap, and how to avoid a rejection the week you meant to ship.

Not legal advice. This is a developer's reading of Google's public Help Center and Android docs as of October 7, 2026. Google's live pages win if anything here drifts. Check Play Console for your own declarations and flags.

Corrected timeline (hook check)

When  ·  What
**Apr 15, 2026**  ·  Policies announced ([Policy announcement](https://support.google.com/googleplay/android-developer/answer/16926792); [blog](https://developer.android.com/blog/posts/boosting-user-privacy-and-business-protection-with-updated-play-policies)).
**Sep 2026**  ·  Apps with `READ_CONTACTS` prompted in Console to declare or remove the permission and use the Contact Picker ([Contacts Help](https://support.google.com/googleplay/android-developer/answer/16935362)).
**By / from Oct 2026**  ·  Play policy insights in Android Studio (blog: "By October").
**Oct 27, 2026**  ·  New **pre-review checks** in Play Console flag contacts/location policy issues before review (blog).
**Nov 2026**  ·  Precise-location (`ACCESS_FINE_LOCATION`) declaration available in Console ([Location Help](https://support.google.com/googleplay/android-developer/answer/17033915)).
**Jan 27, 2027**  ·  **Policy compliance mandatory.** 30-day self-extension available in Console. After that, in-scope apps are subject to enforcement ([Policy Deadlines](https://support.google.com/googleplay/android-developer/table/12921780); Contacts Help; Location Help). Location FAQ: enforcement for Android 17+ anticipated **late January 2027**.

Flag: Search engines still surface some Google Help pages that say "effective October 28, 2026." Live fetches of the Policy Deadlines table and the Permissions policy banner currently say January 27, 2027. This post follows the live pages.

Does this affect my app?

Work top to bottom. Stop when you land on a clear path.

1. Are you on Google Play?

  • No → These Play policies don't apply. Android 17 still ships Contact Picker and the location button as platform APIs you may want for UX/privacy.
  • Yes → Continue.

2. Do you (or will you) target Android 17 (API 37+)?

Both policies are framed around apps that target Android 17 or later:

  • Contacts: may only keep READ_CONTACTS if the Contact Picker isn't enough for core functionality (Contacts Help).
  • Location button: required minimum scope for transactional precise location on Android 17+ (Location Help; location button docs).

If you still target API 36 or lower, you are not in the hard Android 17+ enforcement bucket yet — but raising targetSdk later pulls you in. Plan before you bump.

3. Contacts: what are you actually doing?

Your feature  ·  Likely path
Invite a friend, share a file, pick one contact to message/pay  ·  **Contact Picker or Sharesheet.** Broad `READ_CONTACTS` is generally **not** allowed for these ([Contacts Help](https://support.google.com/googleplay/android-developer/answer/16935362)).
Custom in-app contact list UI that still reads the whole book  ·  **Does not** qualify you to keep `READ_CONTACTS`. Google says a custom picker experience is not enough.
Friend matching / social discovery that needs the full device list, contact manager, dialer/SMS UI, CRM, call screening, accessibility, backup/restore, keyboard autocomplete  ·  May keep `READ_CONTACTS` **if** you pass the Play Console declaration and explain why the picker is technically insufficient.
Enterprise / private device management  ·  Exempt from the Contacts policy requirement (per Help Center).
No contacts access at all  ·  Unaffected by the Contacts policy.

4. Location: how precise and how often?

Your feature  ·  Likely path
City/region content, "within ~5 miles," store list at city scale, language/currency by region  ·  Prefer **`ACCESS_COARSE_LOCATION`** ([Location Help](https://support.google.com/googleplay/android-developer/answer/17033915)).
Search nearby, share current pin once, tag a photo/post, autofill delivery address  ·  On Android 17+: **location button** (session-scoped precise).
Turn-by-turn navigation, live fitness tracking, continuous in-app tracking  ·  May keep persistent **`ACCESS_FINE_LOCATION`** with a Console declaration explaining why the button or coarse isn't enough.
Background location  ·  Separate, stricter rules. The location button does **not** cover background.
Location only for ads/analytics  ·  Not allowed as the sole purpose ([Permissions policy](https://support.google.com/googleplay/android-developer/answer/16558241)).
No location  ·  Unaffected.

Many consumer apps never need contacts or persistent precise location. An outfit-rating app like DripScore is the common case: if you don't declare READ_CONTACTS or ACCESS_FINE_LOCATION, these two policy tracks don't change your release checklist.

What to swap

Contacts → Contact Picker (or Sharesheet)

Goal: User picks specific contacts (and fields). Your app gets temporary access without READ_CONTACTS.

Practical steps:

  1. Remove READ_CONTACTS from the manifest if you only need invite/share/one-shot pick flows and you target Android 17+.
  2. Launch the system picker with ContactsPickerSessionContract.ACTION_PICK_CONTACTS / Intent.ACTION_PICK_CONTACTS (Contact picker guide).
  3. Request only the MIME types you need (phone, email, postal, etc.).
  4. On success, query the returned Session URI with ContentResolver. Do not pass selection / selectionArgs — that throws.
  5. Persist immediately if you need the data after process death. Session access is temporary (Contact Picker blog).
  6. For multi-invite, use EXTRA_ALLOW_MULTIPLE and optionally EXTRA_PICK_CONTACTS_SELECTION_LIMIT.

Compatibility notes:

  • Contact Picker exists on Android 17+ only (not backported) (Contacts Help).
  • If you already use legacy ACTION_PICK and target Android 17+, the system can upgrade you to the new UI. Switch to ACTION_PICK_CONTACTS for multi-field requests, work/private profiles, and the session URI model.
  • You can force-test the new UI on Android 17 devices while still targeting a lower SDK with EXTRA_USE_SYSTEM_CONTACTS_PICKER.

If you truly need the whole address book for core functionality, keep READ_CONTACTS, complete the declaration (prompted from September 2026), and write a technical justification — feature list alone isn't enough.

One-time precise location → location button

Goal: Session-scoped precise location from a clear user tap, without training users to grant "only this time" over and over.

Practical steps:

  1. Audit every ACCESS_FINE_LOCATION call site. Mark each as transactional (one-shot) or persistent (continuous while in use).
  2. For transactional + Android 17+ target: integrate the Jetpack location button (docs).
  3. Declare the needed location permissions plus USE_LOCATION_BUTTON.
  4. If the app only needs precise location via the button, set the fine permission with the button-only flag. Play Help shows:
<uses-permission
    android:name="android.permission.ACCESS_FINE_LOCATION"
    android:usesPermissionFlags="onlyForLocationButton" />
  1. Match Google's design constraints: you can theme colors/shape/label from the allowed set; the location icon stays mandatory and system-controlled.
  2. On Android 16 and lower, the Jetpack library falls back to a local button that triggers the normal permission prompt — one integration path for old and new devices.

Caveats:

  • The location button library is documented as experimental and subject to change. Pin versions and retest before a store push.
  • Button access is foreground / session only. Background needs the separate background-location review path.
  • If you need ongoing precise location for a promoted core feature, keep fine location, complete the Console declaration (available November 2026 per Help), and explain why the button or coarse location fails technically.

How to avoid rejection the week of launch

Indie failure mode is usually the same: you bump targetSdk to 37, ship a contacts invite screen that still requests READ_CONTACTS, or keep fine location for a "find nearby" button that should have been the location button — and Console or review stops you.

Do this before you cut a release candidate:

  1. Inventory permissions in the merged manifest: READ_CONTACTS, ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION, USE_LOCATION_BUTTON.
  2. Map each to a user-visible feature that appears in your Play listing. Policy expects sensitive access to match promoted core functionality (Permissions policy).
  3. Prefer the smallest scope: Sharesheet/Contact Picker over READ_CONTACTS; coarse over fine; location button over persistent fine; foreground over background.
  4. Complete Console declarations if you still need broad contacts or persistent fine location. Use Google's listed use-case buckets; spell out why the picker/button/coarse path is technically insufficient. "We built a nicer UI" is not a contacts justification.
  5. After October 27, run Play Console pre-review checks and treat contacts/location flags as release blockers, even though hard compliance is January 27. Google's own blog positions those checks as the way to fix issues before review.
  6. Don't file an update that raises targetSdk without the swap. Location Help says updates that don't meet Android 17+ standards may be rejected; existing apps are not exempt.
  7. If you need more time past January 27, note the 30-day self-extension in Console — then still ship the fix. Extensions are a bridge, not a product strategy.
  8. Test on Android 17 for picker session URIs and the system-rendered location button, not only on older emulators.

Indie checklist

  • [ ] Confirm whether this release targets Android 17 (API 37)+.
  • [ ] List every screen that touches contacts or location.
  • [ ] For each contacts flow: picker/Sharesheet vs justified READ_CONTACTS.
  • [ ] Remove READ_CONTACTS if you only invite, share, or pick a contact to transact with.
  • [ ] If keeping READ_CONTACTS: Console declaration submitted; technical "why picker fails" written.
  • [ ] For each location flow: coarse vs location button vs persistent fine vs background.
  • [ ] Implement location button (and button-only flag if applicable) for one-shot precise needs on Android 17+.
  • [ ] If keeping persistent fine: November+ declaration completed with a real core-feature justification.
  • [ ] Confirm location is never requested solely for ads/analytics.
  • [ ] Persist Contact Picker session results immediately where needed.
  • [ ] After Oct 27, clear Console pre-review flags for contacts/location before submitting.
  • [ ] Put Jan 27, 2027 (plus any 30-day extension) on the release calendar if you still have debt.
  • [ ] Re-read live Policy Deadlines the week you ship — Google has already moved the public date once relative to older indexed copies.

Soft close

You don't need a privacy rewrite for every app. You need an honest permission audit before Android 17 targeting and before the January 27 enforcement window. Most indie apps that only invite friends or "search nearby" should delete broad contacts access and swap one-shot precise location to the location button. Apps that truly need the full address book or live tracking should spend their time on a tight Console declaration, not on arguing with the picker.

If you want a second pair of eyes on a Play permissions audit, Contact Picker migration, or location-button integration before you raise targetSdk, say hello via /#contact.

About the author

Muhammad Tayyab is a full-stack and mobile developer. He builds DripScore (AI outfit rating) under dawnapps.co, also on the App Store. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

Back to all posts
Thanks for reading 🙏