Two controls that share a brand and little else
Automatic Protection changes the file that Google Play distributes. PairIP components such as the native core and the application stub are the visible result. Play Integrity is an API: the app asks Google Play services for a token, sends that token to its own server, and the server decides what the token means. A single build can carry both, and finding one says nothing about the other.
Automatic Protection is a wrapper on the delivered APK
Play can replace the artifact it distributes with a wrapped version of what the developer uploaded, shown in the Play Console as Automatic Protection. The wrapper adds a native core and a stub that runs before the real application class. It checks the environment it was wrapped for, including the signature and the install route, and it can stop, degrade or continue the launch.
The enforcement is local. There is no network call to a Google verdict service in that path, and the app's backend is not consulted. This is why a wrapped build can refuse to start on a plane, and why the failure message usually points at the store rather than at the account.
Play Integrity is an API call and a server decision
For Play Integrity, the app collects data for the request and asks Google Play services for a token. It then sends that token to its own backend, which verifies it with Google and decides what to do. Verdicts describe the device environment and whether the app installation is recognised. Some request modes bind the verdict to data the app supplies, such as a nonce or a digest of request fields, so the backend can tell that the token was issued for that specific call rather than replayed from elsewhere.
The decision belongs to the backend. A device that fails a device integrity label still receives an HTTP response. Reading that response, and comparing it with the response for a passing device, is the only way to learn what the server actually enforces.
How the failure shapes differ
The two controls leave different traces, and the trace tells you where to work. A local stop removes the request entirely, while a server decision leaves the request and the answer on the wire for you to compare.
- A wrapper license failure happens before the application code runs, and no request leaves the device at all.
- An integrity failure produces a normal request carrying a token, followed by a server response that rejects or restricts it.
- A wrapper integrity failure can change launch behaviour silently, starting a reduced application rather than exiting.
- An integrity failure can be intermittent, because the verdict is produced per request and depends on device state at that moment.
Why one name does not prove the other
Finding the Play Integrity dependency in a decompiled build is direct evidence that the app requests tokens. Finding the PairIP application stub or the native core is evidence that the delivered APK was wrapped. Neither implies the other. A wrapped build can make no integrity calls, and an unwrapped app can call Integrity on every login.
Confirm each against the artifact and the runtime separately. Read the manifest and the native libraries for the wrapper, and read the app code for the token request and the call that carries the token. Where both exist, establish which one gates the feature you need, because a passing integrity verdict does not help if the wrapper stops the launch first.
What to collect
For an integrity flow, the useful evidence is the action that starts the request, the data bound into it, the endpoint that receives the token and the server response when the verdict changes. For a wrapper, it is the stub, the native core and the install the guard accepts.
Both investigations end in the same place: a faithful reproduction of the app's server conversation. Requests that depend on a live integrity token usually need an Android boundary in the final design, and that dependency is stated explicitly instead of hidden. The integrity request flow is a separate piece of work from unwrapping the distributed build, and treating them as one problem is where most schedules slip.
Related work
Reviewed 28 September 2026 · SReverse research desk