Play Billing Library 8 by 31 August 2026: every removed API and the migration path

Summary. From 31 August 2026, Google Play will not accept a new app or an app update that builds against Google Play Billing Library 7 or lower, and eligible developers can request an extension only as far as 1 November 2026. That is 27 days from 4 August 2026. Ten previously deprecated APIs are gone in PBL 8, including querySkuDetailsAsync, the no-argument enablePendingPurchases() and the queryPurchasesAsync(String, PurchasesResponseListener) overload. The same 31 August date also gates the target API level 36 requirement, so most Android teams have one release train to plan, not two. Google's published deprecation table gives every version a two-year window: PBL 8 runs to 31 August 2027 and PBL 9 to 31 August 2028. Google Play's fee structure changed underneath all of this on 30 June 2026, when the service fee split from a separate 5% billing fee in the United States, United Kingdom and European Economic Area, starting at 10% on a developer's first $1M (USD) of annual earnings. In India the older 15% and 30% bands still apply.

The deadline is a publishing gate, not a kill switch. An app already on the Play Store that ships PBL 7 keeps transacting after 31 August 2026. What stops is your ability to ship anything new: a bug fix, a price change, a security patch, a compliance release. For most teams that is worse than a runtime break, because it lands at the exact moment you need to ship.

What actually happens on 31 August 2026

Google's version deprecation page carries a standing reminder: by 31 August 2026, all new apps and updates to existing apps must use Billing Library version 8 or later, with an extension available on request until 1 November 2026.

Three consequences follow, and teams routinely confuse them.

Your published binary is untouched. Users on an existing install continue to buy, subscribe, restore and cancel through PBL 7 code. Google has never broken live purchase flows on a deprecation date, and the deprecation page says so directly: existing apps still work.

Your release pipeline stops. Any bundle uploaded on or after the cutoff that declares a Billing Library version below 8 is rejected at the Play Console. If your app has an active com.android.vending.BILLING permission, this applies to you.

Your extension is not automatic. Google surfaces a warning in the Play Console for apps on an unsupported version, and the extension form sits on that warning's details page under Policy status. You have to go and get it. The extension buys 62 days, to 1 November 2026, and nothing more.

One quiet failure mode is worth checking before you assume you are already compliant. Google's guidance is that the deprecation warning keys off the com.google.android.play.billingclient.version attribute in AndroidManifest.xml. If manifest merging strips that attribute, an app that has genuinely upgraded can still be flagged. Teams with heavy multi-module builds or aggressive manifest placeholders hit this more often than they expect.

The deprecation clock is a schedule, not an event

Every Play Billing Library version gets a two-year support window. Google announced the cycle at Google I/O 2019 and restated it in the Meet Google Play Billing Library Version 3 post in June 2020. The published table is the single most useful artefact for planning, because it tells you exactly when the next wall arrives.

Read the last two rows before you decide what to upgrade to. Moving from PBL 7 to PBL 8 buys twelve months of publishing headroom. Moving from PBL 7 to PBL 9 buys twenty-four. The engineering delta between those two choices is smaller than most teams assume, and we come back to it below.

Every API removed in PBL 8

Google's PBL 8 migration guide splits removals into two groups: a set that bites anyone coming from PBL 6, and a set that bites everyone.

The subscription-parameter removals apply only if you are jumping from PBL 6.

The second group is the one that matters for the 31 August deadline, because it applies whether you are on PBL 6 or PBL 7.

That is ten distinct removals across the two tables, and the last three only apply if you already run an alternative billing flow.

The code you actually have to change

Start with the dependency. Google's own PBL 8 snippet is minimal.

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

Then work through the compiler errors in roughly this order, because each one cascades.

The BillingClient builder changes first. The no-argument enablePendingPurchases() is gone, and Google documents the exact behavioural equivalent, which is useful because it means you can migrate without changing what your app does:

            // PBL 7 and earlier — removed in PBL 8
val client = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases()
    .build()

