Fix the Target SDK 36 Warning by Google in WebViewGold

A notice landed in your Play Console: your app’s Target API Level won’t be sufficient after Aug 31, 2026. From that date, new apps and app updates must target Android 16 (API level 36) or higher to be published on Google Play. Existing apps must target at least Android 15 (API level 35) to remain visible to new users on devices running a newer Android version.

Three details matter more than the scary wording:

• Existing users are unaffected. Anyone who already has your app installed can keep using it, update it, and reinstall it, regardless of its Target API Level.
• This is about visibility for new installs, not functionality. Apps below API 35 become invisible or uninstallable for new users on devices running a newer Android OS. Your app keeps working — it just stops being discoverable to new customers.
• An extension is available. Google lets developers request an extension until Nov 1, 2026 through a form in Play Console, if you can’t make the August deadline.

Android 16 also brings two technical side effects that kick in the moment you target API 36: stricter rules for full-screen notifications (USE_FULL_SCREEN_INTENT), and support for devices with 16 KB memory pages, which requires native libraries to be aligned accordingly.

Why your app got flagged even though you never touched anything

The Target API Level is baked into your app’s Android manifest at build time — it’s not something you configure in your web app or in WebViewGold’s settings directly. Google simply checks what number is set when you upload the AAB. That’s why the warning hits practically any app that hasn’t been rebuilt in a while, whether or not you’ve actively worked on it recently.

The current WebViewGold Android template already targets a level that meets the requirement, and it’s kept current with every release. Any Android build you produce with the latest WebViewGold version automatically carries the correct Target API Level — there’s no manifest or native code to touch yourself.

Which means the entire fix is, once again, producing one new build — either through Cloud Builder or manually in Android Studio.

Clear it in four steps (Cloud Builder)

1. Increase your version code. In your WebViewGold Cloud Builder project settings, go to the app configuration and increase the version code. Do this first — Google Play rejects any bundle that reuses a version code it has already seen.
2. Rebuild. Trigger a new Android build in Cloud Builder. It compiles a fresh AAB against the current WebViewGold template, which already targets the required API level.
3. If automatic deployment to Play Console is enabled, the new AAB is uploaded for you. Within 10 to 15 minutes it should appear in your Play Console, either in the latest releases overview or on the Internal testing track.
4. If you don’t see it there, upload manually. Take the AAB from your Cloud Builder download and upload it yourself: Play Console > Test and release > Internal testing > Create release, attach the AAB, and roll it out.

Once the build is on a track, promote it to Production the same way you release any update. Normal Google review time still applies, so leave enough runway before the deadline.

Clear it manually in Android Studio

If you maintain your own Android Studio project from the WebViewGold source template rather than using Cloud Builder:

1. Pull the latest WebViewGold Android template. Update your local project to the newest WebViewGold release so compileSdkVersion and targetSdkVersion are current.
2. Bump the version code. In your app-level build.gradle, increase versionCode (and typically versionName). As above, Google Play will reject a bundle that reuses a version code already seen.
3. Check native dependencies (16 KB page size). If you bundle your own native libraries, make sure they’re built against the current NDK and aligned for 16 KB memory pages.
4. Sync and rebuild the AAB. Run a Gradle sync to pull in the updated dependencies, then build a signed release bundle via Build > Generate Signed Bundle / APK.
5. Upload to Play Console. Go to Test and release > Internal testing (or your usual track) > Create release, attach the new AAB, and roll it out.

Promote the same build to every track you actively use, then to Production following your normal review process.

Two things that quietly keep the warning alive

An old bundle on a forgotten track. The requirement applies across all your tracks. If you roll out to Production but an old AAB is still the active release on internal, closed, or open testing, the app stays flagged. Promote the same new build to every track you actively use.

“Version code has already been used” on manual upload. If you try to upload the AAB by hand and Play Console rejects it with this message, that’s not a failure. It usually means an automatic deployment (Cloud Builder) already delivered the build, and it’s sitting on one of your tracks. Find it in the releases list and roll it out from there instead of rebuilding.

After the new build is live across your tracks, the warning clears on its own. It can lag a few days behind the rollout, so don’t wait for August to do this.

Try WebViewGold

Turn your website into a native iOS and Android app in minutes, with native features, push notifications, and in-app purchases — no separate mobile codebase to maintain.

Learn more at webviewgold.com