Google Play Data safety section rejection: how to audit, fix and resubmit

What the Data safety section requires

The Data safety section is the privacy label on your Play Store listing, filled in under Play Console → your app → App content → Data safety. Google's User Data policy says "all developers must complete a clear and accurate Data safety section for every app". That includes apps that collect nothing and apps on closed or open testing tracks. Only apps that are exclusively on the internal testing track are exempt.

For each data type, you declare whether it is collected and/or shared, for which purposes, and whether it is required or optional. You also answer security questions, such as whether data is encrypted in transit and whether users can request deletion. Two definitions decide most cases:

• Collected means transmitted off the device, by your code or by any third-party library or SDK in your app. Data from a WebView counts if your app controls the code or behavior delivered through it.
• Shared means transferred to a third party: server-to-server, directly to another app on the device (even if nothing leaves the device), or off the device through an SDK.

The exemptions are narrow. Data processed only locally on the device, data sent off the device but processed ephemerally (held only in memory, only as long as needed to serve the request) and end-to-end encrypted data that you can't read don't have to be declared as collected. Transfers to a service provider processing data on your behalf, transfers for legal purposes, transfers the user initiates or consents to after a prominent in-app disclosure, and fully anonymized data aren't "shared". You also need a privacy policy link in Play Console and inside the app. Google is explicit: "You alone are responsible for making complete and accurate declarations", and that includes what your SDKs do.

Common reasons for a Data safety rejection

1. Undisclosed data sent by an SDK

This is the classic "Invalid Data safety form" email. It names a version code, a data type (often Device or other IDs) and sometimes "Possible SDKs" such as play-services-measurement-impl (part of Google Analytics for Firebase). That library can arrive as a transitive dependency, so don't assume you are safe just because you never added Analytics yourself. Typical sources are ad SDKs sending the advertising ID or app set ID, Crashlytics sending crash logs and an installation UUID, and attribution SDKs. A frequent root cause is answering "No data collected" because your own code sends nothing, while the SDKs in the build do.

2. Permissions that contradict the form

Your bundle declares ACCESS_FINE_LOCATION, READ_CONTACTS or RECORD_AUDIO, but the form says no location, contacts or audio. These permissions are often merged in by a library or plugin you forgot about. If the data really stays on the device, that can be fine, as long as the form, privacy policy and code all say the same thing.

3. Missing or unreachable privacy policy

Google requires the policy to be on "an active, publicly accessible and non-geofenced URL (no PDFs)" and clearly labeled as a privacy policy. Causes developers report for "URL provided does not link to a valid privacy policy page" include:

• an expired or invalid SSL certificate
• a login or cookie wall
• a redirect to your homepage
• geoblocking
• no link inside the app

4. Privacy policy and form disagree

The form says you share device IDs with advertising partners, but your policy is a template that never mentions them. The policy should name the developer or company behind the app, give a privacy contact and cover what data you access, collect and share, who receives it, how you handle it securely, and your retention and deletion practices.

5. Wrong "optional", security or deletion answers

Data may be marked optional only if all users, regardless of device or region, can choose not to provide it or can opt out. Saying users can request deletion when no working process exists is just as inaccurate, and so is claiming all data is encrypted in transit while an SDK or endpoint still uses plain HTTP.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

How to fix a Data safety rejection step by step

