Your app disappeared from Google Play for new users? You haven't been banned — the API 36 deadline has passed

No, you haven't been banned

If in the last few days you've seen a red warning in Google Play Console, a drop in installs, or had a client call to complain that "the app isn't in the store" — don't panic. You haven't been banned, you haven't broken the rules and nobody has reported you.

On 31 August 2026 Google Play's annual target API level deadline passed. It applies to every Android app and each year it cuts off from the store those that haven't kept up with the required system version. This year the threshold is particularly painful, because it covers two different things at once.

Below: what exactly happened, how to check in five minutes whether it affects your app, how much time you realistically have and what needs to be done.

What exactly changed on 31 August 2026

There are two requirements and they are easy to confuse — yet they determine which situation you're in.

1. New apps and all updates must target Android 16 (API 36) or higher. From that day on, you can't upload a new version of an app to Play Console if it targets anything lower. Even if the fix is for a single typo.

2. Existing apps must target Android 15 (API 35) or higher to remain available to new users on devices running a newer Android version than the app's target.

In other words: one threshold blocks releases, the other blocks distribution. You can meet the first and not the second, and vice versa.

For selected device categories the thresholds are more lenient:

The only apps exempt from the requirement are permanently private ones — distributed solely within a single organisation.

"It's gone from the store" — what that really means

This is the most common misunderstanding, and it makes people panic more than they should — or less than they should. The app has not been removed from Google Play. Reviews, ratings and install history don't disappear either.

What actually happens to an app below the availability threshold:

• It remains visible and installable only on devices running an Android version equal to or lower than the app's target API.
• New users with newer phones won't see it in Play search or be able to install it from a link. For them the app practically doesn't exist — and these are usually the users who bought their phone in the last two years.
• Existing users don't lose the app. The installed version keeps working; nobody deletes it from anyone's device.

So the practical effect is this: the app still works, but it has stopped growing as an acquisition channel. You won't see a crash message — you'll see a drop in new installs that nobody can explain. If you run campaigns pointing to Play, part of your budget has been going down the drain for several days now.

Diagnose yourself in five minutes

It all comes down to one number: what the targetSdk is in the version you last published.

Method 1 — Play Console (no developer needed)

Log in to Google Play Console and check two places:

1. Notifications and the policy compliance section — if the app doesn't meet the requirement, Google displays a warning there with a specific deadline and an indication of which threshold it concerns. This is the quickest answer.
2. App bundle explorer → the selected release → package details. There you'll find the target API level for every uploaded version.

Method 2 — source code

If you have access to the repository, open app/build.gradle.kts (or app/build.gradle) and look for:

android {
    compileSdk = 36
    defaultConfig {
        minSdk = 24
        targetSdk = 36   // ← this number
    }
}

In Flutter projects the file is at android/app/build.gradle.kts; in React Native — in android/app/build.gradle or in android/build.gradle as targetSdkVersion.

Method 3 — from a built APK/AAB file

If you only have a built file rather than the code:

# from Android SDK build-tools
aapt2 dump badging app.apk | grep targetSdkVersion

# or
apkanalyzer manifest target-sdk app.apk

Interpreting the result

How much time you have: extension to 1 November 2026

Google has built in a safety valve. If you need more time, you can request a one-off extension of the deadline to 1 November 2026.

What you should know:

• The request is submitted in Google Play Console — the form is available in the context of the app that the target API level warning concerns.
• The extension is one-off. There is no further deadline after 1 November — after that date the situation reverts to what it was before the request.
• The request doesn't get the work done for you; it only buys about two months. For a neglected project that's a realistic minimum; for a maintained one, it's breathing room.
• Submit it even if you think you'll make it in time. It costs nothing and takes the pressure off the team.

If you don't have access to Play Console or don't know who does — that's a separate, more serious problem. We'll come back to it at the end.

What it really takes to raise the target to API 36

The bad news: this isn't a matter of changing one number in the configuration. Raising targetSdk switches on new system behaviours that your app could previously ignore. Three changes in Android 16 cause the most trouble:

1. Enforced edge-to-edge. For apps targeting API 36, the option to opt out of drawing under the status and navigation bars has been removed — the windowOptOutEdgeToEdgeEnforcement attribute no longer has any effect. The app must handle insets correctly, i.e. know where the safe area of the screen ends. Symptoms if neglected: buttons slipping under the navigation bar, headers under the clock, unclickable elements near the edges.

