Google Play rejection reasons and how to fix them

Google Play rejections tend to be about declarations more than design: a Data safety form that does not match what the app collects, a missing account deletion link, an undeclared sensitive permission or an outdated target API level. This guide lists the common rejection and removal reasons, what to fix for each, and a Play policy check your AI beta tester can run on the build before you submit it for review.

Who it’s for

  • Android developers submitting a first app or a policy-sensitive update
  • Founders with a rejected or removed app who need to understand the notice
  • Cross-platform teams shipping the Android build of a Flutter or React Native app
  • Teams preparing a new personal developer account for production access

Updated 2026-10-25.

How Google Play review works

Every release goes through a review against the Developer Program Policies. Unlike App Review at Apple, Play's review is largely automated with human review for flagged cases, and it can reject a release before publishing or remove an app that is already live. The notice arrives by email and in the Play Console's Policy status page, naming the policy and sometimes the exact screen or declaration at fault.

Google changes policies and deadlines regularly. Treat this list as a map of where problems usually are, and check the current policy text and the Policy status page for what applies to your app today.

The most common rejection reasons

Data safety form does not match the app

The Data safety section is a declaration of what data your app and its SDKs collect, share and why. Play compares it against the APK's behavior and the known behavior of the SDKs you include. Analytics, crash reporting, ads and payment SDKs collect data even if your own code does not. If the form says "no data collected" and the app contains an ads SDK, expect a rejection.

Fix: list every SDK, read each vendor's data disclosure, then fill the form to match. Update the form when you add an SDK.

Account deletion requirements

If your app lets users create an account, Play requires an in-app path to delete it and a web link where users can request deletion without reinstalling the app. The link is declared in the Data safety form. Deleting the account must delete the associated data too, unless you must keep some of it for legal reasons, in which case say so. See the account deletion guide for what to test.

Sensitive permissions and APIs

Permissions such as SMS and Call Log, background location, accessibility services, All files access (MANAGE_EXTERNAL_STORAGE) and QUERY_ALL_PACKAGES are restricted. You need a declaration in the Play Console explaining the core use case, sometimes a video, and the use has to be essential, not convenient. Asking for a permission you do not clearly need in the user-facing flow is a frequent cause of rejection.

Fix: remove permissions you do not use, request the rest in context, and make sure the declared use case is visible in the app the reviewer sees.

Target API level

New apps and updates must target a recent Android API level. The rule is roughly that the target level must be within one year of the latest major Android release; the exact level and deadline change every year, so check the current requirement in the Play Console. Builds below the required level cannot be submitted to production, and existing apps that fall too far behind are hidden from new users on newer devices.

Payments and Play Billing

Digital goods and services consumed inside the app, including subscriptions and premium features, must use Google Play's billing system. Physical goods and services delivered outside the app may use other processors. Linking users to a web page to pay for an in-app digital feature is a rejection unless a current program or regional rule allows it. Verify the current Payments policy for your markets.

Content rating

Every app needs a completed content rating questionnaire (IARC). Unrated apps are removed, and a rating that does not match the content (for example, user-generated content or gambling features not declared) leads to a re-rating or rejection. Re-answer the questionnaire when you add features such as chat, user-generated content or purchases.

Misleading or incomplete store listing

Screenshots that do not match the app, keywords in the title, claims about awards or rankings, "best" or "number one" without support, and descriptions that mention features that do not exist fall under Metadata and Deceptive Behavior policies. Also, the listing's privacy policy link must work and be relevant.

Broken functionality

The Minimum Functionality policy rejects apps that crash, do not install, show placeholder content, have no meaningful function, or whose core features do not work during review. Reviewers test with a fresh install on a Play-certified device, so give them a working test account in the App access section of the console.

Families and children

If any part of the app targets children, or your target audience includes under-13 users, the Families policy applies: approved SDKs only, no behavioral ads, and stricter data handling. Declaring the wrong target audience is itself a reason for rejection.