1. Read the exact finding. Open Policy status and the rejection message. Note the version code, the data type and any "Possible SDKs". The version code may belong to a testing track rather than production.
2. Find the source. Map the data type to your code or to an SDK using the audit below. Don't just tick every box. Overdeclaring scares users and can still contradict your privacy policy.
3. Declare or remove. If you need the SDK, declare what it collects and shares. If you don't, remove it, or turn off the collection using the provider's documented settings. For example, if you don't use the advertising ID, remove the merged com.google.android.gms.permission.AD_ID permission and update the Advertising ID declaration under App content to match. If the provider or Play SDK Index flags your SDK version, upgrade to a policy-compliant one.
4. Update the form. Go to App content → Data safety. You can also use Export to CSV near the top right, edit the file and import it again (importing overwrites the answers already in the form). For each data type, set collected and/or shared, the purposes and required or optional, then recheck the security and deletion answers. Review the preview of your store listing section before you save.
5. Align the privacy policy with the data types, SDK partners, retention and deletion process you declared. The Play Console link and the in-app link should point to the same live HTTPS page.
6. Clean up the manifest by removing unused permissions, including merged ones. Rebuild with a higher versionCode.
7. Replace the flagged bundle everywhere. Google warns that if you don't deactivate non-compliant app bundles, your resubmission will fail and live versions may be removed. Create a new release with the fixed build on every track (production, open, closed and internal testing) that still serves the old version code.
8. Send everything for review. In Publishing overview, check that the Data safety changes and the new releases are all listed, then send them for review. If it was an update that got rejected, the version published before it stays available on Google Play in the meantime.

How to audit what your app and SDKs really collect

Audit the release configuration, because debug builds can include different dependencies and settings.

Inventory dependencies and permissions

• List the full tree, including transitive libraries: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath.
• Use the Merged Manifest tab of AndroidManifest.xml in Android Studio to see which library added which permission. For a built bundle, run bundletool dump manifest --bundle app-release.aab.
• Remove a permission a library merged in with <uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" /> (the manifest needs the tools namespace), then test the affected feature.

Read SDK disclosures and check Play SDK Index

Major SDKs publish Data safety guidance, for example Firebase and the Google Mobile Ads SDK. Google Play SDK Index links to this guidance where the provider has supplied it, shows the permissions an SDK requests, and lets Google warn you in Play Console and Android Studio about SDK versions that are outdated or may cause policy issues.

Inspect real network traffic

• Use View → Tool Windows → App Inspection → Network Inspector in Android Studio. It only shows HttpsURLConnection and OkHttp traffic (including Retrofit). For everything else, use an intercepting proxy such as mitmproxy or HTTP Toolkit.
• Apps targeting Android 7.0 (API 24) or higher don't trust user-installed CAs by default. Add the proxy CA under <debug-overrides> in your network security config. Those overrides only apply when the app is debuggable, so capture with a debuggable build type that otherwise mirrors release (for example a build type created with initWith(release) that sets debuggable to true).
• Start from a fresh install. Some SDKs send data on first launch, before your consent dialog appears, unless you delay their initialization.
• Register an AppOpsManager.OnOpNotedCallback (data access auditing, Android 11 and later). Its stack traces show whether your code or an SDK read the location, contacts or microphone.

Flutter, React Native, Unity and WebView apps

Cross-platform packages hide native SDKs, so audit the generated Android project.

• Flutter: firebase_analytics, google_mobile_ads or geolocator bring in native SDKs and permissions. Run flutter pub deps, then run the Gradle report inside android/.
• React Native and Expo: Autolinked modules and config plugins add permissions at build time. In Expo, you can remove unwanted ones with android.blockedPermissions.
• Unity: Every ad or mediation adapter has its own data practices and needs a matching declaration.
• WebView apps: If you control the web content, analytics tags or ad pixels in it count as collection by your app. See also our WebView policy guide.

Responding to Google: resubmit or appeal

In most Data safety cases, the right response is to fix and resubmit: a corrected form plus a new release. Google's help center says not to republish a rejected app until the violation is fixed.

Appeal only if you are sure the finding is wrong, for example because the flagged SDK isn't in that build. Use the instructions in the enforcement email or the Appeal option on the Policy status page.

• Put all your evidence into the first appeal instead of counting on a follow-up. A vague appeal mostly costs you time.
• Include evidence: the dependency report for the flagged version code, the merged manifest and a short summary of your network capture.
• Stay factual and short. Explain what you checked and what the build does, and don't argue about the policy itself.

If permissions such as location are part of the problem, see our guides on sensitive permissions and background location.

