App rejected by Google Play? Read the email, fix the cause, get approved

What does “app rejected by Google Play” actually mean?

It means one specific release you sent for review was not published because the reviewer found something that breaks a Google Play policy or the Developer Distribution Agreement. It is the mildest of the three enforcement outcomes and, in most cases, a to-do list rather than a verdict on your app.

Google's own enforcement documentation separates three outcomes, and it helps to know which one you are holding before you touch anything. A rejection blocks the new version; if an earlier version was already live, that version stays available to users and Google says a rejection does not affect your developer account standing. A removal takes the live listing down until you send a compliant update, and Google warns that repeated removals can lead to a suspension. A suspension is the serious one: it counts as a strike against the account and the listing's users, ratings and statistics are lost. That last case has its own guide on what to do when a Google Play app is suspended.

For a first-time publisher, “rejected” can feel like the end of the road, especially after weeks of development. It rarely is. Most Play rejections we see come from paperwork around the app (a Data safety answer, a missing deletion link, a permission nobody declared) rather than from the app's core idea. The work is to find the exact mismatch, correct it everywhere it appears, and send a release that gives the reviewer no reason to stop.

How do I read a Google Play rejection email?

Read it for three things: the policy name, the evidence, and the version it applies to. Those three tell you where to look; the rest of the email is standard text about policies and appeals.

Rejection emails follow a pattern. Near the top you will see the policy area, such as User Data, Permissions, Metadata or Broken Functionality. Below that there is usually an “issue found” line and often an example: a screenshot, a store listing field, an APK or bundle version code, or a line such as “the app is missing a prominent disclosure”. That example is the most valuable part of the message, because it is the reviewer showing you where they stopped.

Then open Play Console, pick the app and choose Policy status in the left menu. Google's help page describes it as the place that shows active enforcement (rejection, removal or suspension) with details to help you address the issue. Check the Inbox too; sometimes a declaration request or deadline arrived earlier and the rejection is the consequence.

• Policy name: open the matching page in the Policy Center and read the whole policy, not only the paragraph quoted.
• Evidence: screenshot, field or screen; reproduce it on a phone yourself.
• Version code: confirm which bundle was reviewed; an older bundle on a testing track can still trigger rejection.
• Deadline or action: note any date given for a declaration or form.

Copy the email into a shared document before you start. Every later decision, including whether to appeal, depends on quoting it accurately.

Why was my app rejected by Google Play? Sorting the cause into four buckets

Almost every reason for an app rejected by Google Play falls into one of four buckets: the store listing, a Play Console declaration, the compiled build, or reviewer access. Naming the bucket first stops you from rebuilding code when only a form was wrong, or rewriting a form when the code is the problem.

A single rejection can touch two buckets. A photo permission rejection, for example, often needs a code change (switch to the system photo picker) and a declaration update. Write down every bucket involved so none is forgotten in the resubmission.

Data safety form mismatches: the most common fix for an app rejected by Google Play

If the rejection mentions User Data or the Data safety section, the answers you gave do not match what the app, including its third-party libraries, actually collects or shares. The fix is to find out what the build really does and answer truthfully, not to tick “no data collected” and hope.

Google's help page is direct about this: all developers with an app on Google Play must complete the Data safety form, including apps on closed, open or production testing tracks, and developers alone are responsible for complete and accurate declarations. Even an app that collects nothing must complete the form and link a privacy policy that says so. Where Google finds a misrepresentation, it requires a fix, and apps that do not comply face enforcement such as blocked updates or removal.

The trap is that you often did not write the collecting code. A Flutter or React Native app pulls in analytics, crash reporting, push notification, ads, maps and login packages, and many of them send device identifiers, approximate location or app interaction data by default. Your form has to cover them.

• List every dependency in pubspec.yaml, package.json or build.gradle and check each vendor's published data disclosure for Google Play.
• Decide for each data type whether it is collected, shared, optional, encrypted in transit and deletable.
• Turn off collection you do not need (for example, advertising ID in an app without ads) instead of declaring it.
• Make the privacy policy say the same thing as the form, in the same categories.

We keep the SDK audit as a small spreadsheet in your project folder, so the next developer who adds a library can update the form in minutes rather than trigger the same rejection again.

Privacy policy rejections: missing, broken or contradicting the app

