Google deprecates old Play Billing Library versions on a real schedule, and an app that falls too far behind loses the ability to publish updates at all until it catches up. Teams that built their own billing integration feel every one of these deadlines directly. Teams on RevenueCat mostly don’t — but “mostly” is doing some work in that sentence, and it’s worth knowing exactly what you’re still responsible for.
1. What Actually Changes When Google Deprecates a PBL Version
1
You still need to bump your RevenueCat SDK and rebuild
RevenueCat absorbs the Play Billing Library changes internally, but that only reaches your app once you update the RevenueCat SDK dependency and ship a new build — it isn’t retroactive on an app already in production.
2
Re-test proration and upgrade/downgrade flows after every bump
Billing library changes have historically touched proration behavior specifically. Don’t assume last release’s QA still holds.
3
Re-verify deferred replacement and account hold behavior
These are the edge cases most likely to silently regress across a billing library version bump, and the ones least likely to get caught by a quick smoke test.
2. Entitlement Edge Cases Specific to Android
↕️
Upgrade / downgrade proration
Google offers several proration modes (immediate with prorated credit, deferred, charge full price). Which one you use changes what entitlement state looks like mid-cycle — test the specific mode your app uses, not just the default.
⏸️
Account hold & grace period
When a payment fails, Google gives a grace period before revoking access. Your UI needs a state for “payment issue, still has access” — distinct from both “active” and “expired.”
🔁
Resubscribing after voluntary cancellation
A user who cancels and comes back within the same billing cycle is a different case from a fresh subscriber — make sure your onboarding doesn’t re-trigger for someone who never actually left.
👥
Multiple Google accounts on one device
More common on Android than iOS given how account-switching works — worth an explicit test pass rather than assuming it can’t happen.
Before you bump the SDK version
Pin the RevenueCat SDK version explicitly in your build config rather than tracking “latest,” roll the update through a staged release percentage rather than 100% of users at once, and watch the RevenueCat dashboard for a few days afterward for any entitlement anomaly that wasn’t there before.
The same staged, validate-before-you-trust-it discipline applies whether you’re bumping a billing library version or doing a full platform migration — see our iOS migration piece for the equivalent playbook on the other platform, or our Flutter guide if you’re maintaining both from one codebase.
Behind on a Play Billing Library upgrade, or planning one?
Tell us your current RevenueCat and billing library versions and we’ll scope what actually needs re-testing.
Start the Conversation →
