Day15 › Guides

Google Play Data safety form rejected or flagged: how to fix it

Checked against Google’s Play Console Help on Oct 29, 2026 · By Anchor Point Apps

Data safety problems usually come down to a mismatch between what your app does and what the form says. This guide walks through finding the mismatch, using Google’s own definitions.

First, read the exact message

Open Play Console and look at the Policy status page and the Data safety item on App content. The notice tells you what Google found. Fix that rather than re-answering the whole form from scratch. Google’s article notes that policy enforcement is continuously improved, so an app approved earlier can be flagged later.

Who has to complete the form

• All developers with an app published on Google Play, “including apps on closed, open, or production testing tracks.” That includes your closed test for production access.
• Apps active only on the internal testing track are exempt.
• Even apps that collect nothing must complete the form and provide a privacy policy link.

Know Google’s definitions

• Collect means transmitting data from your app off a user’s device. That includes data sent by libraries and SDKs in your app, whether to your server or a third party’s.
• Not collection: data that is only processed on-device and never sent off it; and end-to-end encrypted data that nobody but sender and recipient can read.
• Ephemeral processing (kept only in memory, only as long as needed for the real-time request) still goes in your form response but isn’t shown publicly if it meets Google’s standard.
• Share means transferring collected data to a third party, with some exceptions (for example service providers acting on your behalf).

Audit in this order

1. Permissions. Google tells you to check your declared permissions and the APIs your app uses. Look at the merged manifest (your libraries add permissions too).
2. SDKs. Google says you must reflect collection and sharing by third-party code, and suggests reading your SDK providers’ published Data safety information. Analytics, crash reporting, ads, auth and push SDKs are the usual suspects.
3. Network calls. Anything you send off-device (user IDs, device IDs, diagnostics, content) counts. A permission alone doesn’t.
4. Privacy policy. It must match. See privacy policy requirements.

Permissions are a clue, not the answer

Google’s FAQ: “You do not need to declare collection or sharing unless data is actually collected and/or shared.” A permission that is declared but not used to collect data doesn’t need a declaration (though you still have to follow Google’s permissions policy). The reverse also matters: collection can happen with no special permission at all, for example an account email or an analytics ID.

Other rules that catch people

• There’s one global form per app. It describes the sum of collection across all versions currently distributed, anywhere. If any version collects it, declare it. If collection is required for any users, don’t mark it optional.
• You must say whether you offer a way to request data deletion. There’s no prescribed mechanism; Google gives in-app features, contact forms or a dedicated email alias as examples.
• Encryption in transit: follow industry standards (TLS/HTTPS are the common examples).
• Keep it current. Responses must remain accurate and complete; update when your data practices change.

Fix and resubmit

Edit the form, check the store listing preview Play Console shows before submitting, submit, and re-check the status. Google says that after a submission, review can take up to 7 days or longer in exceptional cases.

Responsibility. Google is explicit: “Only you possess all the information required to complete the Data safety form.” No tool, including ours, can certify your answers. Anything drafted from permissions is a starting point for you to verify.