In this article

To fix a Play Billing deprecation warning, identify the Billing Library version packaged in your release, then upgrade the dependency that actually owns it. Updating a Flutter package declaration or forcing a Gradle version is not sufficient evidence that purchasing still works.

This is a release dependency audit, not guidance on bypassing Google's payment rules. The policy facts below were checked on October 8, 2026.

Read the deadline for the version you ship#

Google's current table lists Billing Library 7's new-app and update deadline as August 31, 2026, with an extension deadline of November 1, 2026. Version 8's corresponding deadline is August 31, 2027; version 9's is August 31, 2028. Existing installations are not automatically disabled when the new-submission deadline arrives. Check the official deprecation table and your Console notice.

Choose a supported version compatible with your integration. The newest version number is not a substitute for a migration plan. An extension requires the applicable Console process; do not treat the published extension date as permission for every app.

Follow the dependency to its owner#

In a Flutter application, the native Billing dependency may come through a purchasing plugin. Inspect the locked Dart package, its Android implementation and Gradle's resolved release dependency graph.

For example, from the Android project, use a read-only dependency report with the configuration that exists in your project:

sh
./gradlew :app:dependencyInsight \
  --dependency billingclient \
  --configuration releaseRuntimeClasspath

A flavored project may use a name such as productionReleaseRuntimeClasspath. If Gradle rejects the configuration, list the project's available configurations rather than copying this example blindly.

Your investigation should establish three facts: the requesting dependency, the selected native version, and why Gradle selected it. Retain the report beside the build identity. Compare it with the merged release manifest and the inspected artifact.

Upgrade the integration, not only the number#

Prefer a plugin release that explicitly supports the required native library. Read its migration notes and Google's Billing Library release history.

An override can change the selected binary without adapting the plugin's API calls or purchase handling. Use one only when you have established compatibility, documented why it is necessary and tested the complete purchase flow. Never describe an untested override as a safe universal fix.

Keep unrelated dependency upgrades out of this change. A small patch gives a failed transaction a shorter list of possible causes.

Test outcomes that affect customers#

Create a release checklist suited to the products you sell:

  1. A new purchase completes and produces the expected entitlement.
  2. Cancellation does not accidentally grant access.
  3. A pending transaction remains pending until the appropriate outcome.
  4. An interrupted session recovers without duplicate entitlement changes.
  5. An existing customer's purchase can be restored or recognized.
  6. Subscription changes follow the behavior your interface promises.

Use Google's supported testing environment and approved test accounts. These are proposed tests, not claims that we ran transactions against your application. Never log purchase tokens or customer identifiers in a public build report.

When the warning survives the upgrade#

Confirm that the uploaded version code belongs to the newly inspected artifact. Google also directs developers with persistent warnings to check the com.google.android.play.billingclient.version manifest metadata and whether manifest merging removed it. See the deprecation troubleshooting guidance.

Close the issue only when the resolved dependency, merged manifest, purchase behavior and Console result agree. For reviewing generated migration patches, use our AI code review checklist.