Android App Attestation: Evidence for a Request, Not a Permanent Trust Badge

Separate the trust questions

The Play Integrity overview and Firebase App Check overview describe related but different integrations. App Check can use provider signals to protect supported resources; direct Play Integrity gives a server a verdict to evaluate in its own workflow.

Bind evidence to a useful decision

Choose the action that needs protection and the server-side response to each relevant outcome. Protecting a high-value transaction may require different treatment from reading public content.

Do not reduce the entire threat model to “device passed, allow everything.” A legitimate app can still be operated by an abusive user.

Plan for imperfect environments

Older devices, alternate distribution, temporary provider failures and unsupported configurations can affect the result. Distinguish unavailable evidence from a positive determination of abuse.

Use proportionate responses such as a retry, remediation, reduced-risk flow or additional verification where appropriate. Avoid silently granting privileged access when verification fails.

Keep the final decision off the client

A boolean computed solely inside the APK can be changed or bypassed by a modified client. The backend should validate the provider's evidence and enforce the policy for protected operations.

Do not store a service-account credential or other privileged verifier secret in the app.

Validate with real release paths

Test the actual distributed certificate and package, not only a debug build. Record which signal caused the decision and avoid logging raw tokens.

APKLint's package and Firebase tools can support configuration review. They do not perform live attestation or certify device integrity, so use them to find setup mismatches before validating the complete client-to-server flow.