// PBL 8 — functionally equivalent to the removed call
val client = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(
        PendingPurchasesParams.newBuilder()
            .enableOneTimeProducts()
            .build()
    )
    .build()
          

If you deliberately want pending prepaid-plan subscriptions as well, that is a separate opt-in rather than a default, and Google covers it under handling subscriptions and pending transactions.

The entitlement query changes next. The old string-typed overload is gone, so anything that passed BillingClient.SkuType.SUBS as a raw string has to move to the params object:

            // Removed in PBL 8
client.queryPurchasesAsync(BillingClient.SkuType.SUBS) { result, purchases -> /* ... */ }

// PBL 8
val params = QueryPurchasesParams.newBuilder()
    .setProductType(BillingClient.ProductType.SUBS)
    .build()

client.queryPurchasesAsync(params) { result, purchases ->
    // handle active and pending purchases
}
          

The catalogue fetch is the largest single change, because querySkuDetailsAsync and the whole SkuDetails data model give way to queryProductDetailsAsync and ProductDetails:

            val params = QueryProductDetailsParams.newBuilder()
    .setProductList(
        listOf(
            QueryProductDetailsParams.Product.newBuilder()
                .setProductId("pro_monthly")
                .setProductType(BillingClient.ProductType.SUBS)
                .build()
        )
    )
    .build()

client.queryProductDetailsAsync(params) { billingResult, result ->
    // NOTE: the listener signature changed. Read Google's
    // "Show products available to buy" section before you wire this up.
}
          

That last comment is not decoration. Google's migration guide calls out a change in the signature of ProductDetailsResponseListener.onProductDetailsResponse, and it is the one change in the PBL 8 migration that a find-and-replace will not handle for you. Check the current signature against Google's integration guide rather than against a two-year-old sample.

The free-trial trap hiding inside queryPurchaseHistoryAsync

Plenty of Android codebases use queryPurchaseHistoryAsync for exactly one thing: working out whether a user has already consumed a free trial, so the paywall does not offer it twice. That API is gone.

Google's replacement guidance is explicit in the PBL 9 migration guide: if you were using queryPurchaseHistoryAsync to determine eligibility for free trials, use ProductDetails.getSubscriptionOfferDetails() to determine which offers a user is eligible for. Play itself now tells you which offers apply to this user, rather than asking you to infer it from purchase history.

For consumed one-time purchases, Google's position is that you track those on your own backend. For cancelled or voided purchases, the server-side Voided Purchases API is the supported route.

This is the part of the migration that is genuinely a product decision rather than a refactor. If your trial-eligibility logic currently lives entirely on the client and reads purchase history, you are not doing a library upgrade; you are moving a piece of entitlement logic to the server or to Play's offer model. Budget for it separately. The real cost of this migration is usually the entitlement logic, not the SDK calls.

Go to 8, or go straight to 9?

A claim circulating in secondary write-ups is that there is no direct path from PBL 7 to PBL 9, so teams must land on 8 first. Google's own documentation contradicts that. The current guide is titled Migrate to Google Play Billing Library 9 from versions 7 or 8 and it documents the 7-to-9 upgrade step by step. As of August 2026, the version pinned in Google's PBL 9 dependency snippet is 9.1.0.

            dependencies {
  val billing_version = "9.1.0"
  implementation("com.android.billingclient:billing-ktx:$billing_version")
}
          

The billing-ktx artefact is worth taking while you are in the file. It adds Kotlin extensions and coroutine support, which removes a layer of callback plumbing from exactly the code you are already rewriting.

Here is the honest comparison for a team standing on PBL 7 today.

If your app already uses ProductDetails rather than the old SkuDetails model, which it must if it is on PBL 7 doing anything modern, the extra PBL 9 removals are largely dead code you deleted years ago. In that situation, going to 9.1.0 costs a few hours more and buys twelve extra months.

Three PBL 9 behaviours need real handling rather than a version bump.

