Google Play's October 2026 Policy Update: What App Teams Must Change

On October 29, 2026, Google Play published its latest batch of policy changes. Most of the headlines are about permissions that Android 17 tightens at the platform level (local network and contacts), a first set of rules for AppFunctions, the API that lets AI agents call into your app, and a new trader status declaration that every developer account has to complete. Some dates are close, others are almost a year out, so the useful question is not "what changed" but "what do we have to do, and by when".

▶ Watch the video version (about 4 minutes):

This guide sorts the update by deadline and by the kind of app it affects, with the exact Play Console steps where Google documents them.

The short version

Google's policy announcement says developers have "at least 30 days" from October 29 to comply, but the Policy Deadlines table gives each change its own effective date. Here is what matters for a typical app team:

Change	Who is affected	Effective date	What to do
Target API extension ends	Apps that took the API 36 extension	November 1, 2026	Ship an update targeting API 36
Japan payments authorization	Developers selling into or out of Japan	December 1, 2026	Complete the authorization form
Contacts (READ_CONTACTS) and location button	Apps targeting API 37+	January 27, 2027	Move to Contact Picker / location button, or declare
Eligibility-based subscription discounts	Student and similar plans	January 27, 2027	Disclose criteria, verification and post-eligibility price
Trader status declaration	Every developer account	February 1, 2027	Declare trader or non-trader in Play Console
AppFunctions rules	Apps that expose AppFunctions	April 14, 2027	Audit function metadata and responses
Local Network and Manage Contacts	Apps using ACCESS_LOCAL_NETWORK or MANAGE_CONTACTS	August 25, 2027	Use pickers and intents, or submit a declaration

The first two rows are this month's real deadlines. The rest give you time, but most of them require code changes, not just a form.

Local network access becomes a declared permission

Until now, any Android app with the INTERNET permission could talk to devices on the user's Wi-Fi: printers, smart TVs, IoT hubs, a dev server on your laptop. Android's local network permission guide explains why Google is closing that door: open LAN access can be used to fingerprint a user and acts as a proxy for location.

