Why Was My App Rejected by Google Play? 10 Common Reasons & Fixes (2026)

You spent weeks building it. You tested it, polished the screenshots, wrote the description, and hit Submit. Then the email arrived: Your app has been rejected.

That moment is brutal — especially when you don't know why, or you fixed the obvious thing and got rejected again. Every day in review is a day without revenue and a launch date slipping sideways.

The good news: Google Play rejections are almost always fixable. The bad news: the two biggest culprits right now — an incomplete Data Safety form and **AI-content policy violations** — are easy to miss if you don't know where to look. This post covers all 10 common rejection reasons, the exact fixes for each, and a step-by-step walkthrough of the Data Safety form (the single most-flagged item in 2025–2026). By the end, you'll know exactly what to fix and how.

Building for iOS too? Don't miss our companion guide: Why Was My App Rejected by Apple? 10 Most Common Reasons (2026).

How Google Play's App Review Process Works (And Why Rejections Happen)

Google Play uses a mix of automated policy scanners and human reviewers — and most rejections are triggered before a human ever sees your app. The scanner checks your store listing, APK/AAB metadata, and Data Safety form for policy flags. If any trip, the app stops there.

Understanding this matters because it changes your debugging approach. You're not trying to convince a person; you're trying to satisfy a checklist that a machine cross-references against your submission.

The Two Types of Rejections You Need to Know

• Publishing rejection — your new app or update is blocked before going live. Your existing live apps are unaffected. Fix the issue and resubmit.
• Policy violation (removal) — a live app is taken down and a strike is issued against your developer account. This is more serious. One warning, two strikes means app removal, three strikes within 12 months means account termination.

Warnings don't affect your account standing. Strikes do. Termination is appealable, but rarely reversed without a demonstrably different compliance posture — and creating a new account after termination is itself a policy violation that leads to a permanent ban.

How Long Does Google Play Review Take in 2026?

