Summary
Google rejected the app because the Data Safety section is incomplete, inaccurate, or no longer matches the release build.
Google Play App Review issue
Google Play Data Safety rejected
Google rejected the app because the Data Safety section is incomplete, inaccurate, or no longer matches the release build.
google play data safety rejecteddata safety rejected google playgoogle play rejection data safety
Fix Google Play review issues before the next submission
Use LogicSpring to run a free precheck, regenerate the right policy or disclosure pack, and shorten the loop from rejection notice to resubmission.
What this means
Data Safety is user-facing disclosure, so Google expects it to match the current build and current policy exactly.
This issue is common after adding or reconfiguring analytics, ads, crash reporting, sign-in, or payment SDKs.
A stale form can block even minor version updates.
Common causes
- The form says less data is collected or shared than the build or SDK inventory indicates.
- The team copied a previous release's Data Safety answers without re-auditing the current branch.
- The policy and Data Safety form describe different categories or different user controls.
What the rejection often looks like
- Google says the Data Safety section is incomplete, inaccurate, or not aligned with the current build.
- The review notice references undeclared collection, sharing, or data handling that is visible from the app or embedded SDKs.
- Play Console blocks the update because the Data Safety form no longer reflects the release currently under review.
Step-by-step fix
- Step 1
Build a current data inventory from the release candidate, not from memory or an older spreadsheet.
- Step 2
Update the Data Safety form from that inventory, then align the policy and in-app disclosures to the same decisions.
- Step 3
Document the rationale for each answer so the next release does not regress into another mismatch.
What to update
- Google Play Data Safety form
- SDK inventory and manifest permission review
- Privacy policy language for collected and shared data
- Internal release checklist for disclosure changes
How to avoid getting rejected again
- Regenerate Data Safety answers from the release candidate instead of copying the last approved submission.
- Track every SDK addition and removal in the same project record used for policy and export work.
- Make one person responsible for final Data Safety, policy, and permission consistency before every upload.
How LogicSpring helps
- LogicSpring keeps one project inventory for policies, disclosures, and review readiness work.
- Precheck flags likely Data Safety mismatches before you ship another update.
- You can export clearer data-use summaries instead of rebuilding them manually each release.
FAQ
What is the fastest way to fix a Google Play Data Safety rejection?
Start from the shipped build, not from old spreadsheets. Audit SDKs, permissions, and data flows from the release candidate, then update the Data Safety form, privacy policy, and disclosures from that same inventory.
Can a third-party SDK cause a Data Safety rejection even if the feature is not obvious in the UI?
Yes. Google can still expect disclosure for identifiers, diagnostics, app activity, or sharing triggered by embedded SDKs, even when the user-facing feature is subtle.
Should I resubmit immediately after changing only the Data Safety form?
Not unless you also checked the policy and app behavior. Resubmitting with only the form fixed often leads to the next rejection if the privacy policy or in-app disclosure still says something different.