Google Play App Rejected: Every Rejection Reason and Fix

A Google Play rejection means a reviewer found one specific problem in one submission, named it in an "Issue found" line, and stopped there. The fix is always the same shape: correct the named problem in a new build, upload the corrected bundle to every track, remove the non-compliant bundle, then send the release for review again. Google's own instruction on the Policy status page is blunt about the order of operations: "Until a policy violation has been fixed, don't republish a rejected or removed app."

Rejections cluster into about ten reasons: broken functionality, thin or wrapper-only apps, store listing metadata, intellectual property, target API level, Data safety and privacy policy, content rating, deceptive claims, missing reviewer login details, and repetitive content. Each one maps to a policy page you can read before you resubmit, which is the difference between a second rejection and a second approval.

This page is written from OnTesters' own submission work: more than 1,500 closed-testing campaigns, physical devices from Samsung, Pixel, Xiaomi and OnePlus, Android 11 to 15, and testers in over 80 countries. Where a number comes from those campaigns instead of from Google, it says so. Where Google does not publish a figure, this page does not invent one.

Which rejection did you actually get?

Three different outcomes get called "rejected" in the same Slack message, and they have different fixes. Google's Policy status page separates them: "Your policy status shows any active enforcement against your app, such as rejection, removal, or suspension from Google Play." A rejection refuses the submission you just sent while your last published version stays live. A removal takes a live app off the store until a compliant update arrives. A suspension pulls the app entirely and puts an Appeal control on the page. Open Play Console, select the app, then Policy status on the left menu to see which one you are in.

The distinction matters because a policy rejection never fixes itself by testing harder, and a production-access refusal never fixes itself by editing your description. If your closed test is still running while a review rejection arrives, both clocks keep moving — the rejected submission does not pause the 14-day window, and the window does not excuse the policy issue.

Where the rejection notice actually lives

The email is a summary, not the record. Google tells you to "read the relevant policy noted in the enforcement message" and to check "your notifications and email for information about the policy that your app violated," but the durable copy sits inside Play Console. Three places carry it.

• Policy status — the enforcement, the policy cited, and the Appeal control when one exists.
• Publishing overview — the current state of the changes you have sent, and the Send for review button that nothing presses for you. Google is explicit: after a rejected update, "your changes aren't sent for review automatically. You must go to the Publishing overview page and click Send for review."
• The release review summary — per-version detail, including the version code. Rejection emails quote it directly: "We found an issue in the following area(s): Version code 55." That line is how you know which build the reviewer actually installed, which matters the moment you have two bundles in the same track.

One habit explains most "why did they only mention one thing" frustration. Google's own community guide for developers explains the review team's behaviour plainly: "The review team is not a test team; they are there to check if the app meets current policies. When they find an issue with the app they will make the rejection and let you know what policy the app has been rejected against. They will then stop reviewing your app and move onto the next app." If several obvious violations exist, they list what they saw; the ones they had not reached yet stay hidden until the next pass. That is why a resubmission that fixes only the printed line can come back rejected for something brand new.

Rejection reasons 1 to 5: the build and the listing

Rows one and two look alike in the inbox and are diagnosed differently. A crash is a build problem: reproduce it on the release artifact, not on your debug build. A wrapper refusal is a product problem: no amount of testing convinces a reviewer that a bookmark needs an APK. Rows three and five are mechanical — a character count and a manifest value — and usually clear on the first resubmission. Row four is the only one where you may need paperwork rather than code.

Rejection reasons 6 to 10: declarations, claims and account details

These five are declaration failures rather than code failures, which is why they surprise developers who tested everything. The reviewer is not judging your Kotlin; they are checking whether your forms, ratings and credentials match the app they were handed. An honest mistake in the Data safety section and a deliberate feature you left out of it produce the same rejection notice, so audit the SDKs in the build before you argue either case.

How to fix a rejection and resubmit

Google publishes the resubmission path, and it has an order. Skipping the first step is what earns a second rejection.

