Integrity is part of a larger request flow
Google Play Integrity gives an app a token that its backend can verify. The app decides when to request it, what action needs it and how the result is attached to the next server call. That surrounding code is the part needed to reconstruct the application workflow.
Standard requests can use a nonce. Standard and classic requests can bind the verdict to request data in different ways. The app may hash selected request fields, a challenge or serialized body before asking for the token.
Trace both sides of the token request
Find the Play Integrity dependency and calls into its token provider. Trace backward to the data used for the request. Then trace the success callback forward to the HTTP header, JSON field or protobuf message that carries the token to the app's backend.
- The action that starts the check.
- The nonce, request hash or challenge source.
- The project or cloud configuration used by the client.
- The endpoint that receives the token.
- The server response when the verdict is missing, stale or rejected.
Keep PairIP separate
Google Play Automatic Protection, often identified through PairIP components such as libpairipcore.so, changes app startup and license behavior. Play Integrity is an API used by app and backend code. One build can contain both, so the package and runtime flow must be checked for each system.
What we deliver
We reconstruct the full application flow around the protected action. The delivery records where the integrity value enters the workflow, which request fields it covers, its timing and the server response path. When a live Android runtime remains part of the design, the interface exposes that dependency clearly to the system that calls it.
Reviewed 30 August 2026 · SReverse