Short answer: no, you should not panic, but you should act. This warning means that from August 31, 2026, you cannot publish any update to your app unless it targets Android 16 (API level 36) or higher. Your app is not being removed, your users lose nothing, and for most apps the fix is a one-line change plus one new release.
This guide explains the warning in plain language, then walks through the exact fix for native Android, Flutter, React Native, and Unity apps.
What you’re seeing in Play Console
In Policy status under Policy and programs, Google shows an issue called “App must target Android 16 (API level 36) or higher” with a red Action by Aug 31 tag. The message says your target API level must be within 1 year of the latest Android release.
Google does this every year. Each new Android version becomes the required target roughly one year after it ships. In 2026 that means Android 16, which is API level 36. If the page says something like “Your highest non-compliant target API level is Android 14 (API level 34)”, it simply means your latest release targets an older Android version than Google now requires.
First, the questions everyone asks
Will my app be removed from Google Play?
No. This warning does not remove your app. Your store listing stays live and everyone who has the app keeps it.
Do my current users lose anything?
No. Installed apps keep working exactly as before.
What actually happens after August 31, 2026?
You lose the ability to publish updates. Any new release that targets API 35 or lower will be rejected. On top of that, Google’s standing policy hides apps with very old target API levels from new users on newer devices, so an app that never updates slowly becomes invisible to new installs.
What if I don’t plan to update my app at all?
Then nothing changes on August 31. The warning only blocks future updates. But the day you need to ship a bug fix, you will have to do this migration first, so it is safer to do it now on your own schedule.
Is target API level the same as minimum SDK?
No, and this confuses everyone. minSdkVersion is the oldest Android version your app supports: you do not need to change it, and raising the target does not drop your older users. targetSdkVersion only tells Android which version’s rules your app promises to follow.
How to fix it, step by step
Step 1: Raise the target SDK to 36
Native Android (Kotlin/Java): in app/build.gradle (or build.gradle.kts):
android {
defaultConfig {
targetSdk 36
compileSdk 36
}
}Flutter: in android/app/build.gradle, set targetSdk = 36 and compileSdk = 36. Newer Flutter projects read flutter.targetSdkVersion, so updating Flutter itself and rebuilding is usually enough. Then run flutter build appbundle.
React Native / Expo: set targetSdkVersion = 36 and compileSdkVersion = 36 in android/build.gradle. On Expo, update to an SDK version that targets API 36 and rebuild with EAS.
Unity: File > Build Settings > Player Settings > Other Settings > Target API Level: set API 36, or “Automatic (highest installed)” with the latest Android SDK installed via Unity Hub.
Step 2: Test the behavior changes
Targeting a new API level opts your app into that version’s rules. These are the changes that most often break apps when moving to API 36:
- Edge-to-edge display is enforced. Your app draws behind the status and navigation bars, so check that buttons and text are not hidden behind system bars.
- Predictive back. If you override the back button, verify custom back handling still works.
- Stricter foreground service and exact alarm rules. Background tasks, timers, and reminders need the correct service types and permissions.
- Large-screen changes. On tablets and foldables, orientation and resizability restrictions are ignored, so test your layouts in landscape and split screen.
- Permissions. Anything touching photos, notifications, or location should be retested end to end.
Run the app on a real or emulated Android 16 device before shipping. Most apps need zero code changes, but the ones that break, break in these five areas.
Step 3: Publish one new release
Upload the new AAB and roll it out to production. Internal testing is the fastest way to sanity-check the build first. Once the update targeting API 36 is live in production, the policy warning clears automatically and Google sends a confirmation notification.
Good news about closed testing: if your app is already published, pushing this update does not restart the 12 testers for 14 days requirement. That requirement applies to new personal developer accounts publishing their first production release, not to updates of an app that already has production access. If you are still working toward your first production release, that is where the 12 testers for 14 days requirement applies, and Testers Community assigns verified testers within 6 hours.
What if you can’t make the deadline?
Play Console offers a Request more time button directly on the Issue details page, in the Action by Aug 31 panel on the right (you can see it in the screenshot above). If Google grants the extension, you get a few extra months to ship the update. Treat it as a safety net, not a plan: the fix itself is usually a one-line change plus testing, and extensions are not guaranteed for every app.
The timeline at a glance
| Date | What happens |
|---|---|
| Now until Aug 31, 2026 | Updates targeting API 35 or lower still accepted. Fix at your own pace. |
| Aug 31, 2026 | New updates must target API 36 or higher. Non-compliant uploads are rejected. |
| After Aug 31, 2026 | Existing app stays live for current users. Apps with much older targets stay hidden from new users on new devices. |
| Around this time in 2027 | The same cycle repeats for Android 17. Budget one target API bump per year. |
The target API deadline by the numbers
If the warning feels like an empty threat, the data says otherwise. Google has spent the last three years actively removing apps that do not keep up with target API requirements:
- There are about 1.89 million apps on Google Play as of July 2026, down from over 3.4 million at the start of 2024, a decline of roughly 47 percent, driven largely by Google removing low-quality and outdated apps [1][2].
- In Q1 2024 alone, about 409,000 apps were delisted from Google Play [3].
- In Q4 2022, 37 percent of Google Play apps were classified as abandoned (no update in more than two years). By Q3 2024 that number had fallen to about 332,000 apps, a 77 percent year-over-year drop [4]. Outdated apps are not being tolerated, they are being removed.
- Meanwhile, developers shipped about 67,300 new apps in June 2026 alone [1], so an app frozen at an old API level is competing against a constant stream of compliant new releases.
- Successful apps treat this as routine: of the top 1,000 apps on Google Play, 96 percent update at least once a year, 76 percent update monthly, and 38 percent update weekly [5]. The annual target API bump is just part of their normal release rhythm.
The takeaway in one sentence: the August 31, 2026 deadline to target Android 16 (API level 36) is part of an enforcement wave that has already halved the Play Store, and the way to stay on the right side of it is one small update per year.
Frequently asked questions
Does this apply to internal, closed, and open testing tracks too?
The enforcement targets updates you publish. Test tracks give you room to build and verify the new AAB first, which is exactly what Google recommends on the warning page itself.
My app was built by an agency or AI tool and I don’t have a developer. How hard is this?
For most apps it is a one-line configuration change plus a rebuild. Any Android developer can do it in under an hour, plus testing time.
Will raising the target API drop support for users on old Android versions?
No. That is controlled by minSdkVersion, which you are not changing.
How do I check my current target API level?
Play Console shows it on the warning page (“Your highest non-compliant target API level is…”). Or check targetSdk in your build.gradle.
I fixed it. How long until the warning disappears?
Once the release targeting API 36 reaches production, the issue clears and Google notifies you, usually within a day or two of rollout.
Ship the fix with confidence
If you want real users on real devices to verify your app before the update goes live, Testers Community’s network of 50,000+ developers can help. Verified testers are assigned within 6 hours and you get structured feedback on exactly the areas that break when target API levels change. Submit your app and ship the update without surprises.
