Google Play rejected your app. The email names a policy, not a fix.
Play explains itself less than App Review does. The mail names a policy, links to a page about that policy, and leaves you to work out which screen, which SDK or which line of the manifest it meant.
The one that stops most people is not a rejection at all. A personal developer account opened after November 2023 cannot publish anything until twelve testers have sat in a closed test for fourteen unbroken days, and nothing you change about the app moves that.
The short answer
Play rejections name a policy, never a line of code, and four causes account for most of them. The Data safety form does not match what the app and its SDKs collect. The app targets an Android version older than Play now allows, which blocks updates but leaves the app in the store. Account creation exists with no way to request deletion, including from a web page that works without installing anything. And a permission sits in the merged manifest that nobody declared, usually added by a library, not by you. Separately, a personal developer account opened after November 2023 cannot publish at all until twelve testers have been opted in to a closed test continuously for fourteen days.
What the policy name usually means.
- 01
You cannot publish yet, and it is not a rejection
A personal developer account opened after November 2023 has to run a closed test before Google will let it apply for production access. Twelve testers, opted in through the test link with real Google accounts, held for fourteen days. Google’s own wording is continuously, so a tester who opts out and drops you to eleven restarts the count from zero.
This is calendar time and nothing compresses it, so it belongs in the plan before the build finishes. Organisation accounts are exempt from the rule, and becoming one is its own application, with Google asking for company registration details.
- 02
The Data safety form does not match the app
Play checks what you declared against what the app does, and the mismatch is almost never something you wrote. An analytics package collects an advertising identifier, a crash reporter ships device details, a payment library sends an email address. All of that is collection and sharing under Play’s definitions, and all of it belongs on the form under your name.
List every third-party package in the build first and read what each one says it collects, then fill the form from that list. Fill the form first and it describes what you meant to build.
- 03
The app targets an Android version Play has retired
Play requires new apps and updates to target a recent Android API level, and it moves the floor on a published deadline every year. Falling behind does not remove the app. It stops you shipping updates, and it stops people on newer Android from installing it at all, and there is no email about it, just downloads flattening.
The fix is a target level bump and whatever behaviour change came with that Android release, which is usually storage or background work. If the app was generated, expect the behaviour change to be the real job and the version number to be the easy part.
- 04
Account deletion, in two places
If people can create an account, Play wants a way to request deletion inside the app and a web page that does the same thing without installing anything. That second half is the one that catches everybody who did the Apple work first, because App Review never asked for it.
The web page has to be reachable by anyone, has to say what gets deleted and what is kept, and its URL goes into Play Console alongside the listing.
- 05
A permission in the manifest that nobody declared
Sensitive permissions each carry a declaration form in Play Console, and several want a video showing the feature that needs them. All-files access, SMS and call log, exact alarms, accessibility services, and foreground service types all sit in that group.
They arrive through libraries, so reading your own source tells you nothing. Read the merged manifest instead, where your own permissions sit beside every permission your dependencies asked for on your behalf.
- 06
The report Google already ran for you
Upload a build to any track and Play runs it on real devices before you publish, then hands back the crashes, the frozen frames and the accessibility problems it found. It costs nothing and most people never open it.
Read it before you submit, because a crash Google found on a Pixel 6 is a crash the reviewer is about to find too.
Before you resubmit.
Six things you can settle from Play Console and a terminal. Start with the two that are calendar time, because nothing you do moves them any faster.
- 01
The closed test is running
Open the closed testing track in Play Console and count testers who have opted in, not testers you invited.
Bad answerEleven, or twelve where somebody joined yesterday.
- 02
You know every permission the build asks for
Skip your source and read the merged manifest. Build a release APK and dump what it declares.
./gradlew app:assembleRelease && aapt2 dump permissions app/build/outputs/apk/release/app-release.apkBad answerA permission you cannot name the feature for.
- 03
The Data safety form covers your SDKs, not just your code
List every third-party package in the build, then read each one’s stated collection against the form.
Bad answerAn analytics or ads package that collects an identifier you did not declare.
- 04
Account deletion exists in the app and on the web
Open your deletion URL in a private window on a device with the app uninstalled.
Bad answerIt only exists inside the app, which is all App Review asked for.
- 05
The target API level is current
Read the target level out of the build file and compare it to Play’s published floor.
grep -rn "targetSdk" app/build.gradle app/build.gradle.kts 2>/dev/nullBad answerA level Play stopped accepting at the last deadline.
- 06
The pre-launch report is clean
Upload the build, wait for the report, and read the crashes and the accessibility findings.
Bad answerYou have never opened it.
When this sheet is the wrong one
None of this touches a suspension. If the account itself has been terminated, and it is not just one app rejected, the appeal is a different form with worse odds, and there is nothing in a build that answers it. A code change cannot fix a terminated account, whatever anybody offers to sell you.
Asked most often.
- How long does Google Play review take?
- Google says a first submission can take up to seven days and sometimes longer, with updates usually faster. A new personal account has the fourteen-day closed test in front of that, so plan on about three weeks from a standing start.
- Do you really need twelve testers?
- For a personal developer account opened after November 2023, yes. Organisation accounts are exempt. The testers have to be real Google accounts that opted in through the test link, and Google’s wording is continuously, so people dropping out restarts the fourteen days.
- Can the same account deletion page serve iOS and Android?
- The in-app path can be shared. Play also wants a web URL that works with the app uninstalled, which App Review never asked for, and that is the half people miss after shipping on iOS first.
- The app was fine last year and now updates are refused.
- Check the target API level before anything else. Play raises the required level on an annual deadline, and an app that stops accepting updates with no policy email attached is usually sitting behind the last one.