If you are still using SafetyNet Attestation, the headline is that it is deprecated and the Play Integrity API is its replacement. Integrity checks answer a question your backend often needs: is this request coming from a genuine, unmodified copy of my app, on a real device, installed from Google Play, or from a tampered build, a bot, or an emulator? Play Integrity gives you signals to make that call, but they are signals to verify server-side, not a switch that secures the app. Here is what it does, what it checks, and how to use it well.
Short answer
The Play Integrity API lets your app and server check whether a request comes from a genuine, unmodified version of your app running on a certified Android device and installed from Google Play. Per Google's overview, it replaces the deprecated SafetyNet Attestation API and the older App Licensing library, and it returns verdicts your backend verifies to detect tampering, fraud, and abuse. It is an anti-abuse and integrity signal, not an absolute guarantee, so you verify the verdicts server-side and use them to decide how much to trust a request. If you still rely on SafetyNet Attestation, migrate to Play Integrity.
What you should know
- It replaces SafetyNet: SafetyNet Attestation is deprecated; Play Integrity is the successor.
- It checks integrity signals: app, device, and Google Play installation.
- Verdicts are verified server-side: your backend evaluates them, not the client.
- It is anti-abuse, not absolute: a strong signal, not an unbreakable barrier.
- Migrate if you use SafetyNet: the old API is on its way out.
What does the Play Integrity API do?
It gives your backend evidence about the integrity of a request. When your app calls the API, it requests a signed integrity verdict from Google Play services, which your server then verifies and reads. The verdict tells you whether the app binary matches what you published, whether it was installed through Google Play, and whether the device looks like a genuine, certified Android device. With that, your backend can decide how to treat the request, for example serving a sensitive action normally, adding friction, or refusing it when the signals indicate a tampered app or an untrusted environment. So Play Integrity is the mechanism for asking "should I trust this client right now," which is exactly what SafetyNet Attestation used to provide before its deprecation.
What does it check?
A few distinct integrity signals, returned as verdicts. The table summarizes them.
| Signal | What it tells you |
|---|---|
| App integrity | Whether the app binary is genuine and unmodified |
| Device integrity | Whether the device is a genuine, certified Android device |
| Google Play installation | Whether the app was installed or updated via Google Play |
| Account or licensing | Whether the user has a valid entitlement, where applicable |
The value is in combining these on your server: a request from an unmodified app on a certified device installed from Google Play is one you can trust more, while a verdict indicating a tampered binary or an uncertified environment is a reason to add friction or refuse a sensitive operation. The verdicts are signals to weigh, not a single pass or fail.
How do you use it well?
Verify server-side, and treat it as one input among your defenses. Always evaluate the integrity verdict on your backend rather than trusting a result the client reports, since a tampered client could lie about its own state; the point of a signed verdict is that your server checks it. Use the signals to gate sensitive actions, payments, granting access to premium content, submitting high-value requests, by adding friction or refusing when integrity is in doubt, rather than blocking the whole app, which can frustrate legitimate users on unusual but honest setups. And keep Play Integrity as part of a layered design: it raises the cost of abuse, but you still keep secrets off the device, enforce rules server-side, and encrypt sensitive data, because integrity attestation complements those controls rather than replacing them.
What to watch out for
The first trap is still depending on SafetyNet Attestation, which is deprecated, so migrate to Play Integrity. The second is checking the verdict on the client, which a tampered app can forge; verification must happen on your server. The third is treating integrity as absolute and hard-blocking, when it is a probabilistic anti-abuse signal that can misjudge unusual legitimate devices. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and checks the static security of your build, like storage, secrets, and network, which complements the runtime integrity Play Integrity provides. The two cover different layers: one checks how the app is built, the other checks the environment it runs in.
What to take away
- The Play Integrity API checks whether a request comes from a genuine, unmodified app on a certified device installed from Google Play, and it replaces the deprecated SafetyNet Attestation API.
- It returns verdicts on app, device, and installation integrity that your backend verifies to detect tampering, fraud, and abuse.
- Verify verdicts server-side, use them to gate sensitive actions rather than hard-block, and treat it as one layer in a defense-in-depth design.
- Migrate off SafetyNet, and pair runtime integrity with a pre-submission scan such as PTKD.com that checks your build's static security.