How account deletion ties into the Data safety form

The Data safety form includes data deletion questions. If users can create an account in your app, Google's account deletion requirements say you need an in-app path to delete the account and its data, plus a web link where users can request deletion without reinstalling the app. That web link is entered in the data deletion questions of the Data safety form, and the deletion answers show up on your store listing.

Reviewers can open that link. A broken URL, a page that only says "email us" with no clear steps, or a "users can request deletion" answer with no real process behind it makes your Data safety section inaccurate. If you keep some data after deletion (for example for fraud prevention or legal reasons), say so in the policy and on the deletion page. Build the in-app and web flows first, then answer the questions. Our Google Play account deletion guide covers the details.

Preventing the next Data safety rejection

Repeat rejections usually happen because the form was correct once and nobody updated it after an SDK upgrade. Treat the form like code:

• Keep a data map in the repo that lists each SDK, the data it sends and the matching answers. Commit the CSV export of the form next to it.
• Diff in CI. Store the release dependency report and the merged-manifest permission list as build artifacts. Require sign-off when either changes.
• Monitor the privacy policy URL so you know it returns HTTP 200 with a valid certificate.
• Run Play Policy Insights in a recent Android Studio version (Code → Inspect for Play Policy Insights), or in CI through the com.google.play.policy.insights:insights-lint lintChecks dependency. It flags potential policy issues around certain permissions and functionality, which catches many permission-related mismatches early. It does not fill in or validate the Data safety form for you.

AI-assisted checks are good at spotting contradictions between dependency lists, manifests and policy text. A human still has to decide what each SDK actually does with the data. At appsubmitter.io, we combine both in our CI/CD and submission work. You can walk through your case in a free consultation call before you resubmit.

Template: how to reply to the Google Play review team

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello Google Play Policy Team,

App: [App name] ([package name])
Rejected version code: [version code]
Issue: Invalid Data safety form – [data type, e.g. Device or other IDs]

We audited the data collected by our code and every third-party SDK in this build:

1. Source: [SDK name and version] transmits [data type] for [purpose].
2. Data safety form: On [date] we declared [data type] as [collected / shared] for [purposes], marked [required / optional].
3. App changes: Version code [new version code] [removes SDK X / upgrades SDK Y to version Z / removes the permission merged by library W]. It is rolled out to [tracks], and the non-compliant bundles have been replaced.
4. Privacy policy: [URL] now covers [data types, partners, retention, deletion]. It is publicly accessible and linked in the app under [screen].

[Only if you believe the finding is incorrect:] Version code [x] does not contain [SDK], and a network capture of a fresh install shows no transmission of [data type]. We can provide the dependency report and merged manifest. Could you please re-review the app or tell us where this data was detected?

Thank you,
[Your name], [developer account name], [contact email]

Checklist before you resubmit

• Every data type named in the rejection email is declared in the form, or the code or SDK that sends it is removed.
• Each SDK in the release dependency report is mapped to the data types on its official disclosure page.
• Every location, contacts, microphone, camera or phone permission in the merged manifest is either covered by the form or removed.
• A network capture of a fresh install, including first launch before consent, shows no undisclosed data.
• The AD_ID permission, the Advertising ID declaration and the Device or other IDs answer all match.
• The privacy policy loads over valid HTTPS without login, redirect, geoblock or PDF, and names the developer or company behind the app.
• The "encrypted in transit" answer is true for every endpoint your code and SDKs call, with no cleartext HTTP left.
• The privacy policy lists the same data types, partners, retention and deletion process as the form.
• The privacy policy is also linked inside the app.
• If users can create accounts, the delete-account link works and the deletion answers are accurate.
• The new release has a higher versionCode and has replaced the flagged bundle on every track.
• The form changes and the new release were sent for review together in Publishing overview.

Frequently asked questions

Official source: Play Console Help – Provide information for Google Play's Data safety section. Store policies change regularly – always check the current version. This guide is independent advice and not affiliated with Apple or Google.