BillingResult from launchBillingFlow() now carries a sub-response code field, populated only in some cases. The documented values are PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS, USER_INELIGIBLE and NO_APPLICABLE_SUB_RESPONSE_CODE. Google's guidance is to update your PurchasesUpdatedListener to recognise them, so a declined card produces a "fix your payment method" prompt instead of a generic failure. For a subscription app, this is the single highest-value change in PBL 9, because insufficient funds and offer ineligibility are two of the most common paywall drop-off causes and they previously arrived as the same opaque error.

An error code was reclassified. Where the Play Store app is blocked by the system, for example in an OEM-customised kids mode, the response code changed from ERROR to BILLING_UNAVAILABLE. Any branch that keys on a generic error in that scenario needs revisiting. This behaviour needs AndroidX core 1.9 or later.

DeveloperProvidedBillingDetails.getLinkUri() is now @Nullable, which only affects external payment integrations. Google's own Kotlin sample handles both null and empty string:

            val linkUri = details.linkUri
if (!linkUri.isNullOrEmpty()) {
    val intent = Intent(Intent.ACTION_VIEW, linkUri.toUri())
    context.startActivity(intent)
}
          

Google now ships an agent skill for this migration

Both migration guides point at the same tool: a Play Billing Library Version Upgrade skill published in Google's android/skills repository. Google describes it as detecting outdated method calls automatically and providing recommendations for updating your implementation to the latest standards.

Treat it as a detector rather than an autopilot. It is good at finding every call site, which on a large codebase is the tedious part. It cannot make the entitlement decision described above, and it cannot tell you whether your trial logic was correct in the first place. Run it, read the diff, then review the paywall by hand.

The deadline stack: two gates, one date

The billing deadline does not arrive alone. Google Play's target API level requirement lands on the same day, which is the practical reason to plan a single compliance release rather than two.

Google's target API level page sets different floors for other form factors: Wear OS and Android Automotive apps must target API level 35 or higher, and Android TV and Android XR apps must target API level 34 or higher.

Two gates on one date, both with the same 1 November escape hatch, is a scheduling gift if you treat it as one release and a scheduling trap if you treat it as two. A single hardened release train that clears both is the cheaper path, and it is the same argument we make for target API level 36 migration and for the Play age signals API integration, which is another Play-driven change moving through the same pipeline.

What this costs, and what it does not

There is no licence fee attached to a Play Billing Library upgrade. The cost is engineering time plus a purchase-flow regression risk that is unusually expensive to get wrong, because the failure mode is silent revenue loss rather than a crash.

A realistic shape for the work, for an app with a single subscription and one or two one-time products, is a day or two on the SDK surface, two to four days on entitlement and trial logic if it currently relies on purchase history, and then the part nobody budgets for: testing every purchase state against a real Play account.

Google's testing guidance covers licence testers and test cards, and there is a separate mechanism for forcing specific BillingResult response codes. Use the second one. A migration that only ever exercises the happy path will pass review and then fail in production on the first pending transaction.

One more recommendation from Google's own guide that is easy to skip: enable automatic service reconnection. The library can re-establish the service connection when an API call is made while the service is disconnected, and both the PBL 8 and PBL 9 guides list it as recommended. It is a two-line change that removes a whole class of flaky purchase failures.

India-specific considerations

Indian developers are migrating on the same 31 August 2026 clock as everyone else, because the Billing Library deadline is global. The commercial picture underneath it is not global, and that difference is worth understanding before you rebuild a paywall.

Google's service fees page puts markets outside the EEA, United Kingdom and United States on the earlier structure: 15% on the first $1M (USD) of annual earnings, 30% above that, and 15% on automatically renewing subscriptions regardless of annual revenue. Google states that 97% of developers distribute at no charge, and that of those who do pay a service fee, 99% qualify for 15% or less.

India also has a specific alternative billing arrangement. For developers who offer an alternative billing system alongside Google Play's billing system for users in India, in accordance with the Payments policy, the service fee for transactions through that alternative system equals the Play billing fee reduced by 4 percentage points. Google documents the India programme in a dedicated Help Center article.

