Google Play 2026: Target Android 16 or Lose New Users
5 Jun 2026 · 7 min read · Erik van Kammen
Google Play raises the floor every year, and if you do not keep up your app quietly stops reaching new users. The 2026 round is here: from August 31, 2026, new apps and updates have to target Android 16. On its own that is a manageable engineering task, but it rarely arrives alone. The same submission gets checked against the Data Safety section, the account deletion requirement, and the Play Integrity expectations, and any one of them can hold up a release. This is a practical pre-submission audit that walks through each requirement so your next Play upload goes through cleanly.
The target API level rule, and why it bites quietly
Google Play requires apps to target a recent Android version. The rule has two distinct effects that people often blur together.
For new apps and updates, there is a hard submission gate. From August 31, 2025, anything you submitted had to target Android 15 (API level 35) or higher. From August 31, 2026, that moves up: new apps and updates must target Android 16 (API level 36) or higher. There are narrower requirements for some form factors: Wear OS and Android Automotive OS trail one version behind the phone requirement, and Android TV trails further behind.
For existing apps, the effect is subtler and easier to miss. If your published app targets an API level below the current requirement, it stays installable for people who already have it, but it becomes invisible to new users on devices running a newer version of Android than your app targets. So an app that looks fine in the console can be silently losing its entire new-install audience.
| Date | New apps and updates must target | Form-factor exceptions |
|---|---|---|
| August 31, 2025 | Android 15 (API level 35) | Wear OS, Android TV, Android Automotive OS: Android 14 (API 34) |
| August 31, 2026 | Android 16 (API level 36) | Wear OS, Android Automotive OS: Android 15 (API 35); Android TV: Android 14 (API 34) |
If you need more time, Google has historically allowed developers to request a short extension, but that is a buffer, not an exemption. Plan the upgrade rather than relying on it.
What targeting a new API level actually involves
Bumping the target SDK is not just changing a number in your Gradle config. Each Android version tightens behavior, and targeting it means opting in to those changes. Newer releases bring stricter background-execution limits, changes to how you request permissions, foreground-service restrictions, and tighter rules on accessing shared storage and other apps. The work is in testing your app against those behavior changes, not in the version bump itself. Budget time to actually run your core flows on the target version before you submit.
The Data Safety section, where submissions stall
After the API level, the Data Safety form is the next most common reason a submission gets flagged. Every app on Play has to declare, in a structured form, what data it collects, what it shares, why, and how it is protected. The catch is that the declaration has to match what your app actually does, including the behavior of the third-party SDKs inside it.
The mistakes that cause problems are predictable. Teams under-declare, because they describe their own code but forget that an embedded analytics, ads or attribution SDK collects and shares data too. They let the declaration drift, because they add an SDK or a feature and never update the form. And they contradict themselves, declaring one thing on Play while their privacy policy or their actual network traffic says another. Google does compare these, and a mismatch is a flag.
The honest way to fill in Data Safety is to base it on what your binary really transmits, SDKs included, not on your memory of what you built.
The account deletion requirement
If your app lets users create an account, Play requires you to give them a way to request deletion of that account and its associated data, and to do it both inside the app and through a web link you provide in the console. Deleting the app is not enough, the user has to be able to delete the account and the data behind it. Apps that offer sign-up but no deletion path fail this check.
Play Integrity and anti-abuse expectations
Google has been steering developers from the older SafetyNet Attestation toward the Play Integrity API for checking that your app is genuine, unmodified and running on a legitimate device. It is not a universal hard requirement, but if your app handles payments, accounts or anything abuse-prone, integrity checks are increasingly expected, and relying on deprecated mechanisms is a slow-motion problem. If you have not looked at your integrity strategy recently, this is a good moment.
The pre-submission audit checklist
Run this before you push your next build to Play.
- Target API level. Confirm your build targets the current required level for your form factor, Android 16 for phones from August 31, 2026, and that you have tested your core flows against that version's behavior changes.
- Data Safety accuracy. Re-derive your declaration from what your app and its SDKs actually collect and share, and reconcile it with your privacy policy.
- SDK inventory. List every third-party SDK and its data behavior, because that is what feeds both the API-level behavior changes and the Data Safety form.
- Account deletion. If you offer accounts, confirm there is a working in-app deletion flow and a web deletion link in the console.
- Permissions. Check that every permission you request is actually used and justified, and that sensitive permissions have the required declarations.
- Integrity. Confirm you are not relying on deprecated attestation and that abuse-prone flows have appropriate integrity checks.
Why this is hard to keep right by hand
The recurring theme across all of these is that the thing being checked is what your app actually does, especially what its SDKs do, and that changes every time you add a dependency or ship a feature. A Data Safety form that was accurate last quarter can be wrong today because someone added an analytics SDK. A target level that was fine in early 2026 fails after August 31.
This is the kind of drift that automated scanning is good at catching. AppCompliance can analyze your Android build and the SDKs bundled into it, check the data they collect and share against your declared Data Safety information, flag target-level and permission issues, and surface integrity gaps before you submit. That turns the pre-submission scramble into a check that runs on every build, so a release is never held up by something you could have caught earlier.
For the cross-platform picture, the Android requirements here mirror a lot of what we cover on the iOS side in our WWDC 2026 compliance preview. Many of the same forces, privacy declarations, data transparency and SDK accountability, are pushing both stores in the same direction. The data behind your Data Safety form comes from your dependencies, which is the subject of our guide to auditing third-party SDKs.
FAQ
What target API level does Google Play require in 2026?
From August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. Wear OS and Android Automotive OS apps must target at least Android 15 (API level 35), while Android TV apps stay one level further behind at Android 14 (API level 34). The previous phone requirement, from August 31, 2025, was Android 15 (API level 35).
What happens if my app targets an older API level?
New apps and updates below the required level cannot be submitted. Already-published apps stay installed for existing users but become invisible to new users on devices running a newer Android version than the app targets, so you lose new installs.
Can I get an extension on the target API level deadline?
Google has historically let developers request a short extension if they need more time. It is a buffer, not an exemption, so plan the upgrade regardless.
Why does my Data Safety declaration keep getting flagged?
Usually because it does not match what your app actually does. The most common cause is forgetting that a third-party SDK collects or shares data, or letting the form drift after adding a feature or dependency. Base the declaration on real binary behavior.
Does Google Play require an account deletion option?
Yes. If your app supports account creation, you must offer account and data deletion both inside the app and via a web link in the Play Console. Removing the app alone does not satisfy this.
What is the Play Integrity API?
It is Google's mechanism for verifying that your app is genuine, unmodified and running on a legitimate device, replacing the older SafetyNet Attestation. It is increasingly expected for apps handling payments, accounts or other abuse-prone features.