Google Play Rejections and Policy Strikes: Causes and Fixes

Google Play rejections feel different from Apple's. Instead of a human reviewer's two sentences, you often get a policy name, a link to a long help page and an email that sounds alarming. And unlike Apple, Google keeps scanning apps after they're published, so a policy issue can surface on a version that was approved months ago.

The causes behind most Google Play rejections are predictable, though, and most are about declarations: telling Google accurately what your app collects, which permissions it needs and how reviewers can get in. Here are the common causes, how to fix each, and how React Native apps in particular pick up problems they didn't ask for.

Key takeaways

• Data safety mismatches are the most common problem: your form must match what your app and every SDK actually collect and share.
• Sensitive permissions need a reason and often a declaration: background location, photos and videos, SMS and call logs, all-files access and similar.
• Reviewers need a way in: give working credentials in the App access section if your app has a login.
• Account deletion is required for apps with account creation, in the app and through a web link.
• React Native apps often inherit permissions from libraries. Check the final merged manifest and remove what you don't use.

The most common causes, and the fix for each

1. Data safety form doesn't match the app

Google compares your Data safety declarations with what your app does, including what its SDKs collect. Analytics, crash reporting, ads, payments and authentication SDKs all collect something.

Fix: list every SDK in your app, check each vendor's data disclosure, and update the form. Declare data that's collected even if it's "anonymous", and say whether it's encrypted in transit and whether users can request deletion.

2. Sensitive permissions without justification

Some permissions are restricted to apps whose core functionality needs them, and require a declaration in Play Console:

Fix: remove permissions you don't need, use narrower alternatives (the photo picker, approximate location, foreground-only location), and complete the declaration honestly for those you keep.

3. Reviewers can't access the app

If your app needs a login, Google's reviewers need credentials. Without them they can't verify functionality, and the update is rejected.

Fix: provide a working test account in the App access section, with realistic data, and keep it active. If access depends on location, hardware or an invite, explain how to get in.

4. Account deletion missing

Apps that let users create accounts must let them request deletion of the account and associated data, both from inside the app and through a web link you add in Play Console. Simply deactivating the account doesn't count.

Fix: build an in-app deletion flow, publish a web page where users can request deletion without reinstalling the app, and describe any data you must retain and why.

5. Target API level too old

From 31 August 2026, new apps and app updates must target Android 16 (API level 36), with some exceptions for Wear OS, Android Automotive, TV and XR. Apps that fall behind can't ship updates, and older ones stop appearing to new users on recent Android versions.

Fix: upgrade your React Native or Expo version to one that targets the current API level, test behaviour changes (edge-to-edge display, permissions, background limits), and plan this upgrade every year.

6. Metadata and listing problems

Misleading descriptions, keyword stuffing, screenshots that don't match the app, or using other brands' names and logos without permission all break the metadata and impersonation policies.

Fix: describe what the app actually does, keep keywords natural, use current screenshots, and remove trademarks you don't have rights to.

7. Broken or minimal functionality

Apps that crash, don't load or are little more than a website inside a web view can be removed or rejected.

Fix: test the release build on real devices, and make sure the app offers real functionality beyond the website.

The React Native trap: permissions you didn't add

Every React Native library with native Android code can contribute permissions to your final AndroidManifest.xml. A location library might add background location. A media library might add broad storage access. Google judges the final manifest, not your intentions.

To find them, build the release bundle and inspect the merged manifest, or check the permissions shown in Play Console for the uploaded bundle. To remove one in an Expo app, list it in android.blockedPermissions:

{
  "expo": {
    "android": {
      "blockedPermissions": [
        "android.permission.ACCESS_BACKGROUND_LOCATION",
        "android.permission.READ_MEDIA_IMAGES"
      ]
    }
  }
}

In a bare project, use tools:node="remove" on the permission in your own manifest. Then test that the features you kept still work.

From the field: Google Play review, including handling rejections, is part of the release work I own, alongside App Store review, EAS builds and phased rollouts. The fixes are rarely hard; the work is in finding exactly which declaration or SDK triggered the problem.

Policy strikes and what they mean

Google's enforcement escalates:

Fix warnings before their deadlines. Suspensions are serious because strikes accumulate on the account, affecting every app in it.

How to respond to a Google Play rejection

1. Open Policy status in Play Console and read the exact policy and the evidence Google cites.
2. Fix the root cause, whether that's a declaration, a permission, the listing or the app itself.
3. Submit a new release or update the declaration, depending on the issue.
4. Appeal only if Google is wrong. Explain specifically why the app complies, with evidence such as a video of the feature.

FAQ

Why was my app rejected by Google Play?

The most common reasons are a Data safety form that doesn't match the app, sensitive permissions without justification or declaration, missing test credentials for reviewers, missing account deletion, an outdated target API level, and misleading listing details. Play Console's Policy status page names the exact policy involved.

How long does a Google Play review take?

It varies. Many updates are reviewed within a day or two, but new apps, new developer accounts and apps with sensitive permissions can take longer, sometimes several days. Plan launches with a buffer, and remember new personal accounts first need a 14-day closed test.

Can I appeal a Google Play rejection?

Yes. If you believe the decision is wrong, you can appeal from Play Console, explaining why your app complies. Appeals work best with specific evidence. If the issue is real, fixing it and resubmitting is faster.

How do I remove a permission my React Native app doesn't use?

Find which library adds it by checking the merged Android manifest. In Expo, add the permission to android.blockedPermissions in your app config. In a bare project, declare it with tools:node="remove" in your manifest. Rebuild and check Play Console's permission list.

Next steps

If Google Play has rejected your app or sent a policy warning, send me the message. I'll tell you what triggered it and how to fix it quickly. Get in touch, or see my services.

Sources

• Developer Program Policy, Google Play
• Provide information for Google Play's Data safety section, Google Play Console Help
• Understanding Google Play's account deletion requirements, Google Play Console Help
• Background location access policy, Google Play Console Help
• Target API level requirements for Google Play apps, Google
• App config: android.blockedPermissions, Expo