On Android 17, local network access is blocked by default for apps that target SDK 37 or higher. The block sits deep in the network stack, so it covers raw sockets, NsdManager, OkHttp, Cronet and WebView traffic (WebView inherits the host app's permission). Outgoing and incoming TCP, and UDP unicast, multicast and broadcast all need the new ACCESS_LOCAL_NETWORK permission. Two exceptions are documented: DNS traffic to a local resolver on port 53, and apps that use the system Output Switcher for casting.

Google gives two paths:

Path A: pickers. For mDNS discovery, build a DiscoveryRequest with FLAG_SHOW_PICKER. The system shows a dialog, the user picks one device, and your app can connect to that device's addresses without the permission. Cast-style media apps should use the Output Switcher.
Path B: runtime permission. Home automation and device-management apps that need broad, persistent LAN access declare ACCESS_LOCAL_NETWORK and request it at runtime. It belongs to the NEARBY_DEVICES group, so a user who already granted a Bluetooth permission in that group will not be prompted again.

The new Play policy adds a review layer on top. Under the permissions policy preview, apps targeting API 37+ may only request ACCESS_LOCAL_NETWORK when device pickers cannot deliver the core feature, and must submit a Play Console declaration explaining why. The policy takes effect on August 25, 2027.

How to test it today

You do not need to wait for API 37 to find out what breaks. On an Android 16 device (Beta 3 or later), run adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name> and reboot. LAN calls will fail the way they will on Android 17: TCP connections usually time out, UDP returns EPERM. Note that while you target SDK 36 or lower, Google says not to add ACCESS_LOCAL_NETWORK to your manifest yet.

Contacts: picker first, declaration second

Contacts rules arrive in two steps.

From January 27, 2027, apps targeting Android 17 (API 37+) may only request READ_CONTACTS if the Android Contact Picker cannot support the core feature. Apps that keep the permission must explain in a Play Console declaration why the picker is not enough. If your "invite a friend" or "share with a contact" screen reads the whole address book just to let the user choose one person, the picker is the expected solution.

From August 25, 2027, the new Manage Contacts rule applies to MANAGE_CONTACTS. Apps that only need to add or edit a contact should hand the job to the system with intents such as ACTION_INSERT and ACTION_EDIT. The policy preview says apps targeting Android 18 (API 38+) must submit a declaration to keep using the permission.

For most business apps the fix is small: replace the permission request with a picker or an intent, remove the permission from the manifest, and delete any code that cached contacts on your server. That last step also simplifies your Data safety form.

AppFunctions: first rules for agent-facing features

AppFunctions lets an app expose functions, such as "create a task" or "search my emails", that agents and assistants can discover and call. Google describes it as the on-device equivalent of tools in the Model Context Protocol (MCP). It runs on Android 16 and later, callers need the EXECUTE_APP_FUNCTIONS permission, and the API is still marked experimental. As of May 2026, its integration with Gemini was in a private preview with trusted testers.

The new policy section, effective April 14, 2027, is short but specific. AppFunctions must:

Describe themselves accurately. Function names, parameters and descriptions must match what the code actually does at runtime.
Not manipulate agents. No prompts designed to push an agent into harmful actions, and no hidden instructions returned in runtime responses. Any instruction meant for an agent has to be declared upfront when the function is registered.
Not interfere with other apps. A function may not dictate how other apps' AppFunctions run, or try to stop an agent from choosing another app or tool.
Ask for the minimum input. Schemas and parameters should only include what the tool needs, and data that flows through AppFunctions must be reflected in your Data safety section.

If you are already experimenting with AppFunctions, treat function descriptions like store listing text: someone will review them against behavior. The announcement also adds guidance on how the Payments policy applies to digital purchases made through AI or agentic experiences, so agent-driven checkout is now on Google's radar too.

Trader status: a form every account must complete

The trader status page says all active developer accounts must declare whether they are a trader or a non-trader under EEA and UK consumer law, by February 1, 2027, regardless of where their apps are distributed. The announcement says the new Console requirement starts in November 2026.

Google's criteria for a trader follow European Commission guidance: you earn money from apps (paid apps, in-app purchases or ads) on a regular basis, you have consistent transaction volume, you run publishing as a business, or you hold a legal business identity such as a D-U-N-S number. If you do not distribute in the EEA or UK at all, you can declare as a non-trader.

Steps in Play Console:

Go to Manage account > Account details > About you and declare the status for the account.
If you are a trader, open each app, go to Monitor and improve > Policy and programs > App content and confirm trader status.
Self-certify that your products comply with applicable laws and add a terms of service link for each app.

One detail matters for small teams: if a trader uses a personal developer account, Google requires a contact phone number displayed on Google Play and notes that the address will also be public. Declaring "non-trader" to avoid that is not an option for a commercial studio; Google warns that falsely claiming non-trader status can lead to global removal.

Smaller changes worth a checklist line

Subscriptions with eligibility-based discounts (student plans and similar) must clearly disclose who qualifies, how eligibility is verified and what the price becomes when eligibility ends. Effective January 27, 2027.
Location: for apps targeting API 37+, one-time precise location requests must use the Android location button (declare the onlyForLocationButton flag in the manifest), and ACCESS_FINE_LOCATION needs a declaration. Effective January 27, 2027.
Call log: phone-call account verification stops being an allowed use of READ_CALL_LOG on January 27, 2027. The update adds the SMS User Consent API to the list of alternatives.
Japan: developers selling into or out of Japan must complete an authorization by December 1, 2026, or their payments are held globally.
Target API: the target API level page confirms the extension for the API 36 requirement ends on November 1, 2026. After that, an update that does not target API 36 cannot be published.

A practical order of work

This week: check Play Console's Policy status page for target API warnings and the Japan authorization notice.
In November: complete the trader declaration for the account and every app. It is a short task and it removes a removal risk.
Before you raise targetSdk to 37: search the codebase and SDKs for READ_CONTACTS, MANAGE_CONTACTS, ACCESS_FINE_LOCATION, mDNS/SSDP, raw sockets and local IP addresses. Run the RESTRICT_LOCAL_NETWORK compat flag test.
Q1 2027: ship the Contact Picker and location button changes, and update the Data safety form.
Before April 2027: if you expose AppFunctions, review every description and response for accuracy and hidden instructions.

Our take

At Lightning Studio we build mobile apps for clients and publish our own titles, mostly from Da Nang to English-speaking markets. Two items in this update deserve attention now. The trader declaration affects every account we touch, and the personal-account rule (public phone number and address) is one more reason for client apps to live on the client's own organization account rather than on a developer's personal one. The local network rule is the bigger engineering task, but only for apps that talk to hardware: companion apps, casting, smart home, POS devices. For those, start testing with the compat flag now; the picker path is less work than it sounds and gives users a clearer prompt. For everyone else, the contacts and location changes are mostly a cleanup that also makes the privacy story easier to explain.

Sources

Need a hand auditing permissions or preparing an Android update for these deadlines? Write to support@lightning-studio.org or see what we do at https://lightning-studio.org/studio/.

Cover photo: Android phones by Samsung Galaxy Note 10 & Google, CC BY 3.0, via Wikimedia Commons (cropped).