A privacy policy rejection means the link is missing, does not load, is a PDF or a generic template that does not describe your app, or disagrees with your Data safety answers. The fix is a public web page, owned by you, that describes this app's data practices accurately.

Google requires a privacy policy link to complete the Data safety form at all, so this is not optional even for simple apps. Reviewers look for a few basics: the page loads without login, names the app or developer, explains what is collected and why, explains how data is shared and retained, and gives a way to request deletion. Many rejected apps link to a document copied from another app or a free generator that mentions payments, location or contacts the app never touches, which is itself a mismatch.

Host the policy on your own domain rather than a shared document link that can break or change permissions. If you do not have a website yet, a single page on a small business website is enough, and it gives you a place for the account-deletion page too. We write the draft from your Data safety audit and you approve it; for legal wording on specific obligations, your own lawyer should review it, because we build the page, we do not give legal advice.

Rejected for SMS, call log, location or photo permissions: what to change

Permission rejections happen when the manifest requests a sensitive permission without an approved declaration or a core use that justifies it. Usually the right fix is to remove the permission or replace it with a narrower API, and only declare it when the feature truly cannot work another way.

Google's permissions documentation lists the ones that need a Play Console declaration: SMS and call log permissions, background location, QUERY_ALL_PACKAGES, all-files access (MANAGE_EXTERNAL_STORAGE), the Accessibility API when the app is not an accessibility tool, and, for apps targeting Android 13 or later, READ_MEDIA_IMAGES and READ_MEDIA_VIDEO. A declaration without a convincing core use is rejected.

If a declaration is genuinely needed, record a short video of the feature and explain in one or two sentences why no alternative works. Vague declarations are the ones that bounce back.

Account deletion: the requirement behind many update rejections

If users can create an account in your app, Google Play requires both an in-app way to delete the account and its data and a web link where deletion can be requested. Missing either one is a common reason an update gets rejected.

Google's account deletion help page asks for an in-app path that is intuitive and prominent, typically inside account settings, and a working web resource where the request option is easy to find. Permanently private apps and enterprise device management apps are exempt; Android TV and Wear OS apps only need the web option. Signing a user out, or hiding a “contact us to delete” line in the privacy policy, does not meet the requirement.

The build work is modest but must be real. Deletion should remove or anonymise the user's data on your server within the period your Data safety answers state, and it should handle the edge cases: pending orders, active subscriptions, data you must keep for invoices or legal reasons (which you disclose rather than silently keep). On the web side, a simple form or page on your domain that explains the steps and accepts a request is enough, as long as it loads and matches the app name.

We usually add three pieces together: a Delete account button under profile settings with a confirmation step, a server endpoint that performs deletion and logs it, and a public deletion page linked in the Data safety section. Doing all three at once avoids a second rejection for the half that was forgotten.

Store listing and metadata problems in an app rejected by Google Play

Metadata rejections mean something in the title, descriptions or graphics is misleading, irrelevant or promotional in a way the policy forbids. These are the fastest fixes because they need no new build, only a corrected listing.

Google's metadata policy limits the title to 30 characters and rules out emojis, repeated special characters and ALL CAPS unless they are part of the brand. It bans text or images in the title, icon or developer name that signal store performance, ranking, price or promotions, with examples such as “#1” and “Best of Play”. It also disallows repetitive or unrelated keywords and unattributed testimonials in the description.

• Remove words like “best”, “No.1”, “free” banners or discount badges from the icon and title.
• Delete competitor app names from descriptions, even in comparisons.
• Replace keyword lists at the bottom of the description with plain sentences about features.
• Show only screens that exist in the reviewed build; mock-ups of planned features count as misleading.
• Check that the developer name and contact email are real and consistent with the privacy policy.

A cleaned listing can still rank. Honest titles with the app's real function, good screenshots and replies to reviews do more for installs than stuffed text; that is the work covered on our app store optimization services page and in how to rank an app on the Play Store.

Why the reviewer could not get into your app, and how to fix App access

If the reviewer met a login screen, an OTP, a region block or a paywall they could not pass, the review fails because they could not check the app. The fix is complete, working sign-in instructions under App content, App access.

