Mobile apps

Android apps: target API 36 and developer verification, what to check

Since 31 August 2026 Google Play has required target Android 16 (API 36), with an extension possible to 1 November. Developer verification started on 30 September in four countries, not Italy, and Play apps must be registered in Play Console.

7 October 2026· 7 min·by NaCode Studios

In short

Since 31 August 2026 Google Play accepts new apps and updates only if they target Android 16 (API 36). On 30 September developer verification started in Brazil, Indonesia, Singapore and Thailand, and developers on Google Play had to register by the same date any apps not registered automatically. Italy is not among the four countries, but this registration applies to every Google Play developer: check your app's target and its registration status.

Updated 7 October 2026. This text summarises Google's official pages, the most recent of them updated on 1 October. Dates and rules can change: sources are listed at the end.

Target API 36 and the extension

According to Google, from 31 August 2026 new apps and updates must target Android 16 (API 36) or higher. Apps already published must target at least Android 15 (API 35) to stay available to new users on devices running a newer Android than their target. Wear OS, Android Automotive OS, Android TV and Android XR have lower thresholds.

An app that does not comply stays in the store, but only for devices running the same Android version as its target or an earlier one. People who already installed it keep using it; downloads from new users may drop. Permanently private apps of a single organisation, meant for internal use, are excluded from the requirements.

If you need more time, you can request an extension to 1 November 2026 to keep distributing the app to all users. According to Google the form is reached from the detail page of the warning, on the Policy status page in Play Console, and only apps that do not comply receive the warning.

What changes when you raise the target

The target is in the app's Gradle file (in a Flutter project it sits in the android folder and follows the Flutter version unless you pin it by hand). A new target brings behaviour changes to check in the app: Google lists many, and these three affect layout and navigation.

Change	With target API 36	Way out
Large screens (from 600dp)	Orientation, resizing and aspect ratio locks set by the app are ignored	Temporary opt-out, which does not apply to target API 37
Back button	On Android 16 predictive back is on and `onBackPressed` is no longer called	Temporary opt-out in the manifest, no end date given
Full-screen layout (edge-to-edge)	On Android 16 the app can no longer opt out of it	None: the layout has to be adapted

With target 36 an app that locks the screen to portrait fills the window on tablets, foldables and resizable windows, with no bars at the sides; games and users who choose the original behaviour in the device settings are exceptions. Apps that intercept the back button with their own code must move to the supported APIs or set android:enableOnBackInvokedCallback to false.

Developer verification

From 30 September 2026 verification applies to users in Brazil, Indonesia, Singapore and Thailand, on certified Android devices, but only to installs from Google Play and from the stores of Honor, OPPO, Samsung, Transsion, vivo and Xiaomi: developers who have not verified their identity and registered their apps cannot have them installed from these stores. Other stores and directly downloaded APKs are outside this phase, and in 2027 verification will extend to all apps on certified devices. Google's pages name only those four countries: Italy is not one of them.

For developers on Google Play, a Google note of 15 July asks them to register in Play Console, by 30 September 2026, the apps not registered automatically (99% were), to avoid global removal from Google Play.

If you publish only on Google Play, you use the Play Console account you already have: with Play App Signing eligible apps are registered automatically, and apps in every form factor must be registered.
If you distribute both on and outside Google Play, the registration goes through Play Console; if only outside it, you need an Android Developer Console account, which costs 25 dollars for full distribution. To register a package you need an APK signed with the private key.
An organisation must give its website, verified with Google Search Console, provide documents confirming its identity and have a D-U-N-S number, which is free but can take up to 28 days.
The limited distribution account (up to 20 devices, no government ID and no fee) is meant for testing and personal use: in our view not for a business app.

For expert users there is an advanced flow, with a one-day wait, to install unverified apps; in our view it is not a path to ask customers or employees to follow.

Google warns that without the signing key packages cannot be registered, and strongly recommends a secure key management solution. We recommend knowing who holds the key before you start.

What it means for your project

The two obligations run on different timelines: target 36 matters at your next update, while the registration was due on 30 September and should be checked now on the Play Console home page. If the app also runs outside the store, for example as an APK handed to field staff, Google distinguishes managed devices (MDM or an Android Enterprise work profile), where registering private apps is not needed, from personal or unmanaged ones, where the Android Enterprise guide requires it.

What we check first

SpaceClub, the nightlife platform we develop as a product, has iOS and Android apps built with Flutter, so the Android store rules apply to us too. Our mobile app development goes as far as publication on the stores: if you ask us to check your app before a deadline, we start from two points that code does not settle, namely who owns the developer account and who holds the signing key. Registration links the package to the account and the key: if either is with a supplier who no longer works with you, that comes before everything else. Only then do we look at the code: target, libraries, the changes in the table, tests on a tablet.

The result is a written analysis with a quote and a roadmap agreed before we touch the code, then releases one at a time, each verifiable. One limit: identity verification is up to Google and uses the documents of the company that owns the account, so the registration starts with whoever owns it; we can prepare and follow it, not take their place.

What we do not know yet

It is unclear how it is going in the four countries: Android Headlines writes on 2 October that the rules are active, while Google's pages report no figures on blocked or removed apps.
For Europe Google speaks of 2027 and a global rollout, with no schedule per country.
We do not know whether the extension form is already available: Google's developer page, updated on 1 October, still says "later this year", with no date.
It is unclear how the obligation applies to private apps on unmanaged devices: the Android Enterprise guide gives 30 September 2026 without naming countries, while the developer pages name four.

If you want us to look at your Android app, read how we work in mobile app development or get in touch.

Sources

Got a project in mind?

Let us build it together

We can help you turn an idea into a digital product that is solid, fast and ready to grow.

Back to all articles