Google Play Policy Update 2027: A Flutter Owner's Checklist (Oct 2026 Changes)
Google Play's policy update for 2027 landed in an October 29, 2026 refresh — and if you ship a Flutter app on Android, several deadlines now sit between January 27, 2027 and August 25, 2027. None of these are Dart-specific, but Flutter teams feel them first in AndroidManifest.xml, Play Console declarations, and plugins that still request broad contacts, location, or call-log access.
I have spent 6+ years shipping Flutter apps to Google Play, including Plum Goodness (1M+ Play downloads) and FleetTrack (100K+ downloads). This Google Play policy changes checklist is for founders and CTOs who need to translate Google's tables into engineering work — without waiting for a rejection email.
Most new rules are about permission scope and Console declarations, not rewriting your Flutter UI.
Plan against the published deadlines in Google's policy deadline table, not rumor timelines.
What Changed in the October 2026 Play Policy Refresh
Google groups the updates under Permissions and APIs that Access Sensitive Information, foreground services, SMS/call log access, subscriptions, and AppFunctions. The official timeline matches Play Console help and the Google Play policies overview.
The table below is a Flutter owner lens: what to audit in your repo, what to expect in review, and when compliance is required. Dates are Google's published deadline (YYYY-MM-DD) values.
| Deadline | Policy area | What Flutter teams should check |
|---|---|---|
| 2027-01-27 | Contacts Permissions | Remove broad contact access unless core; use Android Contact Picker instead |
| 2027-01-27 | Location Permissions | Apps targeting Android 17 (API 37+) need the location button for one-time/infrequent precise location unless you justify broader access in Console |
| 2027-01-27 | SMS / Call Log | READ_CALL_LOG no longer allowed for phone-call account verification — migrate to SMS Retriever, Digital Credentials API, or a provider |
| 2027-01-27 | Foreground services | Geofencing is removed as an approved foreground service use case — use the Geofence API |
| 2027-01-27 | Subscriptions | Eligibility-based discounts (e.g. student plans) need clear eligibility, verification, and post-eligibility pricing disclosure |
| 2027-04-14 | AppFunctions API | AppFunctions must not deceive AI agents, bypass security, or interfere with other apps |
| 2027-08-25 | Local Network (Android 17+) | Local Network permission restricted; Play Console declaration required when targeting API 37+ |
| 2027-08-25 | Manage Contacts | Broad manage-contacts access restricted; declaration or narrowly scoped intents for everyone else |
If you are still working through older gates — bundle alignment, data safety, signing — fold this list into your existing App Store + Play Store release checklist. The new 16 KB page size requirement is a separate deadline (2027-02-01 for blocking non-compliant updates) and should stay on the same roadmap.
January 27, 2027: Contacts, Location, Call Log, Geofencing, Subscriptions
Contacts: Contact Picker beats READ_CONTACTS
Google's Contacts Permissions policy says apps that do not need broad contact access must use the Android Contact Picker — a system UI that returns user-selected contacts without exposing the entire address book.
In Flutter, that usually means:
- Audit
pubspec.yamlforcontacts_service,flutter_contacts, social-sharing plugins, or CRM SDKs that pull full contact lists. - Search
AndroidManifest.xmlforREAD_CONTACTS,WRITE_CONTACTS, or the newer Manage Contacts permission paths yourcompileSdkexposes. - Replace "sync all contacts" flows with picker-based invite or referral UX unless contact management is core functionality (and you can defend it in Console).
Teams that already follow least-privilege in Flutter + Firebase production hardening still fail here when a single outdated plugin re-introduces manifest merges.
Location: location button for Android 17 targets
For apps targeting Android 17 (API 37+), Google now treats the location button as the recommended minimum scope for one-time or infrequent precise location. Broader ACCESS_FINE_LOCATION access remains possible when location is truly core — but Play expects a declaration explaining why the button or coarse location is not enough.
Flutter implications:
- Map and delivery apps (FleetTrack-scale logistics is a common pattern) often request always-on fine location via plugins — reconcile product requirements with the new minimum scope before you bump
targetSdk. - If you only need "current city" or one-shot check-in, plan platform-channel or plugin support for the system location button rather than custom always-on prompts.
- Update Data safety and in-app disclosure text when you shrink scope — reviewers cross-check narrative and manifest.
Planning to build a Flutter app?
I help startups design and build scalable mobile apps with clean architecture, Firebase, and store-ready delivery.
READ_CALL_LOG and phone verification
Google explicitly removes account verification via phone call as an allowed use case for READ_CALL_LOG. If your Flutter app (or an embedded auth SDK) inferred verification from call logs, migrate before 2027-01-27.
Official alternatives cited in Play policy:
- SMS Retriever API (no broad SMS permission when used correctly)
- Digital Credentials API or verification providers built on it
Search your merged manifest for READ_CALL_LOG and READ_SMS. Payment, wallet, and telecom plugins are frequent culprits. This pairs with store-readiness work in CI/CD for Play Store shipping — catch permission drift in release builds, not on a developer phone.
Geofencing: exit foreground-service pattern
Geofencing as a foreground-service use case is removed. Google directs developers to the Geofence API instead.
For Flutter field-service or logistics apps, audit:
- Plugins that start a foreground service to hold geofence regions alive in the background.
- Dart isolates + platform channels that combine
FOREGROUND_SERVICEwith geofence triggers.
You may keep geofences; you should not rely on the deprecated FS justification. Expect manifest and Play Console foreground service declarations to be scrutinized during review.
Subscriptions with eligibility-based discounts
If you sell student, senior, or other ongoing eligibility-based discounts, disclosures must cover:
- Who qualifies
- How eligibility is verified
- What happens to price and benefits when eligibility ends
Flutter apps using in_app_purchase, RevenueCat, or native Play Billing wrappers still own the Play listing and in-app copy. Align Flutter paywalls and FAQs with Console subscription settings before the deadline.
April 14, 2027: AppFunctions and AI-adjacent surfaces
Google's AppFunctions API rule (announced October 29, 2026) states that AppFunctions must comply with all existing Play policies and are prohibited from:
- Deceiving or manipulating AI agents
- Bypassing security controls
- Interfering with other applications
If you are exposing app capabilities to on-device or system AI agents — a growing pattern alongside adding AI features to existing Flutter apps — treat AppFunctions as a trust and abuse surface, not a shortcut around user consent. Document what each function exposes, gate destructive actions behind existing in-app auth, and avoid UX that could trick an agent into unintended purchases or data export.
August 25, 2027: Android 17 Local Network and Manage Contacts
Local Network permission declaration
For apps targeting Android 17 or higher (API 37+), Local Network access is limited to cases where it is needed for core functionality and device pickers are insufficient. Developers must submit a Play Console declaration to use it.
Flutter apps that discover printers, smart-home bridges, or LAN devices via mDNS/Bonjour often trigger this permission when you raise targetSdk. Before you adopt API 37:
- List every plugin that scans the local network (printing, casting, IoT).
- Decide whether each flow can move to Android's device picker patterns.
- Budget time for declaration forms and policy appeals — similar to how teams handled photo/video permission declarations in earlier policy cycles.
Manage Contacts permission
Manage Contacts follows the same pattern: restricted to core contact-management apps with a declaration; everyone else must use narrowly scoped platform intents.
If your product is not literally a contacts app, plan to delete Manage Contacts merges from dependencies and re-test invite flows on Android 17 emulators.
A Practical Audit Checklist for Flutter Codebases
Work through this sequence on a release branch so CI artifacts match what Play analyzes:
- Manifest merge report —
./gradlew :app:processReleaseManifest(or inspectbuild/app/intermediates/merged_manifests/release/) and list every dangerous permission. - Plugin inventory — map each permission to a
pubspec.yamlpackage; open issues or upgrade paths for maintainers. targetSdkroadmap — separate "must ship features" from "API 37 permission refactors"; Android 17 location button work may need native code before Flutter widgets catch up.- Play Console pre-checks — Policy status, App content, and new declaration slots for Local Network / Manage Contacts / broad location.
- Regression on real flows — referral picker, one-shot location, OTP login, geofence arrivals, discounted subscription renewal.
- Store copy — subscription eligibility text, location rationale strings, and Data safety answers that match the shrunken permission set.
If the codebase is already fragile, combine this audit with stabilizing an existing Flutter app — policy compliance is cheaper when your upgrade path and CI are predictable.
How This Differs From Flutter SDK Release Notes
Flutter 3.50 (still pre-stable as of November 2026) includes Android-side breaking changes such as stricter Intent verification for FlutterActivity extras and engine flags ignored in release mode. Those affect deep links and embedded engines — but they are SDK migration tasks, not Play Console policy declarations.
Treat Play policy deadlines as store-compliance work owned by product and release engineering, and Flutter upgrades as toolchain work owned by mobile leads. Both need calendar space before you target Android 17 in production.
FAQ
Does this Google Play policy update require rewriting our Flutter app?
Usually no. Most deadlines push you toward narrower permissions, system pickers, updated billing copy, and Console declarations. Expect manifest, native Gradle, and plugin changes — not a new Dart architecture.
We only ship iOS today. Does Android 17 matter?
Not until you raise Android targetSdk. If your roadmap includes Play in 2027, bake these audits into your next Android milestone rather than bolting them on before a forced targetSdk bump.
Is the Contact Picker usable from Flutter?
Yes, via platform channels or plugins that wrap the Android picker intent. Prefer maintained plugins that document picker-only flows instead of full contact database access.
Fleet tracking apps — are we banned from background location?
No. Core logistics use cases can still justify broader location, but apps targeting Android 17 must implement the location button where requests are one-time or infrequent, and justify broader ACCESS_FINE_LOCATION in Play Console when location is core.
Where is the canonical deadline list?
Use Google's Policy Deadlines table and the Play policies timeline. This article summarizes; Google's pages govern enforcement.
Next Step
Google Play policy update 2027 Flutter teams should not discover these rules from a suspended release. The work is meticulous — manifest merges, billing disclosures, geofence refactors — the same release discipline that keeps large consumer and logistics apps shippable year over year.
If you want a senior Flutter IC to audit permissions, targetSdk plans, and Play Console declarations before your next production Android cut, I help remote teams in US, UK, and Tier-1 markets ship compliant builds without pausing product work.
Explore Flutter app development services, or book a consultation at calendly.com/anghansagar25 / email hello@sagaranghan.com.
Have an app idea?
Let's build something scalable together — from MVP through store release.
See case studies for production examples.