Google's sign-in requirements are specific. The details must be accessible at all times, reusable and valid regardless of location, maintained without errors, and provided in English. For paid or subscription features, you give instructions or access that let reviewers use the content behind the paywall. For two-factor or location-based login, you give reusable credentials that bypass those steps.

In practice, this trips up a lot of Indian apps because login is phone-number OTP only. A reviewer outside India will not receive an SMS on your test number. The usual solution is a dedicated review account whose OTP is fixed on the server side, or an email and password login used only for review, kept active and limited to test data. Add written steps too: “log in, tap Orders, place a test order with the COD option”.

Check the account the day before you resubmit and again after. A test account that expired, got deleted in a database clean-up or was locked after repeated attempts is a surprisingly common reason for a second rejection.

Crashes, broken features and minimum functionality

Google Play rejects apps that crash, freeze, fail to install or load, or that do too little to count as an app. The fix is either stability work or adding real app-specific function, not a new description.

The policy text covers both sides. On broken functionality, it says Google does not allow apps that crash, force close, freeze or otherwise behave abnormally, including apps that install but do not load or load but do not respond. On minimum functionality, it gives examples such as static text-only or PDF apps, apps with very little content, and apps designed to do nothing.

Two patterns come up often. The first is an app that works on the developer's flagship phone but crashes on a low-memory Android device or an older Android version the reviewer happens to use; we test the release build on a spread of devices and read the pre-launch report in Play Console. The second is a thin wrapper that opens a website in a webview with nothing else. A webview app is not banned by name, but if it adds nothing beyond the site, it risks the minimum functionality rules. Adding offline access, push notifications that matter, device features or a native flow for the main task usually changes that; sometimes the honest answer is that a progressive web app fits better than a store listing.

Target API level, new-account testing and other blocks that look like rejections

Some “rejections” are really submission blocks: Play Console will not accept the release because the target API level is too old, or production access is not yet granted on a new personal account. They need different fixes from a policy violation.

Google's target API page says that from 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher, with lower targets for Wear OS, Android Automotive OS, Android TV and Android XR apps. Developers can request an extension to 1 November 2026. For an old Flutter or React Native project, raising the target often means updating the framework, several plugins and the Gradle setup, then retesting permissions and notifications that behave differently on newer Android versions.

New personal developer accounts face a separate step. Google's help page says they need a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access from the Dashboard, and answering questions about the test and the app. If production access is refused, that is a testing requirement, not a policy verdict, and the fix is a better closed test with real feedback and visible updates.

Rejections that hit Indian apps harder: loans, OTP login and copied brands

Indian apps meet a few rejection causes more often: personal loan rules, OTP-only logins, SMS permissions and listings that borrow a bigger brand's name or look. Each has a clear fix once you know the rule.

Personal loan apps in India face the strictest check. Google's financial services policy says only apps that submit a licence and appear on the Reserve Bank of India's list of digital lending apps deployed by regulated entities may submit personal loan apps, and it bars such apps from sensitive permissions including READ_CONTACTS, ACCESS_FINE_LOCATION, READ_MEDIA_IMAGES and QUERY_ALL_PACKAGES. If your lending partner is not on that list, no code change will get the app approved, and we will tell you that before quoting.

Brand and impersonation problems are the other big group. A logo resembling a government scheme, a bank or a popular app, or a name that suggests an official link, gets rejected quickly. Your listing and icon should make clear who publishes the app. Hindi or regional-language listings are welcome, but every translation must say the same as the English one, and claims must match the app in each language.

Finally, remember that Google's reviewers may not read Hindi. Screens and reviewer instructions should be understandable in English, and test credentials must be in English as the sign-in requirements state.

Should you appeal or fix when an app is rejected by Google Play?

Fix when the reviewer's example is real, even partly. Appeal only when you can show, with screenshots or a video, that the app already complies with the exact policy cited. Google's help page says you can submit one appeal per enforcement action, so a weak appeal wastes your only attempt.

Our decision rule is simple. Reproduce the reviewer's example on a device. If you can see it, fix it; arguing about something visible never helps. If you cannot see it, check whether an older bundle on a testing track, a different device language or a merged library permission could explain it. Only when all of those are ruled out is an appeal likely to be worth your one shot.

A good appeal is short and factual: the policy name, the version code, what the reviewer said, and three or four points showing compliance, each with evidence. Emotional appeals, long histories of the project and claims about how many users rely on the app do not change policy decisions. If the reviewer was right about one thing and wrong about another, fix the right part and explain the rest in the resubmission notes instead of appealing.

