A notice landed in your Play Console: your app uses a version of the Google Play Billing Library that will be deprecated soon, and from Aug 31, 2026 all apps must use version 8.0.0 or later. If your app is built with WebViewGold, this is not a code problem and there is nothing to migrate. The fix is a version bump and a rebuild — about ten minutes of your time, whether you use Cloud Builder or Android Studio. Here is what the warning actually means and the exact steps to clear it.
Google deprecates old major versions of the Play Billing Library on a rolling schedule. The current round says that from Aug 31, 2026, Play will reject any new app update that still carries a billing library below 8.0.0.
Two details matter more than the scary wording:
- The check runs against the newest app bundle sitting on your tracks. Play scans what is inside the AAB, so the warning is telling you about the build you uploaded months ago, not about anything you did recently.
- The deadline only gates new submissions. Your live app keeps working for users after Aug 31, 2026 either way. What you lose, if you do nothing, is the ability to ship updates.
Google’s notice also recommends moving to version 9. The requirement is 8.0.0 or later, and that is the bar that clears the warning.
Why your app got flagged when you never touched billing code
The Play Billing Library ships inside the WebViewGold Android template as part of its in-app purchase integration. It is there so that apps selling through Google Play can do it with a simple native bridge call, but Play does not check whether you actually use it. It checks which version is present in the bundle. That is why apps that handle payments entirely outside Google Play — through Stripe or any external checkout — get the same warning as apps selling subscriptions through the Play Store.
The current WebViewGold Android template bundles a Billing Library version comfortably past the 8.0.0 requirement, and that version is kept current with each template release. Any Android build you produce with the latest WebViewGold version carries a compliant library automatically — you do not need to touch billing code yourself.
Which means the entire fix is producing one new build, either through Cloud Builder or a manual Android Studio build.
Clear it in four steps (Cloud Builder)
If you use WebViewGold’s Cloud Builder, this is the fastest path:
- 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, so a rebuild without a bump has nowhere to go.
- Rebuild. Trigger a new Android build in Cloud Builder. It compiles a fresh AAB against the current WebViewGold template, which already includes the compliant Billing Library version.
- 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.
- If you do not 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. Google’s review applies as usual, so leave normal review time 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:
- Pull the latest WebViewGold Android template. Update your local project to the newest WebViewGold release so the bundled Billing Library dependency is current.
- Bump the version code. In your app-level
build.gradle, increaseversionCode(and typicallyversionName). As above, Google Play will reject a bundle that reuses a version code already seen. - 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.
- 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 is not a failure. It usually means an automatic deployment (Cloud Builder) already delivered the build, and it is 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 do not 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
