Google Play enforces Data Safety form accuracy through ongoing policy reviews and user reports, not just initial submission. A mismatch between what your code collects and what the form declares is grounds for a policy strike and app removal under GDPR Art.13 and CCPA §1798.100 disclosure obligations. Common misses: apps that initialise AdMob or react-native-firebase without declaring device ID sharing with Google, or crash reporters left undeclared because they feel like infrastructure rather than data collection. Google distinguishes between data you collect and data third-party SDKs collect on your behalf — both must be declared.
High because an inaccurate Data Safety form results in policy strikes that escalate to app removal and can trigger regulatory scrutiny under GDPR and CCPA.
Walk through Play Console → App content → Data safety and map every SDK initialisation in your code to its declared data types. For Google's own SDKs, use Google's published Data Safety disclosures. For third-party SDKs, check their documentation.
When in doubt about whether an SDK shares data, mark it as shared — false negatives carry greater risk than over-disclosure. After updating, use the Play Console Preview to confirm declarations look correct before publishing. If you use fastlane, store declarations under fastlane/metadata/android/ and review them before every release.
ID: app-store-privacy-data.privacy-declarations.data-safety-form-accuracy
Severity: high
What to look for: Count all relevant instances and enumerate each. Before evaluating, extract and quote any relevant configuration or UI text found. Examine what data the app actually collects by reading the codebase, then compare to any store metadata declarations. Look for: (a) fastlane/metadata/android/ or store-listing/ directories containing Data Safety declaration files; (b) a PRIVACY.md, privacy-policy.md, or docs/legal/privacy.md file that lists collected data types. Then audit what is actually collected: auth flows collecting name/email → "Personal info > Name" and "Personal info > Email address" must be declared; react-native-firebase analytics → "App activity > App interactions" and "App info and performance > Crash logs" must be declared; ad SDKs → "Device or other IDs > Device or other IDs" must be declared and whether it's shared with third parties must be marked; location APIs → "Location > Approximate location" or "Precise location" must be declared with whether it's collected in the background. Cross-reference: is data declared as "not collected" but code clearly collects it? Is data declared as "not shared" but an ad SDK is initialized that shares device IDs? Flag specific mismatches.
Pass criteria: The declared data types in store metadata or privacy policy are consistent with what the code actually collects and shares. At least 1 implementation must be verified. No type is declared as "not collected" when code clearly collects it. A partial or placeholder implementation does not count as pass. Report the count even on pass.
Fail criteria: A mismatch exists: code collects or shares a data type not declared in the Data Safety form; or a declaration claims data is not shared when an ad or analytics SDK clearly shares it with a third party.
Skip (N/A) when: App targets iOS only (no Android build configuration) and no Android metadata files are present.
Detail on fail: "App initializes AdMob (collects device advertising ID and shares with Google) but no Data Safety declaration file found — form likely incomplete" or "Crash reporting via react-native-firebase is active but 'App info and performance > Crash logs' is not declared in fastlane/metadata/android/"
Remediation: Google Play now enforces Data Safety form accuracy — mismatches result in policy strikes and app removal, not just rejection.
Review the configuration in src/ or app/ directory for implementation patterns.