AI & TechnologyGoogle Play Contacts and Location Permission Changes 2027

Google Play's deadlines table lists January 27, 2027 for four sensitive-permission changes: a new Contacts Permissions policy, the location button as the recommended minimum for precise location, no more READ_CALL_LOG for phone-number verification, and geofencing removed as a foreground service use case. The contacts and location button rules are tied to apps that target Android 17 (API level 37) or later. Google's call log and geofencing pages say only "effective January 27, 2027" and give no target API. The June 2026 Play newsletter says "Starting October 28, 2026" for the contacts and location changes, and I could not reconcile the two dates.

I checked each one on October 19, 2026. Google can change a date, so open the linked page before you plan around it.

Disclosure: App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Google doesn't pay me for anything on this page.

The dated table

The contacts article says compliance is mandatory on January 27, 2027 for apps that target Android 17 or later (API level 37+). The location article says compliance is mandatory for "all apps" on that date, but it requires the location button for apps that target Android 17 or later, and expects enforcement for those apps in late January 2027. Both say a self extension of 30 days will be available in Play Console, and that apps in scope are subject to enforcement after that date. The call log and geofencing pages state the effective date only, with no target API, so I can't say whether a lower target API protects you there.

The date conflict

Two Google sources give two different dates, and I want to show both.

The policy deadlines table lists 2027-01-27 as the deadline for each of the four rows, with announcement dates of 2026-04-15 (and 2026-07-15 for READ_CALL_LOG). The Help Center articles repeat it: the contacts article says "January 27, 2027: Policy compliance is mandatory for all apps that target Android 17 or later (API level 37+)."

The June 2026 Play newsletter, under "Policy deadlines and reminders", says: "Starting October 28, 2026: Contacts permissions: Developers must use the Android Contact Picker for apps that do not require broad contact access." It says the same date for the location button. It does not mention READ_CALL_LOG or geofencing.

What I could verify for each reading:

• January 27, 2027 appears on the deadlines table and in four Help Center articles as the effective or mandatory date.
• October 28, 2026 appears on the newsletter page. It does not appear in the Help Center articles I read.
• The April 2026 Android Developers Blog post says "new pre-review checks in the Play Console will be available starting October 27". That is one day off from October 28, and the post does not say the two are the same thing. It also says the contacts declaration form "will be available before October."

My reading is that October 27 or 28 marks the start of Play Console checks and January 27, 2027 is the date compliance becomes mandatory. That is my inference. No page I found states it, so treat it as unconfirmed.

My advice: plan to be done before October 28, 2026 if you can, and use January 27, 2027 as the hard date. Open Play Console, check any prompt or pre-launch warning on your app, and follow what it says.

1. Contacts Permissions policy

What changes. The Help Center article says apps that target Android 17 or later "may only request the READ_CONTACTS permission if the Android Contact Picker is not sufficient for your app to provide core functionality." Contacts are treated as personal and sensitive data under the User Data policy.

Who must act. Any app that targets Android 17 (API level 37) or later and requests READ_CONTACTS. Google says private apps and enterprise device management apps are exempt. If your app asks for contacts to share or invite, the April 2026 Android Developers Blog says to switch to the picker and remove READ_CONTACTS.

The declaration. If you keep the permission, you complete a declaration in Play Console that shows your access needs and why the Contact Picker is insufficient. The article says a custom picker "does not qualify as a reason to retain Contacts access."

The catch. The article states that the Android Contact Picker "is not backported to previous versions and only exists for Android 17 or later (API level 37+)." It is invoked with the Intent.ACTION_PICK_CONTACTS intent. If your app supports older Android versions, you need to decide what those users get.

2. The location button

What changes. Google's preview article says it is "introducing the location button as the recommended minimum scope for precise location." For apps that target Android 17 or later, if precise location is needed only for one-time, user-initiated actions, you must implement the Android location button and declare it in the manifest with the onlyForLocationButton flag.

Who must act. Any app that requests ACCESS_FINE_LOCATION. The minimum-scope article says all apps requesting precise location must complete a declaration in Play Console and explain why the location button or coarse location is insufficient. Apps that need precise, persistent access must show it is essential to core functionality.

Dates. Announced April 15, 2026. The precise-location declaration becomes available in November 2026. Compliance is mandatory January 27, 2027.

My advice: list every place your app asks for precise location. For each, ask whether it is a one-time action the user starts, such as "find stores near me". Those are the ones the button is for.

3. READ_CALL_LOG and phone verification