1. Read the cited policy, then fix it. Check the enforcement message and the policy link it names, and check the rest of your app against the other policies while you are there — Google warns that "additional enforcement could occur if there are further policy violations."
2. Ship the fix in a new build. The corrected artifact has to be a new version code. Android's versioning documentation states plainly: "You can't upload an APK to the Play Store with a versionCode you have already used for a previous version." There is no way to re-review the identical bundle you just failed with.
3. Upload across every track and deactivate the bad bundle. Google's instruction: "upload the modified, policy-compliant app bundle across all tracks, and deactivate the non-compliant app bundle(s)." Its warning is specific — if you fail to deactivate the non-compliant bundle, "your attempt to resubmit your app will fail, and live versions of your app bundle(s) may be removed from Google Play." Repeat this for internal, closed and open tracks, not just production.
4. Press Send for review yourself. On Publishing overview, changes after a rejection sit waiting: "you must go to the Publishing overview page and click Send for review to submit your changes." A corrected build that nobody submits is a fix that never happened.
5. Allow real review time. Google documents that for certain accounts review can run "up to seven days or longer in exceptional cases." Do not make cosmetic edits while you wait — changes you make after submitting may restart the review.
6. Appeal only when the decision is wrong. Google states that "you may submit one appeal per app removal, suspension or other enforcement action." If you simply had a genuine violation to fix, fixing and resubmitting is the faster road; an appeal argues that no violation occurred.

Edge case worth naming: if your update was rejected while an older version is live, that older version keeps serving users. Nothing is lost by taking a week to fix the build properly. The pressure developers feel is almost always a launch date, not a policy deadline.

What repeated rejections do to your app

One rejection is routine and carries no stated penalty. A run of them is treated differently, and Google's community team has published why. In their guide on apps suspended for repeated rejections: "We all make mistakes from time to time and have an app rejected for one reason or another, and that's ok - but when you submit an app and multiple times in succession it gets rejected (for the same or different reasons) then that is an indication the app is not yet ready for production, it's not been fully tested or checked for compliance against the policies."

The practical consequences follow from that reading. Each cycle costs you the full review queue — Google's seven-day-or-longer figure applies again — and each new submission is reviewed against current policies, so an app that drifted for two years can pick up violations it never had at launch. Their advice for the next attempt is unglamorous: test against the same build the reviewer will see (the internal test track), use the exact credentials you gave Google, copy and paste them so they match character for character, and work through Google's release checklist including the description and screenshots, not just the binary.

Repeated rejections are also the point where enforcement escalates beyond the app. Suspension is app-level and appealable from the Policy status page; termination is account-level and is a different, heavier process. If your rejections are heading that direction, stop submitting. Fix the build, fix the listing, fix the declarations, and go in once with a version you would ship to a paying user — because after approval, that is exactly what it becomes.

What our 1,500+ closed-testing campaigns show

Most of the rejection traffic we see sits on top of a closed test that is still running, so the two problems usually arrive in the same week. A rejection of a submission does not stop the 14-day clock: Google's requirement is that your testers stay "opted in continuously for at least 14 days," and an upload to the closed track does not un-opt anyone. What a rejection does cost you is time you no longer have to spare.

From our own campaign data (more than 1,500 campaigns, no overall pass rate claimed): campaigns where testers were active for 10 or more days reached approval 97% of the time; campaigns that shipped two or more app updates during testing reached approval 89% of the time; campaigns with zero updates during the window came in at 53%; and campaigns where testers were active only 5 to 7 days came in at 41%. After a rejection is fixed, second attempts reached approval 91% of the time — the same shape as Google's own guidance that a corrected resubmission, not an appeal, is the normal route.

Two operational notes. Updating during a test is normal, not suspicious — see the target API 36 guide for what a mid-test compliance build has to carry. And a rejection on a build under test does not mean your tester group failed anything: testers are measured on opt-in and activity, which is why the 12-tester count is tracked separately from review outcomes in the 12 testers requirement. If your testers report the app unavailable on their devices, that is a separate, fixable problem covered in our testers-see-not-available guide.

Frequently Asked Questions

How long does Google Play take to review a resubmission?

Google documents review times of "up to seven days or longer in exceptional cases" for certain developer accounts, and processing generally takes a few hours up to that seven-day mark. New personal accounts are the ones most often placed in the longer queue.

Can I appeal a rejected app?

Google allows one appeal per enforcement action, filed from the Policy status page where an Appeal control appears. If you had a real violation and fixed it, resubmitting a corrected build is the faster path; an appeal is for arguing the decision itself was wrong.

