Kotlin and Compose at the current floor
We write new native Android apps in Kotlin with Jetpack Compose, and target Google's floor from the first build. So the app doesn't have to catch up with the floor the first time you submit it.
Android app development company in India
Android apps built for the Android version Google Play requires — code changes included.
Every Android app names the Android version it was built for. That is its target API level. Google Play takes a new app or an update for submission only when that number meets Google's minimum, which we call the floor. Google raises the floor on dates it names. We build new apps at the current floor and bring live apps up to it, and we handle the Android changes each rise switches on.
- Dates read from Google's own pages
- Releases that don't depend on one laptop
- We reply within one working day.
- Play Console Help: Target API level requirements for Google Play apps
- Android Developers: Meet Google Play's target API level requirement
- Android Developers: Behavior changes for apps targeting Android 16
In brief
- What it is
- Android app development in the Kotlin programming language, with Jetpack Compose for the screens. We build new apps at Google Play's current floor and bring live apps up to it.
- Why it matters
- Google Play sets a minimum target for new apps and updates, and raises it on dates it names. A live app's next update, even a one-line fix, can wait on that number.
- What you get
- A build that meets the current floor, the Android changes it switches on handled in code, and a release process that doesn't depend on one person.
What we do
A new app built at the floor, or a live app brought up to it.
For a new app, three early decisions set how much work each later rise in the floor will take. For a live app below the floor, the four steps further down show how we bring it up.
Your Android range, agreed up front
We agree with you which devices and Android versions the app must run on. The oldest one sets the app's minimum API level. We write that decision down, and later changes to the target don't alter it.
A release process not tied to one laptop
Builds and store submissions run from a release process that doesn't depend on one person's machine. So an update with a raised target isn't stuck when that person is away.
One codebase for iPhone and Android? See Flutter or React Native. Once the app is live, later moves to a higher floor can sit inside app maintenance and support. To check what the app stores and sends, see our mobile app security assessment.
The API level floor
The number is one line. What it switches on is the work.
Every Android app declares a target API level: the Android version its code was written to run against. Changing that number is one line in the build. But Android applies some of each version's changes only to apps that target that version. A raised target takes them all on at once, and handling them is the real job.
What that means for your app
- It applies however the app is built. A cross-platform app meets the same floor, since Google sets the rule on the app, not the language.
- Skipped versions add up. An app several versions behind takes on every skipped version's changes in one go.
Apple sets its own terms for its store, covered on the iOS app development page.
Google's dates
These are the dates Google Play has set.
Each date is Google's own. On September 15, 2026, Google's page gave no date for any floor above API level 36. We read the page again when your work is planned.
| Date | Applies to | What Google says |
|---|---|---|
| Aug 31, 2026 | New apps and app updates | They must target Android 16, API level 36, or higher before Google Play takes them for submission. Wear OS, Android Automotive OS, Android TV and Android XR apps get lower floors. |
| Aug 31, 2026 | Apps already published | An app targeting below API level 35 is no longer offered to new users whose devices run a newer Android version than it targets. People who installed it keep it. |
| Nov 1, 2026 | Developers who need more time | They can request an extension to November 1, 2026. |
An app already live
We bring a live app up to Google's floor in four steps.
If your live app is below Google's floor, we raise its target in this order, whoever built it.
Assess the codebase and its dependencies
Taking over starts with a short assessment: the target and minimum API levels, and every library that draws screens or handles the back button.
Read the floor on Google's page
The level and its date come from Google's target API level page when the work is planned, not from memory, because Google sets both there.
Take each skipped version in turn
A raised target takes on every skipped version's changes at once, so we work through them in order. The table below shows two of the changes Android 16 brings.
Run both ends of the agreed range
The raised build runs on an Android 16 device, where the new behavior applies, and on the oldest version in the agreed range, where the old behavior still holds.
Android 16 changes
Raising the target to API level 36 changes how an existing app behaves.
Google's Android Developers site lists several changes for apps that target Android 16. Two of them, screen edges and the back button, are below, with what the build has to contain.
| Where it lands | What changes at API level 36 | What the build has to contain |
|---|---|---|
| Screen edges, Android 16 | The edge-to-edge opt-out is disabled | System bar insets handled on every screen |
| Screen edges, Android 15 | The old opt-out still works there | No opt-out, one layout for both |
| Back navigation, Android 16 | onBackPressed not called, KEYCODE_BACK not delivered | Back logic on supported back APIs |
| Back code not yet migrated | A manifest opt-out, for now | Migration; the opt-out only as a stopgap |
The terms in this table, in plain words
- Edge-to-edge: the app draws its screens behind the status bar and the navigation bar.
- System bar insets: the space those bars take up, which each screen must handle so nothing important sits underneath.
- onBackPressed and KEYCODE_BACK: older ways an app learns that the user pressed back.
- Manifest: the file in which an app declares its settings, including its target API level.
An app coming from API level 34
An app still at API level 34 never had edge-to-edge enforced. At API level 36 it gets enforcement, with no opt-out on Android 16 devices. It takes on Android 15's changes too, which is why we work through the skipped versions in order.
What meeting the floor does not do. It makes an update eligible for submission, and nothing more. Review stays Google's decision, and no build settles that.
FAQ
Questions about Google Play's target API level.
Deadlines, approval and cross-platform apps. For anything else, ask us directly.
Google's Play Console Help page sets API level 36, Android 16, as the minimum target for new apps and app updates submitted from August 31, 2026. Wear OS, Android Automotive OS, Android TV and Android XR apps have lower floors. Developers needing more time can request an extension to November 1, 2026.
It depends how far behind the app is. At API level 35 it stays available, but Google requires API level 36 before an update can be submitted. Below API level 35, Google says new users on Android versions newer than its target can no longer find or download it; existing users keep it.
Raising the target opts existing code into behavior Android holds back from apps on older targets. For Android 16, Android Developers lists, among others, that the edge-to-edge opt-out stops working on Android 16 devices and that onBackPressed is no longer called there. An app coming from API level 34 takes on Android 15's changes too.
No. The target API level is a condition for submitting a new app or an update, and review is a separate decision that stays with Google. A build can meet the floor, but nobody outside Google can say in advance what review will conclude. Meeting it only means the submission can be made.
Yes. Google's page says each app specifies its target API level in its manifest, so the floor applies to the app Google Play receives, whatever built it. A React Native or Flutter app meets the same floor as a Kotlin one. How much of each Android change the framework absorbs is for its own documentation to say.
Ask what the app targets today and which Android versions it must still run on. Ask which libraries draw its screens or handle back, since they meet Android's changes too. Ask where the next floor's date will come from; it should be Google's page. And ask how an update ships when whoever set up releases is away.
Let's talk
Tell us about your Android app, new or already live.
Planning a new app? Tell us what it must do and the oldest Android version it has to run on. Already live? Send the API level it targets now, or ask your developer for it. Project work is delivered remotely from India during business hours. We reply within one working day.