Every Android app that sells anything — a subscription, a one-time unlock, a coin pack — ships a copy of Google Play's Billing Library inside it. That library is not forever: Google retires each major version on a fixed two-year clock, and once your version is retired, the app still runs but you can no longer ship updates. As of August 31, 2026 the minimum supported version is Play Billing Library 8, and every release still built on version 7 or older has a single remaining window: the extension deadline of November 1, 2026.

This is the operational version of that migration: what the deprecation table actually says today, how to find out which version a given APK carries, the exact API renames that break the compile when you jump from 7 to 8 or 9, where the extension form lives, and what to test before you ship the build.

Four numbers decide this migration: 2 years — the deprecation cycle applied to every Play Billing Library major version since Google announced the policy at I/O 2019. August 31, 2026 — the date by which new apps and updates must use version 8 or later (this is the v7 deadline). November 1, 2026 — the extension deadline for the same version. 8 — the lowest version Google Play accepts in a new release today.

1. Where the deadline actually stands today

The banner on Google's own Play Billing Library version deprecation page reads: "By Aug 31, 2026, all new apps and updates to existing apps must use Billing Library version 8 or later. If you need more time to update your app, you can request an extension until Nov 1, 2026." That sentence is the whole rule, and it has two halves that people conflate.

The first half is a shipping restriction, not a removal: an app that still carries a retired version keeps working for the users who already installed it, but Play will not accept your new release. The deprecation FAQ states the corollary plainly — unmaintained APKs do not need updating, while new apps and updates must use a supported version. So the risk profile is not "my app disappears from the store." It is "I cannot ship the fix, the new store listing experiment, or the compliance update until this is done."

The second half is the escape hatch: the extension. It is requested from inside Play Console, and it is granted against the same fixed calendar date rather than a fresh countdown — so the practical question for anyone still on v7 in late September 2026 is not whether they have time, but whether the extension has already been filed.

2. The deprecation clock is fixed, and it is published in advance

Google has published the full deprecation table, and it is worth reading as a schedule rather than a warning. Each major version gets a "new app and update" deadline of August 31 and an extension deadline of November 1, two years later:

Two conclusions follow. First, an app that was already two versions behind in 2025 is now three behind, and it is the same amount of work today as it would have been then. Second, this is a permanent maintenance line item, not a one-off project: whichever version you pick this time, you will be back here again within two years. Scheduling the bump with your regular release train is cheaper than reacting to a Console warning.

3. Step 1 — find out what your release actually ships

Start with build.gradle. The Billing Library is declared as a dependency on com.android.billingclient:billing, and its version string is your answer:

dependencies {
    def billingVersion = "8.3.0"
    implementation "com.android.billingclient:billing:$billingVersion"
}

The deprecation FAQ adds one important detail: these dependencies only appear in APKs that require the com.android.vending.BILLING permission. In a multi-module project, or a portfolio where a handful of apps use an older shared module, the offending build is the one that declares billing — not necessarily the app you are thinking of. Audit every bundle that ships billing, not just the ones you remember writing payment code for.

There is also a second-place check that explains a stubborn warning. Play identifies the library version from the com.google.android.play.billingclient.version attribute in the merged AndroidManifest.xml. If you have already upgraded the dependency and the Console still reports a deprecated version, the official guidance is to confirm that attribute exists — manifest merging is the usual reason it goes missing.

4. Step 2 — pick your target: version 8 or version 9

The requirement is "version 8 or later", which means 8.x and 9.x both satisfy it. The trade-off is real, so make it deliberately.

If you are also reading this to plan the next cycle: v8's own deadline is August 31, 2027 with the extension to November 1, 2027. Migrating to 9.1.0 today buys the longest runway, and the v9 migration guide is written for teams arriving straight from 7 or 8.

5. Step 3 — the v7 → v8 migration itself

Per the official migration guide for Play Billing Library 8, the upgrade is three moves plus optional work.

Move one: bump the dependency. Point com.android.billingclient:billing at 8.0.0 or later (use the latest patch of the line, not the .0 release, unless you have a reason).

Move two: handle the renamed subscription APIs. These are the calls that break the compile when you come from PBL 6; the alternates are drop-in renames:

