If your Android app sells subscriptions or one-time digital goods through Google Play, the Billing Library version in your release train is now a calendar problem. Google's deprecation FAQ lists August 31, 2026 as the new-app and update deadline for Play Billing Library 7, and November 1, 2026 as the extension deadline. The August date has already passed. The November date is the backstop — and you only get it if you open the Play Console warning on the Policy status page and complete the extension form. Google lists no later date for version 7. After November 1, 2026, apps still on Billing Library 7 can keep working for people who already installed them, but Play will not accept a new app or an update until you ship version 8 or later. That is how a "small billing refactor" becomes a full release freeze right when sales wants a feature drop.
Confirm which deadline you are actually on
Read the Policy status warning in Play Console, not a Slack rumor. If you never requested the extension, your effective deadline was August 31. If you did, you have until November 1. Requesting an extension you might not need costs nothing; discovering in late October that you never filed the form costs a blocked production train.
What breaks when you move to PBL 8
Google's migration guide for PBL 8 removes previously deprecated APIs. Teams commonly trip on: querySkuDetailsAsync → queryProductDetailsAsync . SKU-centric code has to move to the product details model. Pending purchases. Parameterless enablePendingPurchases() is gone; use enablePendingPurchases(PendingPurchasesParams…) . Purchase history and typed queries. Older queryPurchaseHistoryAsync and string-typed queryPurchasesAsync overloads are removed in favor of the current purchase query APIs. Alternative billing renames. enableAlternativeBilling / AlternativeBillingListener / AlternativeChoiceDetails become the user-choice billing names ( enableUserChoiceBilling , UserChoiceBillingListener , UserChoiceDetails ). React Native and Flutter wrappers often lag one minor behind the native library. Pin a wrapper version that actually depends on PBL 8, then run subscription QA on a real Play track — not only a local mock.
// build.gradle — pin a supported Play Billing Library 8.x line
dependencies {
implementation 'com.android.billingclient:billing:8.0.0'
// or the current 8.x patch your wrapper requires
}
// After upgrade: search the app for removed symbols
// querySkuDetailsAsync, enablePendingPurchases(), AlternativeBillingListenerA three-week engineering schedule
Week 1. Inventory modules that touch BillingClient. File the Play Console extension if not already done. Create a migration branch and bump the native dependency (and RN/Flutter bridge). Week 2. Replace removed APIs, update subscription and one-time purchase flows, and fix alternative-billing naming if you use it. Add instrumentation around acknowledge/consume failures. Week 3. Internal testing track → closed testing → production. Verify upgrades, renewals, grace periods, and pending-purchase paths. Do not wait until October 28 to discover a wrapper bug.
Founder takeaway
November 1, 2026 is the last published extension date for Play Billing Library 7. Confirm your Console extension status, migrate to PBL 8, and ship through a Play testing track before the cutoff. Teams that treat billing library versions as invisible plumbing learn about them when Play rejects the APK that contains the quarter's roadmap.
React Native and Flutter specifics
Native Android migrations follow Google's PBL 8 guide closely. Cross-platform apps inherit whatever the community bridge exposes. Before you bump react-native-iap , expo-in-app-purchases , or Flutter's in_app_purchase / billing plugin, read the release notes for an explicit Play Billing Library 8 dependency. If the bridge still compiles against 7.x, your app Gradle pin alone will not save you — Play looks at the library packaged in the bundle. Plan a dedicated QA build with license testers covering: new subscription purchase, upgrade/downgrade, renewal after grace period, pending cash purchase if you use it, and restore purchases on a second device. Record screen captures for the release review channel so support sees the new UI copy.
What "extension" actually buys you
The November 1 date is not automatic. Google's deprecation FAQ says the extension form lives on the warning's details page under Policy status in Play Console. If nobody on your team opened that form, you may already be past the August 31 deadline for updates. File it even if engineering swears the migration lands in October — the form is cheap insurance. Also separate "app still runs for existing users" from "we can ship." Existing installs on PBL 7 continue; your ability to publish fixes, pricing experiments, and security patches does not. That asymmetry is how billing debt becomes operational risk.
Coordinate with finance on any SKU renames that happen while you move from SKU-centric APIs to product-details APIs. Catalog mismatches create "charged but not entitled" tickets that look like outages even when Play settlement is fine. Align product IDs in your entitlement service with what PBL 8 returns before you flip the production track.
If you monetize through both Play Billing and a web checkout for the same SaaS account, document which surface is authoritative for EU and US users during the migration week. Mixed clients with divergent library versions are a classic source of double-charge or double-revoke bugs.
Operationally, treat this topic as a dated workstream with a named owner, a written success check, and a short note you can reuse in customer security or procurement reviews. Prefer primary sources linked in your engineering channel over secondary summaries. If you cannot point to the advisory, policy table, or vendor post that justifies the change, you are not ready to claim readiness.
Share the plan with support and sales early. The expensive failure mode is not the code change — it is a surprise store rejection, a customer questionnaire gap, or a checkout path that marketing already promoted. A one-page internal brief beats a Slack thread nobody can find a month later.
