1. Google runs a two-year deprecation cycle on the Play Billing Library: every major version is supported for two years after release, and after that Play Console stops accepting new builds compiled against it. The published table (https://developer.android.com/google/play/billing/deprecation-faq) reads: 5.x last date for new apps and updates 2024-08-31 (extension request deadline 2024-11-01), 6.x 2025-08-31 / 2025-11-01, 7.x 2026-08-31 / 2026-11-01, 8.x 2027-08-31 / 2027-11-01. In practice: since 31 August 2026 any new app or app update that uses Play Billing must be built against Billing Library 8.0.0 or later.
2. The exact wording matters. Google's deprecation FAQ says this deprecation "prevents only new apps and updates from using older versions of the Play Billing Library. Existing apps that use a deprecated version of the library will continue to function as expected." It is a publishing gate, not a runtime kill switch - an already-published v7 build keeps processing purchases. What you lose is the ability to publish anything new, including a security patch or a rebuild, so any app you intend to keep maintaining has to be migrated.
3. The extension is a request, not an automatic grace period. For the 7.x line the extension request deadline is 2026-11-01, and the request has to be filed before the original deadline. Play Console signals eligibility through a warning on the app's page plus an inbox message on the Policy status page once an app is on a deprecated version; the extension form sits on the details page of that warning or issue (https://developer.android.com/google/play/billing/release-notes).
4. Detection trap: Play Console reads your library version from the com.google.android.play.billingclient.version entry that the library injects into the manifest. Manifest merging in multi-module projects can drop it - if that entry is missing from your final merged manifest, Play Console cannot tell which version you shipped and the warning may never reach you. Verify the merged manifest instead of trusting the silence.
5. What breaks in v8 (each item is a compile error until it is replaced): querySkuDetailsAsync() -> queryProductDetailsAsync(QueryProductDetailsParams, ProductDetailsResponseListener); the no-argument enablePendingPurchases() -> enablePendingPurchases(PendingPurchasesParams); the queryPurchasesAsync(String skuType, PurchasesResponseListener) overload -> queryPurchasesAsync(QueryPurchasesParams, PurchasesResponseListener); queryPurchaseHistoryAsync() has no client-side replacement, so purchase history has to be tracked server-side; BillingClient.Builder.enableAlternativeBilling(), AlternativeBillingListener and AlternativeChoiceDetails -> enableUserChoiceBilling(UserChoiceBillingListener), UserChoiceBillingListener and UserChoiceDetails; and ProductDetailsResponseListener.onProductDetailsResponse() now returns a QueryProductDetailsResult that separates fetched from unfetched products with per-product status codes. Terminology changed too: what the docs called "in-app items" are now "one-time products", and in v8 they support multiple purchase options and offers the way subscriptions already did.
6. Practical checklist: pin the latest patch on the 8.x line rather than 8.0.0; re-test the purchase, restore and pending-purchase paths with license testers before rollout; keep verifying purchase tokens server-side; and treat this as an annual maintenance item rather than a one-off - the 8.x line itself is retired for new uploads on 2027-08-31, with a 2027-11-01 extension backstop. Scheduling each migration a quarter ahead of its deadline is the only way it never blocks a release.