Read the verified response only
Use the verdict reference after server-side verification. A client-decoded payload or client-supplied summary must not decide access to a protected backend operation.
Check request details and expected app identity before applying higher-level policy. A validly structured response associated with the wrong action or app is not the evidence you intended to obtain.
Keep signal categories distinct
| Category | Example decision question |
|---|---|
| App recognition | Is this the expected distributed application? |
| Device integrity | Does the environment meet this action's requirements? |
| Account/licensing context | Is the expected Play acquisition context present? |
| Additional enabled signals | Do they justify an extra check or remediation? |
The overview explains available capabilities. Not every field is guaranteed to be available in every configuration or response.
Treat absence explicitly
Distinguish an absent field, an unevaluated result and a negative result. A parser that silently converts all three into false loses information needed for support and proportional enforcement.
Likewise, a default true when parsing fails is a security bug, not graceful degradation.
Define a response matrix
For each protected action, decide which outcomes allow it, which require retry or remediation and which block it. Consider the cost of both false acceptance and false rejection.
Keep user-facing messages actionable without exposing detailed anti-abuse thresholds. A legitimate user should know whether to update, retry or contact support rather than see an unexplained generic failure.
Observe before tightening policy
Measure outcomes by app version and supported device/distribution context using privacy-conscious logging. Retain aggregate reasons, not raw tokens.
APKLint can help inspect the package metadata that informs your expected identity. It cannot produce or validate live verdicts. The real acceptance criterion is a tested server-side response matrix using verified evidence and correctly bound action data.
Create fixtures that preserve missing and unevaluated states
Build a server-policy test set from the documented verified response structure. Include expected values, an absent optional field, an explicitly unevaluated result and an unexpected value. Keep these synthetic policy fixtures separate from raw client input: exercising your parser does not establish that an arbitrary JSON object came from the provider.
The verdict reference defines the signal meanings and conditions. Parse the available values without inventing a positive default. For an unfamiliar result, follow the product's explicit unsupported-evidence policy and record a bounded diagnostic category so the team can investigate a legitimate schema or configuration change.
Evaluate the same evidence for two different operations
Suppose the application offers public product information and a valuable promotional redemption. The product may permit the public information flow while requiring stronger evidence for redemption. Test those decisions separately. A single global passed variable hides the relationship between the signal, the action's risk and the intended user recovery path.
Before considering device signals, verify that the response belongs to the expected request and application context. Add a fixture with strong-looking device information but a mismatched action binding and confirm that the protected operation is refused. A favorable field later in the object cannot repair an earlier mismatch.
Exercise provider errors outside the verdict parser. A timeout, token-acquisition failure and verified negative result are different events. Give them distinct internal categories while keeping user messages useful and proportionate. A temporary service problem should not be reported as a definitive accusation that the user tampered with the device.
When changing enforcement, compare the proposed matrix with measured outcomes for supported app versions and distribution paths. Use aggregate counts and redacted categories rather than a collection of raw tokens. Estimate which legitimate actions would be restricted before enabling a stricter rule.
Retain the policy version with the decision record. If a support case arrives later, the team should be able to identify which rule applied at the time instead of interpreting an old result through today's policy. This makes the server decision reproducible without implying that any one integrity label is a permanent judgment about a person or device.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