How to fix and resubmit an app rejected by Google Play, step by step

Resubmitting means sending a new release where the problem is gone from every track, not just the one the reviewer looked at. Google's help pages say not to resubmit until all violations are fixed, and to deactivate non-compliant bundles, otherwise the resubmission fails.

• Write down the policy, evidence and version code from the email and Policy status.
• Fix the listing, declarations and code together; bump the version code for any new build.
• Check closed, open and internal testing tracks for older bundles with the same problem and replace or deactivate them.
• Update the Data safety form, App access and permission declarations to match the new build.
• Test the release bundle on at least two real Android devices of different age and read the pre-launch report.
• Send the release for review with brief release notes describing what changed for the policy cited.
• Watch Policy status and email; Google says some reviews may take up to seven days or longer in exceptional cases.

Resist sending several quick resubmissions to “test” what the reviewer accepts. Each attempt that still contains the issue adds to the history on the app, and multiple removals can escalate. One careful release is faster in the end.

Worked example: a coaching app in Jaipur rejected by Google Play (hypothetical)

Say a coaching institute in Jaipur has a Flutter app for recorded lectures and fee payments. Its first update in months is rejected under User Data, with a screenshot of the profile screen and a note that the Data safety section is inaccurate. Here is how we would work it.

Day one, we read the email and Policy status and reproduce the flow. The Data safety form says no data is collected, but the app uses Firebase Analytics, a crash reporter, a video player that logs playback events, and a phone-number login. That is collected personal info, device identifiers and app activity at minimum. The privacy policy link is a shared document that no longer opens. The manifest also contains READ_SMS, added years ago for OTP auto-fill.

The fix list is itemised in the quote: a truthful Data safety form built from an SDK audit; a privacy policy page on the institute's website; an in-app Delete account option and a public deletion page, because students create accounts; READ_SMS removed in favour of the SMS User Consent API; a review login with a fixed OTP under App access; and a target API check, since the old plugins may block the update under the 2026 requirement.

The institute approves, we raise the version code, clear an old bundle from the closed testing track, and resubmit with release notes. What happens next is Google's decision and timing, and we would not pretend otherwise; what the institute gets is a release where every point in the email has a documented answer.

Checklist before you resubmit an app rejected by Google Play

Run through this list before pressing Send for review. Each line is a question a reviewer is likely to ask, so a “no” anywhere is worth fixing first.

• Can you point to the exact screen, field or permission in the rejection email, and is it gone?
• Does the Data safety form match every SDK in the release build, not only your own code?
• Does the privacy policy load on a public URL on your domain and match the form?
• If users create accounts, is there an in-app delete option and a working web deletion page?
• Is every sensitive permission in the merged manifest needed, with an approved declaration where required?
• Does the listing avoid ranking claims, other brands, repeated keywords and screens the app lacks?
• Can a reviewer outside India log in with the App access details, in English, without an SMS?
• Does the build target the API level Google currently requires?
• Are old non-compliant bundles on every track deactivated or replaced?
• Is there a short written record of what changed, for the next update and any appeal?

Getting help with an app rejected by Google Play: how we work and what it costs

Send the rejection email and your Play Store link on WhatsApp. We reply with what we think the cause is, what we need access to, and an itemised quote in about two working days. Nothing is billed before you approve it in writing.

You keep ownership throughout. The Play Console account, the signing key setup, the source code and the listing stay in your name; you add us as users with the permissions the job needs and remove access when it is done. We never ask for your Google account password, and you should be wary of anyone who does.

The work itself is shared across the team. One of us handles app code and builds in Flutter, React Native or native Android. Another of us handles data audits, cloud back-ends and the technical parts of privacy and deletion flows. The third of us keeps the change log, the fix list and the resubmission notes in order, and is usually the person you talk to on WhatsApp in English or Hindi.

On cost, a listing or form correction is a small itemised line; permission rewrites, deletion flows and target API upgrades are larger. If the app is old and fragile, we will say when a rebuild from ₹40,000 (about US$600) is more sensible than patching. After approval, ongoing app maintenance from ₹8,000/mo keeps each future update inside policy; see our pricing page for all starting prices.