Publishing & Deployment Issues

Play Console Integrity API Requirement Fails Review - SDK Integration and Manifest Declaration Fix

Fix Play Console Integrity API requirement review failures by validating SDK wiring, Play Core dependency versions, manifest declarations, and server-side token verification flow.

By GamineAI Team

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

  1. Partial integration Client-side token requests exist, but server-side decode and verdict checks are missing or incomplete.

  2. Dependency drift Play Integrity related libraries resolve to conflicting versions through transitive dependencies.

  3. Manifest or build-variant mismatch Required package metadata or build settings differ between local test build and submitted artifact.

  4. 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:

  1. client token request point
  2. backend verification endpoint
  3. 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:

  1. verify Play Integrity dependency is present in the final resolved dependency tree
  2. remove duplicate or legacy Play Core entries that can shadow correct APIs
  3. 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:

  1. check package identity and variant-specific manifest overlays
  2. confirm no build flavor removes required declarations
  3. 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:

  1. receive token from trusted app flow
  2. verify with Google Play Integrity backend APIs
  3. enforce verdict logic for device integrity, app integrity, and licensing signals as needed
  4. 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

Bookmark this fix so future Play review cycles can be validated in minutes instead of after repeated rejection rounds.