|
| 1 | +# Play Review Rejection Playbook |
| 2 | + |
| 3 | +Use this playbook when Google Play rejects an OnTime app submission or update. |
| 4 | +It is scoped to Play review response only; release rollout monitoring belongs in |
| 5 | +the release ownership checklist. |
| 6 | + |
| 7 | +## Response Owner |
| 8 | + |
| 9 | +- Assign a Play review monitor before each Play Console submission. |
| 10 | +- Assign a backup monitor who has Play Console and policy email access. |
| 11 | +- The monitor checks Play Console policy status and the developer account policy |
| 12 | + email inbox at least twice per business day while a release is in review. |
| 13 | +- The monitor opens the response thread within one business hour after a |
| 14 | + rejection notice is found and records the intake checklist below. |
| 15 | +- The monitor owns coordination until the release is resubmitted, appealed, or |
| 16 | + explicitly handed off. |
| 17 | + |
| 18 | +## Immediate Triage |
| 19 | + |
| 20 | +1. Stop any further Play Console submissions for the rejected app until the |
| 21 | + cited policy issue is understood and fixed. |
| 22 | +2. Save the rejection email, Play Console policy status page, and affected |
| 23 | + release details in the release tracking thread. |
| 24 | +3. Identify whether the status is an app rejection, update rejection, removal, |
| 25 | + suspension, or another enforcement action. |
| 26 | +4. Confirm whether the previously published version remains available to users. |
| 27 | +5. Notify the release owner, backup owner, and the engineer responsible for the |
| 28 | + affected release change. |
| 29 | + |
| 30 | +## Rejection Intake Checklist |
| 31 | + |
| 32 | +Record these details before changing code, store metadata, declarations, or the |
| 33 | +appeal form: |
| 34 | + |
| 35 | +- Rejection received date and time, including timezone. |
| 36 | +- Play Console app status, update status, and affected item status. |
| 37 | +- Affected package name, track, release name, version name, and version code. |
| 38 | +- Rejection reason exactly as summarized by Google Play. |
| 39 | +- Affected policy or Developer Distribution Agreement section. |
| 40 | +- Reviewer notes, examples, and remediation instructions from the email or Play |
| 41 | + Console. |
| 42 | +- Screenshots of the policy status page, review summary, affected declarations, |
| 43 | + and any highlighted store listing or in-app evidence. |
| 44 | +- Submitted declarations that may relate to the rejection, including Data |
| 45 | + safety, content rating, target audience, permissions, ads, account deletion, |
| 46 | + health, financial, location, background activity, and notification |
| 47 | + disclosures. |
| 48 | +- Store listing fields involved, including title, short description, full |
| 49 | + description, screenshots, feature graphic, privacy policy URL, support |
| 50 | + contact, and release notes. |
| 51 | +- Build artifacts involved, including `.aab` filename, commit SHA, workflow run, |
| 52 | + signing source, Firebase config source, and Dart defines. |
| 53 | +- Whether a previous production version remains available. |
| 54 | +- Whether the same or similar rejection has happened before. |
| 55 | +- Proposed owner for the fix and proposed deadline for the next response. |
| 56 | + |
| 57 | +## Fix And Resubmit |
| 58 | + |
| 59 | +Prefer fixing and resubmitting when any of these are true: |
| 60 | + |
| 61 | +- The rejection identifies a real app behavior, metadata, declaration, or |
| 62 | + permissions mismatch. |
| 63 | +- The submitted declarations are incomplete, stale, or inconsistent with the |
| 64 | + build. |
| 65 | +- The store listing, screenshots, or release notes can be corrected without |
| 66 | + disputing Google's policy interpretation. |
| 67 | +- The reviewer notes point to a reproducible issue in the submitted build. |
| 68 | +- The team cannot prove the submitted build and metadata were policy-compliant |
| 69 | + at review time. |
| 70 | + |
| 71 | +Before resubmission: |
| 72 | + |
| 73 | +- Fix every cited policy issue and any nearby declaration or metadata mismatch. |
| 74 | +- Review the same policy area across the whole app, not only the example cited |
| 75 | + in the notice. |
| 76 | +- Update the intake thread with the exact changed files, Play Console fields, or |
| 77 | + declarations. |
| 78 | +- Attach evidence for the fix, such as screenshots, test notes, or store listing |
| 79 | + diffs. |
| 80 | +- Confirm the new build number is higher than the rejected upload when a new |
| 81 | + Android App Bundle is submitted. |
| 82 | +- Ask the release owner or backup owner to approve resubmission. |
| 83 | + |
| 84 | +## Appeal |
| 85 | + |
| 86 | +Use an appeal only when the team has a factual reason to believe the enforcement |
| 87 | +decision is incorrect or incomplete. Appeal when one of these is true: |
| 88 | + |
| 89 | +- The rejected behavior is not present in the submitted build. |
| 90 | +- Google Play appears to have reviewed stale metadata, stale declarations, or |
| 91 | + the wrong release item. |
| 92 | +- The policy requirement is already satisfied and the team can provide precise |
| 93 | + evidence. |
| 94 | +- The requested fix would make the app inaccurate, misleading, or nonfunctional. |
| 95 | +- The enforcement action is more severe than the facts support and there is a |
| 96 | + clear record showing compliance. |
| 97 | + |
| 98 | +Do not appeal only to ask for a faster review, to dispute policy without |
| 99 | +evidence, or to avoid making a known compliance fix. If the team both fixes an |
| 100 | +issue and appeals, state exactly what changed and what part of the decision is |
| 101 | +still being disputed. |
| 102 | + |
| 103 | +## Appeal Response Template |
| 104 | + |
| 105 | +```text |
| 106 | +Subject: Appeal for OnTime Google Play review decision |
| 107 | +
|
| 108 | +App: OnTime |
| 109 | +Package name: club.devkor.ontime |
| 110 | +Affected release: <track>, <version name>, <version code> |
| 111 | +Decision received: <date and time with timezone> |
| 112 | +Policy cited: <policy or DDA section named by Google Play> |
| 113 | +
|
| 114 | +Hello Google Play Review Team, |
| 115 | +
|
| 116 | +We are appealing the review decision for the OnTime release listed above because |
| 117 | +<one-sentence factual reason the decision appears incorrect or incomplete>. |
| 118 | +
|
| 119 | +Facts: |
| 120 | +- <Fact 1 tied to the submitted build, declaration, or store listing> |
| 121 | +- <Fact 2 tied to reviewer notes or Play Console evidence> |
| 122 | +- <Fact 3 tied to screenshots, policy text, or implemented behavior> |
| 123 | +
|
| 124 | +Fixes or verification completed: |
| 125 | +- <Code, metadata, declaration, or test change completed, or "No change needed |
| 126 | + because ..."> |
| 127 | +- <Evidence location, screenshot name, workflow run, or test result> |
| 128 | +
|
| 129 | +Requested outcome: |
| 130 | +Please re-review this release with the evidence above and reinstate approval if |
| 131 | +you agree it complies with the cited policy. |
| 132 | +
|
| 133 | +Thank you. |
| 134 | +``` |
| 135 | + |
| 136 | +## Evidence Folder Template |
| 137 | + |
| 138 | +Use this structure in the release tracking thread or shared release folder: |
| 139 | + |
| 140 | +```text |
| 141 | +play-review-rejection-<version-code>/ |
| 142 | + rejection-email.txt |
| 143 | + policy-status.png |
| 144 | + review-summary.png |
| 145 | + submitted-declarations/ |
| 146 | + store-listing-before/ |
| 147 | + store-listing-after/ |
| 148 | + build-artifact.txt |
| 149 | + fix-summary.md |
| 150 | + appeal-response.txt |
| 151 | +``` |
| 152 | + |
| 153 | +## References |
| 154 | + |
| 155 | +- Google Play Console Help: Check your app's policy status |
| 156 | + https://support.google.com/googleplay/android-developer/answer/9842754 |
| 157 | +- Google Play Console Help: Publish your app |
| 158 | + https://support.google.com/googleplay/android-developer/answer/9859751 |
| 159 | +- Google Play Developer Program Policy: Enforcement process and enforcement |
| 160 | + actions |
| 161 | + https://play.google.com/about/developer-content-policy/ |
0 commit comments