Does a rejection reset my 14-day closed test?

No. Google's requirement is continuous opt-in by the same 12 testers for at least 14 days; uploading a new build does not un-opt your testers or restart that count. Losing testers, pausing the test, or removing them from the track is what costs you the window — that is a testing-engagement problem, not a rejection.

Why was my app rejected when it works perfectly on my phone?

Because the reviewer tests the release artifact from Play, not your debug build from Android Studio. Signing-key fingerprints, server allowlists, remote config flags and feature toggles behave differently once Play App Signing is in play — test the exact bundle you uploaded.

How many rejections before my account is suspended?

Google publishes no fixed number. What it publishes is that repeated rejections indicate an app that has not been fully tested or checked against policies, and sustained non-compliance can escalate from app-level to account-level enforcement.

Is a rejected email the same as losing production access?

No. A review rejection refuses one submission; production access is a separate eligibility decision after closed testing. If your application for production access was refused, you are reading the wrong guide — start with production access rejected: next steps.

Do I need a new version code to resubmit?

Yes. Play will not accept a version code you have already used, so every fixed submission must be a new build with a higher versionCode, uploaded to all tracks with the non-compliant bundle deactivated.

Sources

• Check your app's policy status (Play Console Help) — Google's definition of rejection, removal and suspension, where the Policy status page sits in the console, and the instruction not to republish until the violation is fixed.
• My app has been removed from Google Play (Play Console Help) — the official six-step resubmission path, the deactivation warning for non-compliant bundles, and the one-appeal-per-enforcement rule quoted in the FAQ.
• Minimum Functionality policy (Play Console Help) — broken functionality, limited functionality and content, the crash/freeze wording quoted above, and Google's do-and-don't table for functional apps.
• Spam policy (Play Console Help) — message spam, webviews and affiliate traffic, and the repetitive-content rule that catches cloned or template apps.
• Metadata policy (Play Console Help) — the 30-character title limit, the ban on store-performance and price claims in listing text, and the rule that screenshots must match the app.
• Intellectual property policy (Play Console Help) — copyright, trademark and counterfeit rules, plus Google's instruction to bring documented permission forward before you submit.
• Target API level requirements for Google Play apps (Play Console Help) — the August 31, 2026 API 36 deadline for new apps and updates, the Wear OS, TV, Automotive and XR exceptions, and the extension window to November 1, 2026.
• User Data policy (Play Console Help) — privacy policy obligations, the Data safety section, and prominent disclosure and consent for third-party SDKs that collect user data.
• Content Ratings policy (Play Console Help) — IARC ratings, the requirement that every app carry one to be on Google Play, and how ad maturity is judged against the app's rating.
• Deceptive Behavior policy (Play Console Help) — misleading claims, impossible features, and why describing something as a prank or entertainment does not remove it from policy scope.
• Play Console Requirements (Play Console Help) — developer profile accuracy, the privacy policy and Data safety obligation, and the requirement to hand reviewers a working demo account and all access resources.
• Requirements for providing sign in details for review (Play Console Help) — credentials must be reusable, always valid regardless of location or 2FA, and supplied in English.
• Control when app changes are reviewed and published (Play Console Help) — why a corrected build waits for you to press Send for review, and how managed publishing affects that queue.
• Publish your app (Play Console Help) — app, update and item statuses, errors versus warnings on a release, and the documented seven-day-or-longer review window.
• Version your app (Android Developers) — the versionCode rules, including Play's refusal of an already-used version code and the 2,100,000,000 ceiling.
• App testing requirements for new personal developer accounts (Play Console Help) — the 12-tester, 14-day continuous opt-in requirement referenced in the FAQ and in the closed-testing section.
• Google Play Developer Community guide: app suspended for repeated rejections — written by Google's community team, not a policy page: why reviewers stop at the first issue, how repeated rejections are read, and the signing-fingerprint trap on the first Play-hosted build.
• OnTesters campaign record — internal data from more than 1,500 closed-testing campaigns run on physical Samsung, Pixel, Xiaomi and OnePlus devices, Android 11 to 15, testers across 80+ countries, with campaigns matched in under 24 hours. The figures in this article describe those campaigns only; OnTesters does not publish an overall approval rate.