If you have shipped an Android app, you have probably lived this: Google rejects an update, you fix exactly the thing the notice named, you resubmit, and it comes back rejected again. Same policy, same wording, no new information. Most people conclude the review is arbitrary or that a human never looked at it.
It usually isn't arbitrary. There are two rules sitting in Google's own Play Console documentation that almost nobody reads, and between them they explain most repeat rejections.
1. You are not supposed to be waiting for a reply
A lot of developers send the appeal/contact form and then sit there for a week waiting for a human to write back before touching anything. Google's own instructions on preparing an app for review say the opposite, in plain words:
If your update is rejected or your app is removed, please follow the instructions below to resubmit your app for review. You can complete these steps without contacting or waiting for a reply from the policy support team.
So the loop is: read the enforcement message, fix the cause, push the corrected release, hit Send for review on the Publishing overview page. No ticket, no reply, no queue. If you are waiting on an email you are just burning days.
2. The corrected build has to land on every track — and the bad one has to be deactivated
This is the one that causes the "I fixed it and it got rejected again" loop, and it is the single most expensive thing I see people miss.
When you resubmit after a policy violation, Google does not only look at production. From the resubmission instructions:
Make the appropriate changes to your app and update all release types in addition to your production release (for example, the open, closed, and internal test track releases).
and then, flagged as Important:
If you fail to deactivate the non-compliant app bundle(s), your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play.
Read that second sentence twice. Leaving the violating bundle alive on an internal test track you forgot about in March does not just risk a rejection — Google says it can take your live production app down with it.
The practical checklist is therefore:
- Upload the corrected bundle to production, open, closed and internal — every track that has a release.
- Deactivate the non-compliant bundles on each of those tracks. If the offending release is still a draft, discard it.
- Make sure the non-compliant version shows under "Not included" in the new release.
- Roll the release to 100%, then send for review.
Most people do step 1 for production only and stop.
The causes worth checking before you resubmit
In my experience the actual root cause is nearly always one of six things, and the enforcement message names the policy but not the line:
| What broke | What it looks like in the notice |
|---|---|
| Data safety answers don't match the app's real behaviour | Data safety / User data policy |
| Privacy policy missing, 404s, or is a Google Doc that needs sign-in | User data |
| Sensitive permission with no approved declaration (SMS, call log, background location, all-files access) | Permissions / sensitive data |
| The reviewer could not get past your login screen | App access instructions |
| Screenshots, title or description overselling or misdescribing the app | Metadata / deceptive behaviour |
| Build no longer meets the current target API level | Target API level requirement |
On app access specifically: if any part of the app is behind a login, you have to give working credentials in App content → App access, and you can add up to five sets of instructions. A demo account that expired two months ago reads to a reviewer exactly like a broken app.
How long the resubmission actually takes
Usually hours to a couple of days. But Google is explicit that it is not uniform:
For certain developer accounts, we'll take more time to thoroughly review your app to help better protect users. This may result in review times of up to seven days or longer in exceptional cases.
Nobody — no agency, no consultant, no "Play Store expert" on a freelance site — can shorten that queue. If someone tells you they can, that alone is the tell.
One thing that is not a rejection
If your app is sitting in closed testing and you cannot push to production, that is usually not an enforcement action at all. Personal developer accounts created after 13 November 2023 have to run a closed test with at least 12 testers opted in continuously for 14 days before they can even apply for production access. Testers who opt in, test for a few days and drop out do not count, and the 14 days have to be consecutive. It is a waiting requirement, not a violation, and there is nothing to fix.
Sources
- Prepare your app for review — https://support.google.com/googleplay/android-developer/answer/9859455
- My app has been removed from Google Play (resubmission + appeals) — https://support.google.com/googleplay/android-developer/answer/2477981
- Publish your app (review times) — https://support.google.com/googleplay/android-developer/answer/9859751
- App testing requirements for new personal developer accounts — https://support.google.com/googleplay/android-developer/answer/14151465
Disclosure: I write for ZoopCoder, an Indian development studio, and we sell a fixed-price Play Store rejection fix at ₹2,999 — diagnosis plus resubmission in 2-4 working days. Everything above is in Google's public documentation and you can do all of it yourself for free; I wrote it up because the two-track rule costs people weeks. We do not guarantee approval and nobody honestly can. If the hold-up is the 14-day tester clock rather than a rejection, this piece on how long an app actually takes to go live in India has the timeline.
Top comments (0)