Debugging log · Billing

Play Billing Library 8: the removed & changed APIs checklist

When I migrated seven apps to Play Billing Library 8, the fastest way to know how much work each one needed was to grep the billing code against a short list. Most of the time the answer was "one line." This is that list, so you can scan your own BillingManager and know in two minutes whether you have a quick bump or real removal work.

How to use this: search your project for each symbol below. If you only hit the "changed" row, you have a five-minute migration. If you hit any "removed" row, fix those first — they won't compile against v8 at all.

Changed — you must edit this

queryProductDetailsAsync callback

The single change that touched every app. The callback's second parameter changed from a list to a result object:

// v7: second param is List<ProductDetails>
client.queryProductDetailsAsync(params) { _, list ->
    list.forEach { /* ... */ }
}

// v8: second param is QueryProductDetailsResult
client.queryProductDetailsAsync(params) { _, result ->
    result.productDetailsList.forEach { /* ... */ }
}

In Java it's the same idea: the listener now receives a QueryProductDetailsResult, and you call getProductDetailsList() on it. The result object also exposes an unfetched-products list if you want to detect product IDs that returned nothing.

Removed — replace before you compile

Removed API	Replace with
`querySkuDetailsAsync` / `SkuDetails`	`queryProductDetailsAsync` with `ProductDetails`
`queryPurchaseHistoryAsync`	`queryPurchasesAsync` (or drop it if you only needed current purchases)
`enablePendingPurchases()` (no arguments)	`enablePendingPurchases(PendingPurchasesParams…)`
Old `launchBillingFlow` subscription-update fields (`setOldSkuPurchaseToken`, etc.)	`setOldPurchaseToken` + `setSubscriptionReplacementMode`

These are the symptoms of a genuinely old integration. The good news: if you already migrated from SkuDetails to ProductDetails in an earlier version, you almost certainly don't hit any of these.

Unchanged — leave it alone

Just as useful is knowing what not to touch. In every app I migrated, these were identical between v7 and v8:

enablePendingPurchases(PendingPurchasesParams.newBuilder()…) — the parameterized form is correct and stays.
queryPurchasesAsync(QueryPurchasesParams, listener) — the params-object form is unchanged.
launchBillingFlow(activity, params) — unchanged.
acknowledgePurchase and consumeAsync — unchanged.
Subscription replacement via setSubscriptionReplacementMode / setOldPurchaseToken — unchanged.

The dependency bump

implementation("com.android.billingclient:billing:8.0.0")
// or, if you use the KTX artifact:
implementation("com.android.billingclient:billing-ktx:8.0.0")

After the Play deadline you can't publish updates built against v7, so this is required if you plan to ship again — not just a nice-to-have.

Before you call it done

A compile-clean migration is not a tested migration, and this is real money. Build a release and actually run, on a device: a subscription purchase, a subscription upgrade/downgrade, a consumable purchase, and a restore after reinstall. The callback change is mechanical, but the only way to be sure your purchase flow still resolves products correctly is to watch a real one complete.

Library contents and Play requirements shift between releases; confirm the exact removed-API list and current minimum version against the official Play Billing migration guide before shipping.