MOBILE July 1, 2026 · 3 min read

Google Play Integrity API: Subscription Security After SafetyNet's Full Sunset

SafetyNet Attestation is fully sunset. Any Android subscription app still relying on it is exposed to trial abuse and billing bypass attacks it can no longer detect. Here's what the Play Integrity API provides and what to check in your implementation.

By the AppsOps news desk · July 1, 2026

For years, SafetyNet Attestation was the backbone of device integrity verification on Android — the signal telling your backend whether the device running your app was legitimate. That era ended in late 2024, when Google fully sunset the SafetyNet API. By mid-2026, any app still calling it receives degraded or empty responses that cannot be relied on for security decisions. The Play Integrity API has been the intended replacement since 2022, and yet adoption in the subscription app space remains uneven. If your fraud prevention or trial-gating logic still touches SafetyNet, closing that gap should be an H2 2026 priority.

What the Play Integrity API Gives You

The old SafetyNet API returned a single pass/fail signal. Play Integrity API returns structured, verifiable verdicts across three independent dimensions:

App integrity — does this build match the APK your team signed and submitted to Google Play, or has the binary been modified or sideloaded?
Device integrity — is the device running a Google-certified Android build with a clean boot state? Signals range from MEETS_STRONG_INTEGRITY (hardware-backed, the strictest tier) to MEETS_BASIC_INTEGRITY (software attestation only) to unrecognized entirely.
Account details — has the Google account on this device legitimately licensed your app through Play? This replaces the old Licensing Verification Library (LVL), now folded into the same API response.

Verdicts are returned as signed, encrypted tokens that your server decodes and verifies against Google's public keys. This is the fundamental change from SafetyNet: client-side verdict handling defeats the security model entirely. The threat you're defending against is a malicious client intercepting and faking a response — server-side verification closes that door.

Why Subscription Apps Are Specifically at Risk

Android subscription fraud concentrates in three patterns: emulator farms cycling through free trials, rooted devices bypassing in-app billing, and modified APKs distributed outside Play that strip out purchase gating. Play Integrity API provides the signals to address all three.

Free trial abuse

If your acquisition funnel runs through a free trial, emulator farms can burn through them faster than account-level filters fire. An account returning MEETS_DEVICE_INTEGRITY: false, or an unrecognized app binary, is a reliable signal to deny the trial before onboarding begins. Reports from subscription infrastructure vendors suggest integrity gating at trial start reduces multi-account cycling measurably, though exact figures vary by category and price tier. For apps running purchase-power-parity pricing across markets, this matters even more — high trial abuse in low-priced markets skews cohort data and inflates reported churn.

Modified APK installs

The app integrity verdict directly flags builds that don't match your signed Play submission. Denying premium features to unrecognized binaries stops most casual attacks without affecting legitimate subscribers. The higher the value behind your paywall, the more the binary gets targeted — subscription apps in productivity, health, and education tend to attract the most attention here.

Implementation Checklist for H2 2026

Check	Priority
All SafetyNet API calls removed from codebase	Required — responses are sunset and unreliable
Using `StandardIntegrityManager` warm-up + token flow	Strongly preferred over Classic API for paywall flows
Verdict decryption and verification runs server-side only	Critical — client-decoded verdicts are not security
Nonce is unique per request and bound to transaction context	Required — replay attacks are the most obvious bypass
Graceful degradation when verdict is `UNKNOWN`	Important — enforce permissively at first, escalate on pattern

If you use a third-party subscription SDK — RevenueCat, Adapty, Glassfy, or similar — verify whether the SDK handles attestation or whether device integrity is your responsibility to layer on top. Most SDKs handle purchase receipt validation but not device-level attestation. They are different problems with different mitigations.

One practical note on latency: initialize StandardIntegrityManager at app launch, not at the moment the user hits your paywall. The warm-up call takes meaningful time; the token generation step is fast. By the time a user reaches checkout, the token is ready and your purchase flow adds no perceptible delay.

For cross-platform teams shipping on both iOS and Android, Apple's App Attest API is the functional analog. The attestation models differ — Apple's is hardware-bound from the start, Google's tiers from strong to basic — but the security objective is the same. If you've already worked through StoreKit receipt validation on iOS, the mental model for Play Integrity API is familiar ground.