If your Android release keeps failing Play review with Integrity API requirement warnings, the issue is usually integration consistency, not policy randomness. In most cases the client requests, manifest configuration, and backend verification flow are not aligned to the same implementation path.
This guide gives you a deterministic fix sequence so your build and review evidence match what Play checks.
Problem summary
Common symptoms:
- Play Console review flags missing or incomplete Integrity API implementation
- internal testing looks fine, but review still blocks production rollout
- integrity tokens are requested in client code but not validated correctly server-side
- failures begin after Unity, Play Core, or Gradle dependency updates
Impact:
- release approvals stall close to launch windows
- hotfix rollout timelines slip due to repeated policy rejections
Root causes
-
Partial integration Client-side token requests exist, but server-side decode and verdict checks are missing or incomplete.
-
Dependency drift Play Integrity related libraries resolve to conflicting versions through transitive dependencies.
-
Manifest or build-variant mismatch Required package metadata or build settings differ between local test build and submitted artifact.
-
Environment confusion Integrity flow is wired for debug or internal test behavior, then shipped without production-ready verdict handling.
Fix steps
Step 1 - Confirm the exact review requirement and map it to your current flow
Before changing code, copy the exact Play Console review text and map it to:
- client token request point
- backend verification endpoint
- verdict enforcement path in gameplay or entitlement logic
This removes guesswork and prevents unnecessary rebuild loops.
Step 2 - Validate SDK and dependency wiring
For Unity or Android native projects:
- verify Play Integrity dependency is present in the final resolved dependency tree
- remove duplicate or legacy Play Core entries that can shadow correct APIs
- align Gradle plugin and dependency versions with current Android and Play guidance
If dependency resolution changed recently, re-run dependency export and compare against last approved release.
Step 3 - Verify manifest and package declarations per shipped variant
Review the final merged manifest of the artifact you actually upload:
- check package identity and variant-specific manifest overlays
- confirm no build flavor removes required declarations
- ensure release signing and package metadata match the backend project expecting token verification
Do not rely on editor-only or debug manifest inspection for review-critical checks.
Step 4 - Implement complete server-side verification and verdict handling
Requesting a token alone is not enough. Your backend should:
- receive token from trusted app flow
- verify with Google Play Integrity backend APIs
- enforce verdict logic for device integrity, app integrity, and licensing signals as needed
- return clear allow or block outcomes to the game service layer
Log verification outcomes with stable reason codes so you can prove behavior during review response.
Step 5 - Rebuild evidence packet before resubmission
Prepare a compact evidence set:
- dependency resolution snapshot for release build
- merged manifest snapshot for submitted artifact
- backend verification log sample with successful verdict checks
- test matrix notes across internal test track and pre-release rollout path
This helps resolve follow-up reviewer questions quickly.
Verification checklist
- [ ] Submitted artifact uses the same dependency set validated in local release build.
- [ ] Final merged manifest for release variant includes required declarations and correct package identity.
- [ ] Backend verifies Play Integrity token and enforces verdict logic, not token presence only.
- [ ] Integrity verification logs include deterministic pass or fail reason codes.
- [ ] Resubmission notes reference concrete implementation evidence instead of generic compliance statements.
Alternative fixes
- If Unity dependency resolution is unstable, use External Dependency Manager resolution reports and lock known-good versions before resubmission.
- If only one flavor fails review, compare merged manifests across build flavors and remove environment-specific overrides that strip required config.
- If backend verification is difficult to retrofit immediately, ship a minimal compliant verification path first, then harden verdict policy after approval.
Prevention tips
- Add a release gate requiring Integrity token verification evidence before creating Play production release candidates.
- Keep a dependency lock and changelog for Play libraries so version drift is auditable.
- Re-run merged-manifest checks in CI for each release flavor to catch declaration regressions early.
FAQ
Why does internal testing pass while Play review fails
Internal tests often validate runtime behavior only. Review failures usually come from policy or integration evidence gaps between client, manifest, and backend verification.
Is requesting an Integrity token from the app enough
No. Play expects a full flow where tokens are verified server-side and verdicts are used in actual decision logic.
Should we bypass strict verdict checks to pass review faster
No. Keep enforcement aligned to your risk model, but ensure the implementation is real and demonstrable. Placeholder flows usually fail later audits.
Related links
- Google Play 16 KB Memory Page Size Requirement Blocks Release - IL2CPP NDK and Gradle Packaging Fix
- Steamworks Overlay Missing in Release Build - Redistributable and Launch Context Fix
- Unity Cloud Diagnostics Symbol Upload Failed - dSYM and ProGuard Mapping Pipeline Fix
- Official docs: Play Integrity overview, Standard API request flow, and Google Play Console Help
Bookmark this fix so future Play review cycles can be validated in minutes instead of after repeated rejection rounds.