Play Billing Library 8 Required: Upgrade Before Updates Are Blocked

On this page (7 sections)

The requirement and the schedule

Play Billing Library support timeline — each row is the last date that version may be used
PBL version	Last date new apps and updates may use this version	Extension available until
6	31 August 2025	1 November 2025
7	31 August 2026	1 November 2026
8	31 August 2027	1 November 2027
9	31 August 2028	1 November 2028

Read the table as a cut-off, not a target. Each date is the last day Google accepts a new app or an update built on that version, which is why version 7’s 31 August 2026 cut-off is what makes version 8 the minimum today. An extension defers the block on your app for that older version; requesting one is not the same as having one granted, and it does not move the version requirement. Apps on a deprecated version see a warning in Play Console, and after the deadline the release cannot be distributed — but existing installs keep processing purchases. The block is on shipping, not on the apps already out there.

Google’s deprecation FAQ puts the current requirement this way: by 31 August 2026 all new apps and updates to existing apps must use Billing Library 8 or later, with an extension available on request until 1 November 2026 (paraphrased — read the support timeline for the wording that applies to your app).

Find out which version you actually ship

Native Android: com.android.billingclient:billing:<version> in Gradle — but check the resolved version (./gradlew app:dependencies); a plugin or SDK can pin an older one.
Unity: the Unity IAP package version determines the embedded PBL; old Unity IAP releases carry PBL 4–6.
Flutter: in_app_purchase_android — its changelog states the PBL version it wraps.
React Native: react-native-iap — likewise; some forks pin old versions.
RevenueCat / Adapty / Qonversion: the SDK version fixes the PBL version; upgrade the SDK.
Play Console: the policy status message names the deprecated version detected in the uploaded bundle.

Quickest first pass: paste the dependency block from your build file into the update readiness checker. It picks the billing dependency out of Gradle, version catalogues, pubspec.yaml and package.json and tells you whether the declared version still meets the requirement. A wrapper SDK can still pin something older underneath, so treat a clean result as a starting point, not a clearance.

What changes on the way to version 8

API changes that force code changes when moving an old integration to PBL 8
Version	Removed or changed	What your code must do instead
5 → 6	queryPurchases() removed; launchPriceChangeFlow() removed; ProrationMode superseded by ReplacementMode; order IDs no longer created for pending purchases	Use queryPurchasesAsync(); handle pending purchases without an order ID until PURCHASED
6 → 7	ProrationMode and setOldSkuPurchaseToken() removed; enableAlternativeBilling() removed; queryPurchaseHistoryAsync() deprecated; minSdk 21, targetSdk 34	ReplacementMode + setOldPurchaseToken(); user-choice billing APIs; track consumed purchases server-side
7 → 8	querySkuDetailsAsync() and the SkuDetails flow removed; queryPurchaseHistory() removed; enablePendingPurchases() without parameters removed; queryPurchasesAsync(String, …) removed; onProductDetailsResponse() signature changed (unfetched products returned with a status)	queryProductDetailsAsync() with ProductDetails everywhere; enablePendingPurchases(PendingPurchasesParams); handle per-product status codes; “in-app items” become one-time products with purchase options
8.1	minSdk 23; suspended subscriptions surfaced (Purchase.isSuspended()); subscription replacement moves to SubscriptionProductReplacementParams	Do not grant entitlements for suspended subscriptions; update upgrade/downgrade flows

Source: Android Developers, Google Play Billing Library release notes and the deprecation FAQ (page verified 22 September 2026; the support timeline in the table above was re-checked against the deprecation FAQ on 29 September 2026).

Side-effects to plan for

Backend verification. If your server still validates purchases with the legacy purchase-history or SKU-based assumptions, it needs updating alongside the app; Real-time Developer Notifications and the Play Developer API remain the source of truth for subscription state.
Entitlement logic. Pending purchases, suspended subscriptions and unfetched products all return new states that an old integration silently mishandles.
Product configuration. One-time products with multiple purchase options and subscription base plans/offers must be set up in Play Console and referenced by the new IDs.
Toolchain cascade. PBL 8.1 requires minSdk 23 and a current Kotlin; in Unity, Flutter and React Native the upgrade path runs through the framework upgrade — see legacy app update.
Policy. The upgrade is a good moment to confirm the app follows the Payments policy (digital goods through Play Billing, user-choice or alternative billing only where eligible) — the reason for the separate payments-policy library entry.

Test every purchase path in the sandbox before rollout

Billing regressions are expensive: a broken restore flow or a missed acknowledgement means refunds and one-star reviews. Use license testers, test subscriptions with accelerated renewals, pending-purchase test cards and a staged rollout.

What we do

Identify the shipped PBL version (resolved dependencies, plugin versions) and inventory every call site: product queries, launch flow, acknowledgements, consumption, restore, subscription upgrades.
Map each call to its version-8 equivalent and to the backend logic it depends on.
Implement the upgrade in native code or the framework plugin, update the server verification, and re-test in the Play sandbox with license testers.
Request the Play Console extension if the release date is at risk, then ship with a staged rollout.

Upgrade checklist

Resolved dependency tree shows billing:8.x (or the framework plugin that wraps it)
No remaining SkuDetails, querySkuDetailsAsync, queryPurchaseHistory or parameterless enablePendingPurchases calls
Product-level status codes from queryProductDetailsAsync handled
Suspended and pending purchases do not grant entitlements
Server-side verification and RTDN handling updated and tested
Products, base plans and offers configured in Play Console with the new identifiers
Sandbox tests pass for purchase, restore, upgrade/downgrade, cancellation and refund paths

Frequently asked questions

How do I find out which Play Billing Library version my app actually ships?

Check the resolved version, not the one written in your build file — a plugin or SDK can pin an older one. On native Android, ./gradlew app:dependencies shows what is really linked. Otherwise the version is decided by whatever wraps it: the Unity IAP package, in_app_purchase_android on Flutter, react-native-iap on React Native, or a subscription SDK such as RevenueCat, Adapty or Qonversion. Play Console's policy status message names the deprecated version it detected in your uploaded bundle.

Purchases still work. Why upgrade the Billing Library at all?

Because the block is on publishing, not on purchasing. Google deprecates each Play Billing Library version two years after release, and since 31 August 2026 new apps and updates that sell in-app products or subscriptions must use version 8 or later. Existing installs keep working; your next release does not go out. An extension can be requested per app until 1 November 2026.

Is upgrading to Play Billing Library 8 a breaking change?

Usually yes, if you are coming from version 4–6. Version 8 removed the SkuDetails-era APIs, so product listing and purchase launching have to be rewritten against ProductDetails, and product details and pending purchases are handled differently. Plan for changes in the purchase flow, the restore path and server-side verification, plus a full test pass on real purchases rather than only on the happy path.

Related: Play Billing Library 8 Upgrade