ExtensionBooster

Posted on Nov 13 Originally published at appranker.net

Google Play Billing Library 8: fix your blocked updates

#android #reactnative #flutter #mobile

Originally published on AppRanker.

Google Play Billing Library 8 has been mandatory for new apps and updates since August 31, 2026, and the last extension window closed on November 1. If your Android build still ships version 7, your users can keep buying, but you can't push the next update. This post covers how to confirm which version you actually ship, the code that breaks, and the plugin versions for Flutter, React Native, Unity and RevenueCat.

What is blocked, and what still works

This is a publishing gate, not a kill switch. Live v7 builds keep handling purchases, renewals and restores. What stops is everything you upload next: crash fixes, the yearly target API bump, seasonal builds.

It only applies if your build includes the billing library (it comes with the com.android.vending.BILLING permission). Don't assume you're out of scope because you never added it yourself: payments SDKs and plugins can pull it in.

Google repeats the same yearly cycle, so it's worth knowing the schedule:

Version	Blocked for new apps and updates	Extension ends
v7	Aug 31, 2026	Nov 1, 2026
v8	Aug 31, 2027	Nov 1, 2027
v9	Aug 31, 2028	Nov 1, 2028

Upgrading to 8 buys you until August 2027. Version 9 lasts a year longer, but it needs minSdk 23. Only 8.0.0 still supports minSdk 21; 8.1.0 and later need 23.

Check the version you really ship

Your build.gradle line isn't the whole story. A stale lockfile or a transitive dependency can keep v7 in the release build. Check the resolved graph from the Android project folder (android/ in Flutter and React Native projects):

./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep billingclient

You want com.android.billingclient:billing:8.x.x (or billing-ktx). A resolution like 7.1.1 -> 8.0.0 is fine.

Then confirm it in the built artifact by looking for the com.google.android.play.billingclient.version entry:

# AAB
bundletool dump manifest --bundle app-release.aab | grep billingclient
# APK
apkanalyzer manifest print app-release.apk | grep billingclient

If the entry is missing, look for a tools:node="remove" rule or a custom manifest merge that strips it. In Play Console, Policy and programs > Policy status shows an outdated library as a warning for each app.

The API changes that break your build

Most upgrades need code changes because v8 removes several methods:

Removed in v8	Use instead
`querySkuDetailsAsync()`	`queryProductDetailsAsync()`
`enablePendingPurchases()` (no arguments)	`enablePendingPurchases(PendingPurchasesParams)`
`queryPurchasesAsync(String skuType, listener)`	`queryPurchasesAsync(QueryPurchasesParams, listener)`
`queryPurchaseHistoryAsync()`	`queryPurchasesAsync()` plus your own backend

If you are jumping from v6, also rename setOldSkuPurchaseToken to setOldPurchaseToken, and replace setReplaceProrationMode and setReplaceSkusProrationMode with setSubscriptionReplacementMode.

A minimal v8 setup in Kotlin:

// build.gradle.kts
implementation("com.android.billingclient:billing-ktx:8.0.0")

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(
        PendingPurchasesParams.newBuilder().enableOneTimeProducts().build()
    )
    .enableAutoServiceReconnection() // new in 8.0.0
    .build()

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

billingClient.queryPurchasesAsync(params) { billingResult, purchases ->
    // restore entitlements from active purchases
}

Product queries now return a QueryProductDetailsResult. After checking for BillingResponseCode.OK, read productDetailsList, and log unfetchedProductList. That list is the fastest way to explain an empty paywall: products that are inactive, misspelled or unavailable show up there.

The hidden part: purchase history

The biggest change isn't a rename. v8 no longer returns expired subscriptions or consumed one-time products. If your "restore lifetime unlock" flow or a returning-user discount relied on queryPurchaseHistoryAsync(), it will quietly stop working.

Move that logic to your server before you ship: queryPurchasesAsync() for what's active now, the Voided Purchases API for refunds and cancellations, and your own records for everything else.

Cross-platform plugin versions

Minimum versions that bundle Billing Library 8:

Flutter in_app_purchase_android: 0.5.0 (removes queryPurchaseHistory). 0.5.5 moves to Billing Library 9.1.0 and needs minSdk 23.
react-native-iap: 14.0.0. All 12.x and 13.x releases default to Billing Library 7.0.0.
Unity IAP: 4.15.1 or 5.0. IAP 5.4 uses Billing Library 9.0.0.
RevenueCat (Android, Flutter, React Native): 9.0.0, which needs Kotlin 1.8.0 or later.

Major plugin versions also change their own APIs, so read their migration guides. Then run the Gradle check again, because bumping the Dart or JavaScript package alone may leave a pinned v7 in the build.

Test it before you upload to production

Add your Google account as a license tester in Play Console.
Upload to the internal testing track and install from Play, not Android Studio.
Buy each product type: subscription, consumable and non-consumable.
Cancel, restore, then reinstall and confirm entitlements come back.
Check server logs: purchases must be acknowledged within three days, or Google refunds them automatically.
Roll out in stages and watch Android vitals for new crashes.

Key takeaways

v7 builds can't be published as of November 1, 2026, but installed apps keep working.
Verify the version in the built AAB or APK, not just in Gradle files.
Replace the four removed APIs and move purchase history to your backend.
Flutter, react-native-iap, Unity IAP and RevenueCat each have a minimum version; check it after upgrading.
v8 is good until August 2027; v9 lasts longer but needs minSdk 23.

The original post has the extension steps, FAQ answers and a full checklist: Google Play Billing Library 8 deadline and migration guide. If you're shipping the upgrade with a visible improvement, it's also a good moment to put your Android app in front of more people on the AppRanker app leaderboard.

Which part of the v8 migration cost you the most time: the API changes, a plugin still holding v7, or moving purchase history to the server?

DEV Community