Home › App Publishing Hub › Google Play Rejection Guide › Playbook

Google Play Rejection Playbook

If you just received a rejection email, follow this sequence: map the policy trigger, fix by priority, then resubmit with verifiable reviewer evidence.

End-to-End Flow

01 Map Policy TriggerExtract policy code, impacted page, and evidence screenshots from the rejection email.
02 Prioritized FixesFix privacy, permissions, and SDK first, then stability and metadata alignment.
03 Reviewer NotesUse a 4-part note: policy code, changes made, verification result, and test route.
04 Pre-submit QARun critical-flow regression so reviewers can reproduce key functionality.
Case A | Permission vs Privacy Mismatch

Symptom: reviewer asks for clearer permission purpose, policy text is too generic

This is one of the most frequent failure modes. If your app requests contacts or location but the policy says only “for better experience,” reviewers cannot verify minimum necessity. Update trigger timing, feature entry, and policy copy together.

BeforePermission text says “improve experience” without a specific in-app feature path.
FixAdd explicit purpose, request only after user enters the related feature.
AfterReviewer can reproduce permission flow; app behavior and declaration match.
Evidence pack: screenshots before/after permission prompt + related feature entry + matching privacy policy section.
Case B | Metadata vs Actual Feature Mismatch

Symptom: store listing promises a feature not available in the current build

Teams often ship marketing assets ahead of feature rollout, which triggers misleading metadata issues. Downgrade listing content to what is verifiable now, then restore stronger copy after feature release.

BeforeListing claims “AI assistant,” but no corresponding in-app entry exists.
FixRemove exaggerated claims and replace with current production screenshots and copy.
AfterStore content matches real app behavior, reducing review friction.
Evidence pack: listing edit history + in-app matching screenshots + short release-delta note.

High-frequency Rejection Points

  • Incomplete privacy policy: cover data type, purpose, processing method, and contact channel.
  • Improper permission declaration: remove non-essential permissions and map each one to a feature.
  • Outdated target SDK: upgrade to current Google Play requirements and run compatibility regression.
  • Misleading metadata: keep title, description, screenshots, and real functionality aligned.
  • Core path failures: fix crash, blank screen, login failure, and payment failure scenarios.

Resubmission Notes

  • Policy code: identify the triggered policy and impacted screen.
  • Fix list: enumerate code/content/permission changes completed.
  • Verification: provide test account, exact route, and key evidence screenshots.
  • Prevention: explain your release QA checks to avoid recurrence.
Submit both “before” and “after” evidence. Reviewers can validate faster, which often shortens back-and-forth.

If Rejected Again, What Next?

  • Do not rush a third submission. Compare both rejection emails and confirm root-cause overlap.
  • Avoid vague notes like “fixed, please review.” Reply policy-by-policy with concrete evidence.
  • Add a reviewer reproduction route: account, click path, and expected result.
  • If needed, isolate high-risk non-core features first, pass core flow, then reintroduce safely.
Back to Rejection Guide See Google Play Rejection Guide See App Store Rejection Guide Back to App Publishing Hub