Google Play in 2027: The Rules Small Publishers Keep Missing

A policy email you don't fully understand. A red banner in the Console about your target API level. A strike out of nowhere. The rules changed, and nobody sent a memo.

Here's what's enforced right now, what lands over the next twelve months, and which 2027 headlines you need to plan around. Shipping your first Android app? Pair this with our Android publishing walkthrough.

The rule that quietly kills your installs: target API 36

From August 31, 2026, every new app and every update you push must target Android 16 (API level 36) or higher. Wear OS and Android Automotive apps need API 35; Android TV and Android XR apps need API 34.

The trap is the app you aren't updating. If your build targets API 34 or lower, Play stops offering it to new users on devices running a newer Android version than you target — installs quietly drop and you blame marketing. If the calendar already beat you, Play Console has an extension form that pushes your deadline to November 1, 2026. Bumping target API isn't bumping minimum SDK — you keep older devices, you just also declare you tested against Android 16's behavior changes:

• Edge-to-edge can no longer be disabled — handle system bars and display cutouts yourself.
• Predictive back is on by default; custom back handlers must move to the supported back navigation APIs.
• On displays 600dp and wider, your orientation, resizability and aspect-ratio restrictions are ignored.
• Foreground service types and runtime-registered receiver export flags still have to be declared — API 34 and 35 carryovers old projects never fixed.

Individually none are hard; together they break an app nobody has touched in a year. The large-screen one gets worse: Android 16 still lets you opt out of adaptive layout behavior, but that escape hatch disappears at API level 37. Ship a locked-portrait phone app and 2027 is when that stops being a choice.

The September 30 deadline nobody is talking about

Top of your list: it isn't a code problem, and it's easy to miss. Google now requires every app distributed on Google Play to be registered in Play Console under a verified developer, package name included. Apps not registered by September 30, 2026 face removal from Google Play globally. Not a strike. Not reduced visibility. Removal.

One active app and a current account and you're probably fine. Inherited client accounts, forgotten packages and half-finished organization verification are the profile this catches. Go look — ten minutes.

The deadlines that actually hurt small publishers aren't the technical ones. They're the Console checkboxes nobody assigned to anybody.

Developer verification: what's live, and what 2027 really means

Behind that deadline is Android developer verification: Google wants every app on a certified Android device to come from an identity-verified developer, through Play and through sideloading. Where it stands:

• Verification opened to all developers in March 2026 — Play Console for Play publishers, the new Android Developer Console for everyone else. Limited-distribution accounts for students and hobbyists went global in August.
• From September 30, 2026, apps must come from a verified developer to install or update on certified devices in Brazil, Indonesia, Singapore and Thailand.
• The requirement expands to the rest of the world through 2027.

Sideloading isn't going away; anonymous distribution is. Ship APKs directly to clients, or run a beta outside Play? Get verified now. One warning: organization accounts need a D-U-N-S number, the same identifier Apple uses. It's free, but issuance can take weeks in some regions while review itself takes days. That's the long pole, and people hit it the week they wanted to launch.

Permissions: the January 27, 2027 pileup

Contacts — January 27, 2027

Apps that don't genuinely need the whole address book must use the Android Contact Picker, which returns the single contact the user chose without granting READ_CONTACTS over everything. Smaller code change than you'd guess, and it kills a category of policy risk.

Location — January 27, 2027

Same date, same idea. The location button — one-shot precise location granted in context — is the recommended minimum scope. Always-on precise location "just in case" is the fastest route to a warning. Genuine background location needs a Prominent Disclosure and a real justification.

Call log — January 27, 2027

The sleeper. From January 27, 2027, the SMS and Call Log Permissions policy no longer accepts account verification by phone call as a use case for READ_CALL_LOG. Sign-in flows that read the call log must move to the Digital Credentials API, the SMS Retriever API, or another supported path — engineering work, not a manifest edit, so put it in a Q4 sprint. Related: on the same date, geofencing stops being an approved foreground service use case. Use the Geofence API.

Data Safety: the form that eats small publishers alive

Data Safety is Google's primary policy lens: what your app collects, shares and why, checked against the real behavior of the SDKs you ship. It's the most common source of avoidable strikes, because it drifts:

• An analytics or ads SDK goes in and the form never gets updated.
• A new crash reporter collects a slightly different field.
• A chat or auth SDK quietly collects contact info.
• An AI feature forwards user content to a third-party model provider — data sharing, and it has to be declared.

Any of those can produce a strike months later. Treat the form like a code artifact: when an SDK changes, the form changes.

AI features, chat apps, and child safety

If your app generates content with AI — chatbots, image generation, voice or video of real people, "smart" summaries — Google's AI-Generated Content policy applies. Two obligations: users need an in-app way to report or flag offensive AI output, and you must test your models well enough to keep restricted content from being generated at all. You own what the model produces, even when it's someone else's model.

On child safety: from August 26, 2026, the Age-Restricted Content and Child Safety Standards policies specifically cover anonymous and random chat apps, and the Families policy prohibits anonymous chat apps from targeting children. User-to-user messaging needs reporting and blocking flows plus visible in-app content policies.

Money: the fee structure changed, and it isn't done

Since June 30, 2026 in the US, UK and EEA, Google splits the old 30% commission into a service fee and a separate billing fee. The service fee is 10% on your first $1M in annual earnings and 10% on all auto-renewing subscriptions. Above $1M, non-recurring transactions run 20% on new installs and 25% on existing installs, lower if you're in the Apps Experience or Games Level Up programs. Google Play Billing adds a 5% billing fee in those regions, waived if you use alternative billing or an external checkout. Australia and Japan follow September 30, 2026, South Korea December 31, 2026, and the rest of the world September 30, 2027.

US developers in the external content links and alternative billing programs also start reporting transactions and paying service fees on October 1, 2026. And the Play Catalog Access Program went live July 22, 2026: US listings reach approved third-party US app stores automatically unless you opt out in Play Console, with downloads still completing through Play at the same terms. Free reach for most small publishers — but make it a decision, not a discovery.

If you're a solo dev with a new personal account

Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 consecutive days before applying for production access. It was 20 originally; Google cut it to 12 after developers pushed back. The word doing the work is consecutive: testers who opt in and out don't count. Organization accounts and older personal accounts are exempt. Budget three weeks, not three days.

The strike appeal, briefly

Got hit? Read the exact policy citation, fix it in code and in your Console metadata, then appeal with a short note referencing the change. Don't argue policy, don't send a wall of text — reviewers respond to "here's the section, here's the fix, here's the commit."

Where people go wrong (and when to call a pro)

Frequently asked questions