Google Play rejections: the policies that catch indie developers
Google Play rejection reasons indie developers hit most: Data safety, account deletion, permissions, target API level, Play Billing, and how to test each. By betatest.ing team · October 18, 2026 · 7 min read.
Key takeaways
- Data safety answers must match what the app and every SDK actually collect; reconcile each SDK's documentation with your form.
- Account deletion must exist in-app and through a declared web link, and it must actually delete.
- Read the merged manifest of the release build: library-added permissions and restricted permissions without a declaration are common rejection causes.
- Target API level and 16 KB page-size requirements move every year; check the current deadline before each update.
- Digital goods must use Play Billing with clear subscription terms; metadata must not imply a relationship with other brands.
In this article
- Data safety section does not match the app
- Account deletion is missing or not discoverable
- Permissions without a reason, or restricted permissions without approval
- Target API level is too old
- Digital purchases outside Play Billing
- Broken functionality and minimum functionality
- Metadata, impersonation and misleading claims
- Deceptive behavior and undisclosed changes
- Families and content ratings
- Developer account and verification problems
- Related guides
- Turning this into a pre-submission routine
Google Play review feels different from App Review. Much of it is automated, a rejection often arrives as a policy email with a section name rather than a conversation, and the fix is frequently a form in Play Console rather than a code change. That makes Play rejections both easier and more frustrating: easier because the rules are written down in the Developer Program Policies, and frustrating because a mismatch between a form and your binary can hold a release for days.
This post covers the policies that indie developers hit most, what each one actually requires, and the test that proves you pass before you submit.
Data safety section does not match the app
The Data safety form in Play Console asks what data your app collects and shares, whether it is encrypted in transit, whether users can request deletion, and the purpose of each item. Google's User Data policy requires the form to be accurate, and Google checks it against your app's actual behavior, including SDK behavior.
Why indie apps fail: the developer answers for their own code and forgets the SDKs. Analytics, crash reporting, ads and attribution libraries all collect device identifiers and usage data. Many SDK vendors publish a data safety guide for exactly this reason.
Test: list every SDK in the release build. For each, find the vendor's Data safety documentation and reconcile it with your form. Then run the app with a network inspector and check what actually leaves the device on first launch before the user has consented to anything.
Account deletion is missing or not discoverable
Since 2024, apps that allow account creation must also provide a way to delete the account, both from inside the app and through a web link that you declare in the Data safety form. Google's account deletion requirements specify that the deletion must remove the account and associated data, with limited exceptions for legal retention.
Why indie apps fail: deletion exists only as "email us", or the web link in the form points to a generic help page.
Test: fresh install, create an account, find deletion without help, complete it, attempt to log in again. Separately, open the web link you declared in an incognito browser and confirm it leads to a page where a user can actually request deletion.
Permissions without a reason, or restricted permissions without approval
Android permissions fall into two groups for review purposes. Ordinary runtime permissions must be requested in context and used for a feature the user can see. Restricted permissions, such as SMS, call log, accessibility services, QUERY_ALL_PACKAGES and the all-files-access permission, require a declaration form and a use case that Google accepts. The Permissions policy lists them.
Since Android 13 and the Photo and Video Permissions policy, apps that only need occasional access to a user's photos should use the system photo picker rather than requesting broad media permissions.
Why indie apps fail: a library adds a permission to the merged manifest without anyone noticing, or the app asks for location at launch for a feature that is three screens deep.
Test: read the merged manifest of the release build, not your source manifest. Justify every permission in one sentence. Trigger each prompt and confirm it appears when the feature is used. Deny each and confirm the app does not crash or loop.
Target API level is too old
Google requires new apps and updates to target a recent Android API level, with the deadline moving each year. Builds that miss it cannot be published to the tracks, and existing apps that fall too far behind become unavailable to users on newer devices. The current requirements are in Play Console Help. Related: from late 2025, new apps and updates targeting Android 15 and later must support 16 KB memory page sizes, which affects any app shipping native code.
Why indie apps fail: the app was built a year ago, works fine, and nobody checked the deadline before the update.
Test: check targetSdkVersion in the release build and compare it with the current requirement. Then install on an emulator at that API level and run through the permission and background behavior changes that level introduced.
Digital purchases outside Play Billing
The Payments policy requires Google Play's billing system for in-app purchases of digital goods and services, with exceptions for physical goods, services consumed outside the app and some regional programs. Subscriptions also have disclosure requirements: price, billing period, and clear cancellation.
Why indie apps fail: a "Pro" upgrade link to a web checkout, or a subscription paywall that shows the trial but not the renewal price.
Test: walk every path that mentions money. Then test a license-tester purchase, a cancellation, and a restore after reinstall. Our payment flow testing guide covers the sandbox details.
Broken functionality and minimum functionality
The Minimum Functionality section of the Developer Program Policies rejects apps that crash, do not install, have no content, or are a web page in a wrapper with nothing added.
Why indie apps fail: a release build pointing at a staging server that is off, a WebView-only app, or a first run that fails on a device without Google Play services.
Test: install from the Play testing link on a low-end device and on an emulator at your minimum API level. Cold launch, complete the main flow, rotate, go offline, come back. Read Google's pre-launch report for the build, which runs on real devices in Google's lab and flags crashes, ANRs and accessibility problems.
Metadata, impersonation and misleading claims
The Metadata policy covers the listing: no misleading screenshots, no keyword stuffing, no claims the app cannot back up, no references to other brands that imply a relationship. The Impersonation policy is applied aggressively; using another company's name or logo in your icon or title because your app "works with" their product is a common trap for indie utilities.
Test: put each screenshot beside the live screen. Search the title, short description and full description for third-party brand names and for superlatives. Check the icon for anything that resembles another product's mark.
Deceptive behavior and undisclosed changes
The Deceptive Behavior policy covers apps that do something other than what they claim, change behavior after review, or hide functionality. A beta flag that enables a different app after a server-side switch is the classic violation, even if the intent was innocent.
Test: make sure the release build's behavior does not depend on a remote configuration that review will not see. If you use feature flags, document what review will experience.
Families and content ratings
If your target audience includes children, the Families policy applies and brings extra requirements for ads, data collection and content. Answering the target audience questionnaire casually is what pulls indie apps into this policy by accident.
Test: re-answer the target audience and content rating questionnaires honestly, then read what the resulting designation obligates you to do.
Developer account and verification problems
Not a policy violation but a frequent blocker: new personal accounts must complete identity verification and, as covered in our Android app beta testing guide, run a closed test with a minimum number of testers opted in for 14 days before production. Organization accounts need a D-U-N-S number. Start both early; neither can be rushed.
Related guides
Turning this into a pre-submission routine
Most of the items above have a test that can be run on every release candidate:
- Install the exact release bundle from the testing track on a low-end device and an emulator at the minimum API level.
- Complete the core flow, rotate, go offline, return.
- Trigger every permission, deny each, confirm recovery.
- Create an account, find and complete deletion, verify the declared web link.
- Walk every path that mentions money; purchase, cancel and restore as a license tester.
- Read the merged manifest and reconcile it with the Permissions and Data safety declarations.
- Compare the listing screenshots with the live screens.
- Read the pre-launch report.
Steps 1 through 5 and 7 are repeatable device work. betatest.ing runs them as part of a Store readiness test category on Android emulators and real devices: it installs your .aab or .apk, works through those flows, and files each problem with steps, severity, annotated screenshots and a recording, alongside a scored report you can export. Steps 6 and 8, and the judgment calls around Families and impersonation, stay with you. The beta testing checklist generator turns the list into something you can share with your team before each release.
Start for $1 and run a Store readiness pass on your next Play release before review does.
Related guides
Each ends with a test task you can send to your AI beta tester.
Keep reading
- The App Store rejection checklist: 12 things to test before you submit — Most first-submission rejections come from a short list of guidelines. Twelve checks, each with the guideline number, the test that proves you pass, and the mistake that usually fails it.
- AI mobile app testing: what an AI beta tester can and can't do on a phone — An AI beta tester on a phone sees the accessibility tree and the screen, taps, types, reads crash logs and records everything. It cannot be a real camera, notification or wallet. Here is the line.
- From beta to launch: how to decide your product is ready — "Ready" is a decision, not a feeling. Write exit criteria before the beta, measure against them at the end, and launch with a known-issues list instead of waiting for zero bugs.