2. No more forcing orientation and aspect ratio on large screens. On displays with a smallest width of 600dp or more (tablets, foldables), the system ignores screenOrientation and resizableActivity declarations as well as aspect ratio restrictions. The app fills the entire window regardless of whether it was prepared for that. An app designed exclusively for a phone in portrait will look bad on a tablet — and you can no longer block this with a manifest declaration (a temporary escape hatch exists, but it's transitional).

3. Stricter JobScheduler quotas. Quotas are enforced more rigorously, and setImportantWhileForeground no longer does anything. If the app syncs data in the background, some jobs may stop running the way they used to.

On top of that comes the part that usually takes the most time in neglected projects: updating Gradle, the Android Gradle Plugin, libraries and the entire framework. In Flutter and React Native projects, raising the target API usually forces a framework version upgrade, which in turn drags in a dependency migration. If the project hasn't been updated for two years, this is where 80% of the work lies — not in API 36 itself.

How long it takes

The honest answer: it depends almost entirely on how long ago the app was last updated.

If you're in either of the bottom two rows — request the extension today. Two months is the difference between a calm migration and a version rushed out to production without testing.

We write more about how to recognise the last row of this table in your own project in 5 signs your mobile app is quietly dying.

Worst-case scenario: there's nobody to do it

In many companies this alert lands in an organisational vacuum. The app was built by an agency you've lost touch with. The developer who looked after it left a year ago. Nobody knows where the repository is.

The rescue order in this situation differs from the technical one — first regain control, then deal with the code:

1. Check who owns the Google Play Console account (Users and permissions) and whether the contact address is monitored by someone who still works for you. Without console access you can't even request the extension.
2. Find out where the signing key is. If the app uses Play App Signing, you're safe. If it uses a local keystore that nobody has ever seen — that's a bigger problem than the target API, because without it you can't release any update at all.
3. Locate the repository and check whether the project builds on a clean machine. This can be a separate task taking several days.
4. Only then plan the migration to API 36.

You can tick off points 1–3 yourself in a single day. We've put together a full checklist of your app's health in Will your app survive 2027? A 15-point checklist.

How not to end up here again next year

The target API level deadline is a recurring event, not a one-off crisis. Google raises the threshold every year, with the deadline falling at the end of August, and the required level corresponds to the Android version from a year earlier. So you know months in advance what will be required.

Three things that close the topic for good:

1. A calendar entry for May–June every year. By then the new Android version is already in preview, and you have three months of calm work instead of two weeks of panic.
2. A release every quarter, even without new features. Just dependency updates. It's the cheapest insurance policy there is — and at the same time a guarantee that the build works and someone knows how to run it.
3. Named responsibility for the Play Console and App Store Connect inboxes. An alert that nobody reads isn't an alert.

It's worth keeping the same calendar for iOS — every year, usually in spring, Apple requires apps to be built with the latest public SDK.

Quick FAQ

Has my app been removed from Play? No. It remains available on devices running an Android version no higher than its target API. New users with newer phones won't see it.

Will I lose my ratings and reviews? No. Your store listing, ratings, reviews and install history remain intact. Once you raise the target API, the app returns to full distribution.

Will existing users lose the app? No. The installed app keeps working.

My target is 35 — do I need to do anything? The app is available to new users, but you can't release any update until you raise the target to 36. If a critical bug appears you'll be helpless, so treat this as urgent, not optional.

Is there any risk in requesting an extension? No. It's a mechanism provided by Google, not an admission of guilt. It moves the deadline to 1 November 2026, once.

Does this also apply to internal company apps? Permanently private apps, distributed solely within an organisation, are exempt from the requirement. If the app is publicly available on Play — it applies.

Summary

31 August 2026 wasn't an exception — it was another instalment of an annual deadline that, for some apps, ends with them quietly vanishing from new users' reach. The good news: nothing is lost, nothing has been deleted, and Google offers an extension to 1 November 2026.

Three things to do today:

1. Check your targetSdk — five minutes in Play Console.
2. If it's below 36, request the extension — even if you believe you'll make it in time.
3. Estimate the effort honestly — if the app hasn't had a release in two years, the work isn't a single number in the configuration.

At Mobilesoft we carry out migrations like this regularly, including on projects we didn't write — from recovering access and getting the environment running to catching up on outdated dependencies. See how we approach building and maintaining mobile apps, and if you first need an assessment of the app's state and an effort estimate — we handle that as part of our audits and consulting. You can also browse our case studies or go straight to getting a quote.

If you've got a red alert on your screen and don't know how big a problem it is — get in touch. Checking an app's state and estimating the effort usually takes us one day, and at least you'll know what you're dealing with before 1 November.