Move three: fix queryProductDetailsAsync. There is a signature change in ProductDetailsResponseListener.onProductDetailsResponse, which requires code changes in your implementation. The behaviour change behind it matters more than the signature: before 8.0.0, products that could not be fetched simply were not returned; with PBL 8 they come back carrying a new product-level status code that explains why — product not found, or no offers available to that user. If your UI previously inferred "this user is not eligible" from silence, it now has to read the status instead of guessing.

Also removed in PBL 8 if your code still calls any of them: queryPurchaseHistoryAsync (use the alternatives in Query Purchase History), querySkuDetailsAsync (use queryProductDetailsAsync), the parameterless enablePendingPurchases() (use enablePendingPurchases(PendingPurchaseParams)), and the old queryPurchasesAsync(String skuType, PurchasesResponseListener) overload. Readers on v6 or earlier who land directly on v8 also have to move off enableAlternativeBilling / AlternativeBillingListener / AlternativeChoiceDetails, replaced by enableUserChoiceBilling / UserChoiceBillingListener / UserChoiceDetails.

Optional, but worth taking: BillingClient.Builder.enableAutoServiceReconnection() lets the library re-establish the Play Billing service connection on its own instead of requiring you to call startConnection() again after a disconnect — the single most common source of "purchase button does nothing" reports on Android. The same release adds pending-purchase support for prepaid plans and virtual installment subscriptions.

6. Step 4 — or go all the way to 9.1.0

The migration guide for Play Billing Library 9 covers teams coming from 7 or 8. Beyond the dependency bump to 9.1.0, the recurring theme is that the legacy SKU vocabulary finally disappears (BillingClient.SkuType → ProductType, SkuDetails → ProductDetails, SkuDetailsParams → QueryProductDetailsParams, SkuDetailsResponseListener → ProductDetailsResponseListener, getSkuDetailsList/setSkuDetailsList → setProductDetailsParamsList), and one change lands directly on subscription revenue logic:

If you were using queryPurchaseHistoryAsync to decide whether a user qualifies for a free trial, the guide says to use ProductDetails.getSubscriptionOfferDetails() to determine which offers a user is eligible for.

Three smaller v9 changes are easy to miss. Blocked-Play-Store handling changed response codes: when the Play Store app itself is blocked (OEM kids modes, for example), the result code moved from ERROR to BILLING_UNAVAILABLE with a "Play Store is blocked" debug message, and this requires androidx.core version 1.9 or later to behave correctly. DeveloperProvidedBillingDetails.getLinkUri() is now @Nullable, so any code that launches that URI without a null and empty-string check is a live crash. And 9.0.0 adds in-app messaging for opt-in price increases, which shows users the outstanding increase without leaving the app — capped at one message every seven days.

7. Step 5 — the extension form, if you need it

If your app is still shipping an unsupported version, Play Console raises a warning. The extension is requested from the warning's details page: open Policy status, open the warning, and use the extension form linked there. Officially, this is the only route — there is no email request, and no second extension beyond the published November 1 date for the version in question.

Treat it as a shipping buffer inside an already-fixed deadline, not as additional runway. If you file the extension, the work still has to be done before November 1, 2026, and after that date new releases on v7 stop being accepted — including the compliance release you might be waiting on for a completely unrelated policy.

8. Step 6 — verify before you ship

Billing regressions do not show up as crashes; they show up as paying users who cannot buy. Before the release goes to production:

9. What the newer versions give back on the revenue side

The migration is billable work, so it is fair to count what the newer library unlocks. PBL 8.0.0 renamed "in-app items" to one-time products and added multiple purchase options and offers for them, which reduces the number of separate products you have to create to sell the same thing at different price points. It also added sub-response codes to launchBillingFlow(): PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS, USER_INELIGIBLE (the user does not meet the configured eligibility requirements for a subscription offer), and the default NO_APPLICABLE_SUB_RESPONSE_CODE — the difference between a vague "something went wrong" and a screen that tells the user to top up their card.

The 8.2.x and 8.3.0 releases (December 2025) added the external content links, external offers, and external payments APIs, and 9.1.0 added the Billing Choice APIs. If your roadmap includes any of those programs, the version jump is the prerequisite rather than a separate project — which is the practical argument for going to 9.1.0 while you are already in this code.

Sources