What to do after a rejection or removal

  1. Open Policy status in the Play Console and read the exact policy and, where provided, the screenshot or declaration at fault.
  2. Decide whether it is a declaration fix (Data safety, permissions form, content rating) or a code fix (permission removal, billing flow, target API).
  3. Fix, bump the version code and submit the update. Declaration fixes can be submitted without a new build.
  4. If you think the decision is wrong, use the appeal form linked from the notice; be specific about where in the app the reviewer can see compliance.
  5. Repeated violations and strikes can lead to account termination, so fix recurring issues at the root rather than resubmitting.

Example Play policy finding

Title: Data safety form declares no data collection, app contains analytics SDK
Policy at risk: User Data / Data safety section
Environment: Pixel 8 emulator, Android 15, build 2.0.0 (210)

Observed: The app requests the ADVERTISING_ID permission and sends events to
an analytics endpoint on launch and on each screen view. The Play listing's
Data safety section states that the app does not collect or share data.

Severity: High (common rejection and removal trigger)

Fix: Declare device identifiers and app interactions as collected, state the
purpose (analytics), and update when SDKs change.

How to test before you submit

  1. Install the release build clean on an emulator or device and walk every screen with the test account.
  2. List the permissions in the manifest and compare them with the prompts you can actually reach in the app; remove or declare the rest.
  3. Open the Data safety form next to your SDK list and match each row.
  4. Find account deletion from the main settings screen and complete it with a throwaway account; confirm the web deletion link works while signed out.
  5. Run every purchase and subscription flow with license testers to confirm they go through Play Billing.
  6. Compare each listing screenshot and claim against the app.
  7. Check the target API level in the build and the current requirement in the console.

How an AI beta tester helps

betatest.ing's Store readiness tests run the Google Play policy checklist on your uploaded .apk or .aab on an Android emulator or device: clean install, every screen, the test login, permission prompts and whether the use is visible in the flow, the in-app account deletion path and web link, billing flows with license testers only, legal links and the listing comparison. Findings come back with the policy they risk, steps to reproduce, severity, annotated screenshots and recordings where a flow breaks, plus a scored report. It cannot see your Data safety form or the Play Console, so it reports what the app does and you check the declaration against it.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Run a Google Play policy check on my Android app [UPLOADED .APK/.AAB OR PUBLIC PLAY LINK] on a phone. It is [WHAT THE APP DOES]. Install it clean and go through every screen with the saved test login. Note every permission prompt and whether the feature that needs it is visible in the flow; flag permissions that appear with no clear purpose, especially SMS, call log, background location, accessibility or all-files access. Confirm the privacy policy link works from inside the app. Find account deletion from the settings screen and complete it with a throwaway account; report if it only deactivates or sends you to email support. Start each purchase or subscription flow and report whether it uses Google Play billing or sends you to a website; do not complete any purchase. Compare the app against the store listing [PLAY LISTING URL OR 'skip'] for screenshots or claims that do not match. List the network destinations or SDK behavior you can observe (analytics, ads) so I can check the Data safety form. Log each issue as a finding with the policy it risks, steps to reproduce, severity and an annotated screenshot, and end with a report that scores Play policy readiness with the top fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [UPLOADED .APK/.AAB OR PUBLIC PLAY LINK] "the uploaded .aab" for a new build, or the Play Store link of the live version
  • [WHAT THE APP DOES] One sentence about the app and its users
  • [PLAY LISTING URL OR 'skip'] Your public listing to compare screenshots and claims against, or skip for a first submission

What the AI beta tester checks

  • Clean install, launch and test login on an Android emulator or device
  • Crashes, placeholder content and features that do not work (Minimum Functionality)
  • Permission prompts in context; sensitive permissions with a visible use case
  • Privacy policy link working from inside the app and the listing
  • In-app account deletion path and the signed-out web deletion link
  • Purchases and subscriptions through Play Billing, tested with license testers only
  • Observable analytics and ads behavior to compare with the Data safety form
  • Store listing screenshots and claims versus the real app
  • Content that may require a different content rating (chat, user content, gambling)