What changes. The SMS and call log article says Google "will no longer permit account verification via phone call as a use case for the READ_CALL_LOG permission", effective January 27, 2027. The article already requires apps using these permission groups to be actively registered as the default SMS, Phone or Assistant handler.

Who must act. Apps that read the call log to confirm a user's phone number, for example by matching an incoming verification call.

What to use instead. The article recommends the Digital Credentials API to verify accounts without sensitive permissions, and mentions that the SMS Retriever API can do SMS-based verification automatically. If neither is an option, users can enter a verification code manually.

4. Geofencing as a foreground service

What changes. The foreground service preview article says: "We're removing geofencing as an approved foreground services use case." It adds that developers can instead use the Geofence API. Effective January 27, 2027.

Who must act. Apps that run a location-type foreground service just to monitor geofences. The article still lists background location updates for user-initiated location sharing and navigation, so a service that does those is a separate question.

What the Geofence API needs. Android's geofencing guide says your app must request ACCESS_FINE_LOCATION, and ACCESS_BACKGROUND_LOCATION if it targets Android 10 (API level 29) or higher. You create a GeofencingClient through LocationServices. Note that the geofencing guide's permissions are themselves sensitive and fall under Play's location rules above.

The Flutter angle

Flutter apps get these permissions from three places: your own AndroidManifest.xml, plugin manifests, and the Play policy checks on the final build. Here is what I could verify on pub.dev.

• permission_handler (13.0.2 when I read it) has Permission.contacts and a rationale check, Permission.contacts.shouldShowRequestRationale, on Android. Its page also says that on Android 10 and later you request foreground location first, then call Permission.locationAlways.request(). The page does not mention Android 17, the Contact Picker or the location button.
• flutter_contacts (2.6.0) tells you to add READ_CONTACTS and WRITE_CONTACTS to your manifest. Its FlutterContacts.native.showPicker() needs no contacts permission on either platform. The page says calling it with properties on Android requires READ_CONTACTS. The page does not mention Android 17, so I can't say whether showPicker() uses the new system picker on API 37.
• contacts_service (0.6.3) is listed as published 5 years ago. Its README says to add READ_CONTACTS and WRITE_CONTACTS and that it does not handle permission requests itself. I did not see a discontinued note on the page.
• geolocator (14.1.1) tells you to add ACCESS_COARSE_LOCATION, and ACCESS_FINE_LOCATION only if you need precise location. For ACCESS_BACKGROUND_LOCATION it says apps targeting Android 10 and later need it for updates in the background. It states that FOREGROUND_SERVICE_LOCATION is required from Android 14 for a location foreground service and that the plugin's manifest declares it.

None of those pages describe the new Play policy, so whether a given plugin version is compliant is something you need to test, not assume.

Removing a permission from the merged manifest

Android's manifest documentation describes the tools:node="remove" marker as one that removes an element from the merged manifest, used "when you discover an element in your merged manifest that you don't need that was provided by a lower-priority manifest file that's out of your control (such as an imported library)." The page declares the namespace as xmlns:tools="http://schemas.android.com/tools" on the <manifest> element.

For a permission, the pattern in android/app/src/main/AndroidManifest.xml looks like this:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <uses-permission
        android:name="android.permission.READ_CALL_LOG"
        tools:node="remove" />

The Android page's own example removes a meta-data element, not a uses-permission line. Applying it to a permission follows from the general rule, but I have not run it against your build. Build a release, then read the merged manifest and confirm the line is gone.

One more caution. Removing a permission a plugin needs will break that plugin feature at runtime. Remove only what you have confirmed your app does not use.

My advice: for each of the four permissions, search your own manifest and your merged manifest, then work out which plugin adds it before you change anything.

A short plan

1. Check Play Console. Look for prompts about READ_CONTACTS and precise location on each app, and note the dates they show.
2. Find the permissions. Read the merged manifest for READ_CONTACTS, ACCESS_FINE_LOCATION, READ_CALL_LOG and FOREGROUND_SERVICE_LOCATION.
3. Trace each to a feature. Sharing or inviting: use the picker. One-time precise location: use the location button. Call-log verification: move to the Digital Credentials API or SMS Retriever. Geofence monitoring: move to the Geofence API.
4. Decide your target API. The contacts and location rules apply to apps that target Android 17 or later. For the target API deadline itself, see my Android 16 target API guide.
5. File declarations only for permissions you truly keep, and write down the user-facing feature each one supports.
6. Test a release build on a real device, with a clean install, before you submit.

For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see App Store and Google Play deadlines for 2026 and 2027.

Need a hand?

If your Flutter app requests contacts, precise location, call log or geofencing permissions and you want it sorted before Google Play enforces the change, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.