Standard review takes 1–3 days; sensitive categories (health, finance, VPN, children's apps) can take up to 7 days. There's no expedited option — that's a myth.

The part that stings: every resubmission resets the clock. If you fix one thing, resubmit, and get rejected again for something else, you've just lost another week. Fix everything in one pass.

What Changed in Google Play's Policies in 2025–2026?

The biggest policy shifts target AI-generated content disclosure, expanded Data Safety requirements, stricter health and finance app rules, and new SDK transparency mandates. Apps built before 2024 may now be out of compliance without a single line of code changing.

If you're a returning developer who hasn't touched a live app in a while, read this section carefully — your app might be sitting on a ticking violation.

AI-Generated Content & Synthetic Media Policy (New in 2025)

Apps must now disclose use of AI-generated images, audio, or video — in the store listing and within the app itself. Synthetic media of real people requires explicit labeling.

The fix is simple: add a disclosure in your app description (e.g., "This app uses AI-generated images") and surface the same disclosure in-app wherever synthetic media appears.

Expanded Data Safety Form Requirements

Google now requires you to declare all third-party SDKs that collect data — not just your own first-party collection. There's also a new required field: you must provide a data deletion request workflow accessible to users.

Mismatches between your form answers and your app's actual behavior are flagged automatically by Google's scanner. This is the single most common rejection trigger in 2025–2026. The full walkthrough is in the Data Safety Form section below — don't skip it.

Health, Finance, and VPN App Requirements

• VPN apps must complete a new independent security audit declaration.
• Finance apps have additional KYC/AML disclosure fields.
• Health apps face new data minimization requirements for any app accessing sensor or biometric data.

If your app falls into any of these categories, check the Google Play Developer Policy Center for the current specifics — these fields change more frequently than other policy areas.

Target API Level Policy Updates

Apps targeting API level below 34 are rejected as of late 2025. New apps must target API 35 or higher (check the current Google deadline — the outline notes the exact figure should be verified against current documentation).

The fix is a one-liner: update targetSdkVersion in your build.gradle or build.gradle.kts file.

SDK Transparency and Third-Party Library Rules

SDKs you use must appear in Google Play's SDK Index or be declared manually. Ad SDKs must comply with the updated Families Policy if your app targets children. This isn't optional fine print — it's an automated rejection trigger.

10 Common Reasons Google Play Rejected Your App (And How to Fix Each One)

The 10 most common Google Play rejection reasons in 2026 are: incomplete Data Safety form, missing or mismatched privacy policy, misleading metadata, restricted content without declaration, app crashes or broken functionality, permission overreach, IP/trademark violations, billing policy violations, impersonation or deceptive behavior, and non-compliant third-party SDKs.

Here's the breakdown for each.

Reason 1 — Incomplete or Incorrect Google Play Data Safety Form

📋 The #1 cause of first-time rejections in 2025–2026. Read the full walkthrough in the Data Safety section below.

This one bites developers because the form looks simple until you realise the automated scanner cross-references your answers against your actual APK. The three most common failure modes:

• Mismatch between declared data practices and actual app behavior.
• Skipping required fields, especially "data deletion" and "third-party sharing" disclosures.
• Selecting "No data collected" when your app bundles an ad SDK that collects device identifiers.

The fix:

• Audit every SDK you ship against its declared practices in Google's SDK Index.
• Cross-reference your Privacy Policy with every answer on the form.
• Use Google's Data Safety Help Center checklist as a pre-submit QA step.

Reason 2 — Missing, Inaccessible, or Mismatched Privacy Policy

A bad privacy policy URL is an instant rejection. Four failure modes cover most cases:

• No URL at all in the store listing.
• URL returns a 404 or redirects to a login wall.
• Policy doesn't cover all data types the app actually collects.
• Generic template text that doesn't mention your app by name.

The fix:

• Host your policy at a publicly accessible, mobile-friendly URL — check it works from a phone in incognito mode.
• The policy must cover: data collected, purpose, third parties, retention period, and user rights.
• Keep it in sync with your Data Safety form. Google cross-checks them. If one says you collect location data and the other doesn't mention it, you have a problem.

A dedicated Privacy Policy generator calibrated for Google Play compliance saves a lot of back-and-forth here.

Reason 3 — Misleading or Non-Compliant App Metadata

Metadata rejection means something in your title, description, screenshots, or graphics doesn't match your app. Common triggers:

• Title or description promises features the app doesn't have.
• Screenshots show UI from an older build.
• Short description contains keyword stuffing.
• Icon or feature graphic mimics another app or brand.

The fix:

• Audit all metadata against the live APK before submission.
• Remove superlatives ("Best," "#1," "Most Downloaded") unless verified by Google-approved sources.
• Screenshots must come from the current build. Device frames should come only from Google's approved set.

Reason 4 — Restricted Content Without Required Declaration

Gambling, alcohol, firearms, and adult content all require content declarations — submitting without them triggers rejection. The most common trap: an app claims to be "for 18+" in the description but is submitted with an "Everyone" content rating.

The fix:

• Complete the IARC content rating questionnaire in Play Console.
• Set content rating, content declaration, and target audience consistently — all three must align.
• For real-money gambling apps: complete the required government-issued license declaration.

Reason 5 — App Crashes, Fails to Load, or Has Broken Core Functionality

Google's reviewers test your app, and if it crashes or fails to load on their test devices, it's rejected. Three common causes:

• App crashes on launch on Google's review devices.
• Login flow is broken or requires credentials Google doesn't have.
• Core features depend on hardware (GPS, camera) unavailable on test devices, with no graceful fallback.

The fix:

• For apps behind a login wall: provide demo/test account credentials in the App Access section of Play Console (Policy → App Content → App Access). This is mandatory.
• Test on Android emulators across API levels 34 and 35 before submitting.
• Add graceful degradation for any feature that depends on hardware.

Reason 6 — Overly Broad or Unjustified Permission Requests

Requesting permissions you don't need — or can't justify — is a rejection. Three common patterns:

• Requesting SMS, Call Log, or Contacts without a core-use-case justification.
• Requesting background location when foreground location is all you need.
• Declaring permissions in the manifest that the app never uses.

The fix:

• Remove every permission not directly tied to a user-facing feature.
• For sensitive permissions (SMS, Call Log, Contacts, Background Location): submit a Permissions Declaration Form in Play Console.
• Replace broad permissions with scoped alternatives where available — for example, QUERY_ALL_PACKAGES can usually be replaced with specific intent queries.

Reason 7 — Intellectual Property or Trademark Violations

Using trademarked terms in your app name, icon, or description — without authorization — is an automatic rejection. Examples from the outline include app names like "for WhatsApp" or "Spotify Downloader," and screenshots that include copyrighted UI from another app.

The fix:

• Remove all unauthorized brand references from metadata and in-app UI.
• If your app legitimately integrates with another service, use generic descriptions: "music streaming integration" rather than naming the specific brand.
• Google has a formal trademark complaint process; if you've been incorrectly flagged, that's the route to contest it.

Reason 8 — Billing and In-App Purchase Policy Violations

Digital goods sold inside your app must use Google Play Billing. No exceptions for digital content. The common violations:

• Selling digital goods without Google Play Billing.
• Including a link or prompt directing users to pay outside the Play Store.
• Subscription terms not disclosed upfront in the paywall UI.
• Free trial terms not clearly labeled before purchase.

The fix:

• Physical goods and real-world services (ride-sharing, food delivery) may use external payment. Everything digital must go through Google Play Billing.
• Your subscription paywall UI must display: price, trial duration, renewal terms, and cancellation instructions — before the user taps to subscribe.

Reason 9 — Impersonation or Deceptive Behavior

Deceptive behavior covers anything where your app misrepresents itself — to Google or to users. Common triggers:

• App pretends to be a system utility, antivirus, or device optimizer without genuine functionality.
• App's behavior changes significantly after install (hidden functionality).
• App requests device admin privileges without clear justification.

The fix:

• Your store listing must represent 100% of what your app does — including anything it does in the background.
• Device admin, accessibility service, and notification listener APIs require a policy declaration and a clear in-app explanation shown to users before they grant access.
• Functionality added via OTA (over-the-air) update must not violate the policies your app was reviewed under.

Reason 10 — Non-Compliant Third-Party SDKs or Libraries

Third-party SDKs are the sneakiest rejection trigger because the violation isn't in code you wrote. Three patterns to watch:

• A bundled ad SDK collects data not declared in your Data Safety form.
• An analytics library accesses identifiers prohibited for your app's audience — for example, Advertising ID in a children's app.
• An outdated SDK has known security vulnerabilities flagged by Google's automated scanner.

The fix:

• Audit every SDK version using Google Play's SDK Index.
• Update ad SDKs to the latest versions — especially for Families Policy compliance.
• For children's apps: use only Families Policy-approved SDKs. For AdMob, make sure the COPPA flag is set correctly.

Step-by-Step: How to Complete the Google Play Data Safety Form Correctly

To complete the Data Safety form: open Play Console → select your app → go to Policy → App Content → Data Safety. You'll declare what data your app collects, why it's collected, how it's shared, and what security practices protect it.

Before you start, open three things in separate tabs: your privacy policy, your full SDK list, and a network traffic audit of your app (more on that below). You'll need all three.

Step 1 — Access the Data Safety Section

Navigate to: Play Console → [Your App] → Policy → App Content → Data Safety.

Click Start for a new app, or Edit for an existing one.

Step 2 — Answer the Collection & Sharing Overview Questions

Three questions define the shape of your form:

1. "Does your app collect or share any of the required user data types?" — Answer carefully. "No" triggers a simplified form, but if your APK says otherwise, you'll be flagged automatically.
2. "Is all of the user data collected by your app encrypted in transit?" — This must be true. All network calls should use HTTPS/TLS 1.2 or higher.
3. "Do you provide a way for users to request their data be deleted?" — Required as of 2025. You must link to an in-app or web-based deletion flow.

⚠️ Warning: Selecting "No data collected" when your app includes Google Analytics, Firebase, AdMob, or Meta Audience Network will cause an automatic rejection.

Step 3 — Declare All Data Types Collected

Walk through each category and check what applies — including data collected by third-party SDKs, not just your own code:

Step 4 — Specify Data Usage Purposes

For each declared data type, select all applicable purposes from the list: App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention & security, Personalization, Account management.

Common mistake: selecting only "App functionality" for data that's actually used for "Analytics." Google's automated review can detect the inconsistency between your declared purpose and the SDK's known behavior.

Step 5 — Declare Third-Party Sharing Practices

If any declared data goes to ad networks, analytics providers, or crash reporting tools, answer "yes" to sharing. You declare categories of recipients — you don't need to name specific companies.

One thing developers frequently miss: sharing data with a parent company or subsidiary still counts as "sharing with third parties" for this form.

Step 6 — Confirm Security Practices and Submit

• Check "Data is encrypted in transit" — only if all data transfers use TLS/HTTPS.
• Check "You can request data deletion" — only if a working deletion request mechanism exists.
• Click Save → Submit.

The form submission doesn't push your app live — it goes live only when the associated app version is published.

Pro tip: Re-submit the Data Safety form every time you add a new SDK or change data collection behavior, even if the APK version number stays the same.

7 Mistakes That Get Developers Rejected Again (After They Thought They Fixed It)

The most common reason for a second rejection is fixing the violation without fixing the root cause — especially with the Data Safety form, where surface-level edits don't catch what an SDK is doing at runtime.

1. Fixing the form, not the SDK. Editing your Data Safety answers without updating or removing the non-compliant SDK. Use a proxy tool like Charles Proxy or mitmproxy to verify what data actually leaves your app at runtime — not just what your code says.
2. Ignoring the App Access section. Submitting a login-required app without demo credentials. Fix: Policy → App Content → App Access. Complete this before every submission that requires authentication.
3. Using one privacy policy across multiple apps. Google checks that policies are app-specific. A generic company policy that doesn't mention your app by name raises flags. Create per-app policy pages, or use URL parameters to serve app-specific content dynamically.
4. Resubmitting before reading the full rejection email. The email contains a specific policy section number — and often a secondary violation listed below the obvious one. Fix all flagged items in a single resubmission.
5. Not updating the Data Safety form after adding a new SDK. Adding an analytics or monetization SDK without revisiting the Data Safety section is one of the most common repeat-rejection causes. Treat "add SDK" and "update Data Safety form" as a single atomic task.
6. Submitting screenshots from an older build. Screenshots showing UI that no longer matches the current APK — reviewers notice this. Re-export screenshots from the exact build you're submitting.
7. Overlooking the Families Policy for broad-audience apps. Apps rated "Everyone" or "Everyone 10+" that include third-party ad SDKs not cleared under the Families Policy. If your audience could include children under 13 — even partially — switch to Families Policy-approved ad SDKs or disable ads for that segment.

How to Appeal a Google Play Rejection (And When It Actually Works)

To appeal: go to Play Console → Support → contact Google Play developer support and select "Appeal a policy decision." Appeals work best when the rejection was a false positive. They rarely succeed if the underlying violation wasn't fixed.

Appeal vs. Resubmit: When to Do Which

• Appeal when you believe the rejection was a policy misapplication — for example, being flagged for a permission your app doesn't request.
• Resubmit when you know what's wrong and you've fixed it. Don't waste days waiting on an appeal when you can fix and resubmit faster.

How to Write an Effective Appeal

• Reference the exact policy section Google cited in the rejection email.
• Explain in 1–2 paragraphs why your app is compliant with that specific section.
• Attach evidence: screenshots, code snippets, or a short video walkthrough showing the feature in question.
• Be factual. Emotional language doesn't help and can hurt.

Sample structure: "Our app was rejected citing [Policy Section X]. We believe this is a false positive because [specific reason]. Attached are [screenshots/video] demonstrating [specific behavior]. We have not modified [feature] and our implementation follows [specific guideline]."

What Happens If Your Developer Account Gets Suspended?

• One strike: warning.
• Two strikes: app removal.
• Three strikes within 12 months: account termination.

Termination is appealable but rarely reversed without a demonstrably new compliance posture. Creating a new account after termination violates Google's terms and results in a permanent ban.

Pre-Submission Checklist: 15 Things to Verify Before You Hit "Submit"

Copy this and run through it before every release — not just first submissions.

PRE-SUBMISSION CHECKLIST — Google Play 2026

STORE LISTING
[ ] Title: no trademarked terms, no keyword stuffing, ≤30 characters
[ ] Short description: <80 characters, no superlatives, no symbols
[ ] Long description: accurate, no deceptive claims
[ ] Screenshots: match current APK build, correct dimensions
[ ] Feature graphic: no misleading imagery

DATA SAFETY & PRIVACY
[ ] Data Safety form completed and saved
[ ] All SDKs audited against Data Safety declarations
[ ] Privacy policy URL live, accessible, app-specific
[ ] Data deletion request mechanism available to users
[ ] Data Safety form matches privacy policy

APP FUNCTIONALITY
[ ] App launches without crash on API 34 and API 35
[ ] Demo/test account credentials added (if login required)
[ ] All core features functional on emulator
[ ] No network calls fail silently

PERMISSIONS & COMPLIANCE
[ ] No unused permissions in manifest
[ ] Sensitive permissions (SMS, Call Log, BG Location) have Declaration Form submitted
[ ] Content rating (IARC) complete and accurate
[ ] Target audience and content declaration consistent
[ ] targetSdkVersion = 35 (or current Google minimum)

BILLING (IF APPLICABLE)
[ ] All digital goods use Google Play Billing
[ ] Subscription terms visible before purchase
[ ] No external payment prompts for digital content

Frequently Asked Questions About Google Play Rejections

Key Takeaways and Next Steps

Getting rejected by Google Play is frustrating — but it's almost always fixable. The developers who resubmit fastest treat the rejection email as a spec, not a setback.

Six things to take away from this:

1. The Data Safety form is the #1 rejection trigger in 2025–2026. Treat it with the same care as your codebase.
2. Third-party SDKs are invisible landmines. Audit every library's data practices before you submit.
3. Fix the root cause, not the symptom. Editing your Data Safety form without fixing the underlying SDK behavior will get you rejected again.
4. Use the pre-submission checklist before every release — not just the first one.
5. Google's policies evolve continuously. Subscribe to the Google Play Policy Update Center and review your compliance posture quarterly, even for live apps.
6. Appeals are a last resort. Fixing and resubmitting is almost always faster.

For your next step, check out our Google Play Console guide for a full walkthrough of the console, our ASO checklist for 2026 to maximize visibility after your app goes live, or use our Privacy Policy generator to produce an app-specific, Google Play-compliant policy in minutes.

Quick Reference Links