What you get

  • Findings tagged with the Play policy each one risks
  • Steps to reproduce, severity and annotated screenshots per issue
  • Recordings of flows that break or redirect to external payment
  • A list of observed permissions and SDK behavior to check against your declarations
  • A Play policy readiness score with the top fixes

How to run it with betatest.ing

  1. Add your app as a project in betatest.ing and upload the .apk or .aab you intend to release.
  2. Save the test account you will give Google reviewers as the project's test login.
  3. Send the Play policy check task; the tester runs it on an Android emulator or device.
  4. Fix the flagged items and update the Data safety form, then re-run on the new build before submitting.

Tips

  • Keep a living list of every SDK and what each collects; update the Data safety form whenever it changes.
  • Request permissions in context and remove any the app does not use in a visible feature.
  • Fill in App access with a working test account so reviewers can reach gated screens.
  • Check the current target API level deadline every year before your release window.
  • Use license testers for billing so nobody on the team pays real money during checks.

Google Play rejection reasons: FAQ

What is the most common Google Play rejection reason?

Declaration mismatches are the usual cause: a Data safety form that does not match the app's SDKs and behavior, missing account deletion information, or sensitive permissions without an approved declaration. Broken functionality and misleading listings follow.

Why was my app rejected for Data safety when my code collects nothing?

Third-party SDKs for analytics, crash reporting, ads and payments collect data on their own. Play compares your form with the behavior of the whole APK, including those SDKs, so each one must be reflected in the form.

Does Google Play require account deletion?

Yes, for apps that allow account creation. You need an in-app way to delete the account and a web link where users can request deletion, both declared in the Data safety form. Associated data must be deleted too unless you must keep it for legal reasons.

What target API level do I need?

New apps and updates must target a recent API level; the rule has been within about one year of the latest major Android release, with exact levels and deadlines changing annually. Check the current requirement in the Play Console before you build.

Can I use Stripe or PayPal in my Android app?

For physical goods and services consumed outside the app, yes. For digital content, features and subscriptions used inside the app, Google Play's billing system is required unless a current program or regional rule says otherwise. Verify the current Payments policy.

What happens if my app is removed instead of rejected?

Removal takes a live app offline until you fix the violation and submit an update. Repeated or severe violations can lead to strikes and account termination, so fix the root cause and read the notice carefully before resubmitting.

How do I appeal a Google Play decision?

The notice and the Policy status page link to an appeal form. State exactly where in the app the reviewer can verify compliance, and submit a fixed build in parallel when the fix is quick; appeals can take longer than a resubmission.

Can an AI beta tester check Play policy compliance?

It can test what is observable in the app: permissions and their context, account deletion, billing flows, legal links, placeholder content and listing mismatches, and it reports SDK behavior it can see. It cannot read your Play Console declarations, so you compare its findings with your Data safety form.

Related beta testing guides

  • App Store rejection reasons — Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.
  • In-app account deletion requirement — Both app stores require apps that let users create an account to let them delete it, inside the app, for real. It is one of the most common reasons an otherwise finished app gets rejected. This page explains what Apple and Google require, how grace periods, data export and subscriptions fit in, and what to test so the deletion flow passes review and actually works.
  • Google Play closed testing — Closed testing is the Google Play track where invited testers install your app from the Play Store before anyone else, and for new personal developer accounts it is a mandatory step before production. This guide explains how the track works, what the 12 testers for 14 days requirement really means, how to apply for production access, and what to test while the clock runs.
  • In-app purchase testing — In-app purchases are the flow you can least afford to ship broken and the one teams test least, because nobody wants to pay real money on every build. This guide covers how the Apple and Google sandboxes work, which subscription states to test, and a task your AI beta tester can run against your paywall without ever completing a real purchase.
  • Android app beta testing — Android beta testing means getting a test build onto many different phones and finding what breaks before the public release. Here is how Google Play testing tracks work, what to test that is specific to Android, and a task your AI beta tester can run from your uploaded build or Play link.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in guides