The newer structure that started on 30 June 2026 applies to buyers in the EEA, United Kingdom and United States, which means an Indian studio with paying users in those markets is already on the new rates for those transactions. Paul Feng, Vice President, Google Play Eng, Product, UX, described the change in Google's announcement on 24 June 2026: "To enable this new level of flexibility, we're separating our service fee from the billing fee." Under that structure the service fee starts at 10% on the first $1M (USD) of annual earnings and applies at 10% to all auto-renewing subscriptions, with a 5% billing fee on top when Google Play's billing system processes the transaction, and no billing fee for alternative billing or external web links. Standard one-time purchases sit at 20% plus the billing fee for new installs and 25% plus the billing fee for existing installs, and Google has said programme rate cards for Games Level Up and Apps Experience become available on 30 September 2026.

None of this changes your PBL 8 code. It changes what a paywall redesign is worth, which matters because you are already opening that file. We work through the full arithmetic in our breakdown of Google Play service fees and app economics.

On data protection, purchase tokens, Play account identifiers and any user-level entitlement records you store on your own servers are personal data under India's Digital Personal Data Protection Act 2023. If this migration moves trial-eligibility state from the device to your backend, which for many apps it will, that is a new processing purpose and it belongs in your notice and retention schedule rather than in a follow-up ticket.

A rollout checklist that survives contact with the Play Console

Work this in order. Each step catches a failure the next step would otherwise hide.

1. Grep the codebase for all ten removed symbols before you change the Gradle version, so you size the work honestly.

1. Confirm com.google.android.play.billingclient.version survives manifest merging in a release build, not just a debug build.

1. Bump to 9.1.0 rather than 8.0.0 unless you have a specific reason not to, and take billing-ktx while you are there.

1. Move trial-eligibility logic to ProductDetails.getSubscriptionOfferDetails() or to your backend, and write a test for the already-used-trial case.

1. Handle the PBL 9 sub-response codes in your PurchasesUpdatedListener, especially PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS.

1. Enable automatic service reconnection.

1. Exercise pending transactions, insufficient funds and billing-unavailable using Google's response-code test harness.

1. Bundle the target API level 36 upgrade into the same release train.

1. Ship to a staged rollout with purchase-success rate on the release dashboard, not just crash rate.

1. If step 9 slips past mid-August, request the extension in the Play Console under Policy status before 31 August, not after.

That last point deserves emphasis. The extension is requested through a form on the warning's details page in the Play Console, and the sensible time to request it is while you still have a working release channel.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based, ISO 27001:2022 certified engineering organisation, and our senior Android teams run Play compliance deadlines as scheduled release trains rather than fire drills. We audit the removed-API surface, move trial and entitlement logic off purchase history where it needs to move, harden the purchase-state test matrix, and bundle the Billing Library and target API level work into one staged rollout. If your team is looking at 31 August with a PBL 7 codebase and no slack in the sprint, talk to us or read more about our Android and Kotlin app development work and our approach to enterprise mobile app development.

References

1. Google Play Billing Library version deprecation, Android Developers, last updated 22 June 2026.

1. Migrate to Google Play Billing Library 8 from versions 6 or 7, Android Developers, last updated 27 April 2026.

1. Migrate to Google Play Billing Library 9 from versions 7 or 8, Android Developers, last updated 1 July 2026.

1. Play Billing Library Version Upgrade skill, Google, android/skills repository.

1. Integrate the Google Play Billing Library into your app, Android Developers.

1. Query purchase history, Android Developers.

1. Purchases.voidedpurchases, Google Play Developer API reference.

1. Expanded billing choice and lower fees on Google Play, Paul Feng, Android Developers Blog, 24 June 2026.

1. Service fees, Play Console Help.

1. Alternative billing system for users in India, Play Console Help.

1. Target API level requirements for Google Play apps, Play Console Help.

1. Test your Google Play Billing integration, Android Developers.

1. Test BillingResult response codes, Android Developers.

1. Meet Google Play Billing Library Version 3, Android Developers Blog, June 2020.

Last updated: 4 August 2026.