7 Data Safety Mistakes That Get Apps Rejected
Nearly every Data Safety rejection is one of seven mismatches: undeclared location, missing advertising ID, denied analytics, forgotten auth data, ignored crash logs, a stale form, or a contradicting privacy policy. Each takes five minutes to check against your AAB.
The seven, with the check for each
Work through these against your own bundle in the AAB analyzer:
Location permissions, no location declared
ACCESS_FINE_LOCATION in the manifest with location unchecked is the single most common mismatch. Upload the AAB, list permissions, and answer location deliberately.
Ads SDK present, advertising ID missing
AdMob or any ads SDK means the advertising identifier is collected and usually shared for advertising. Declaring otherwise contradicts your own binary.
Analytics SDK, “not collected” checked
Firebase Analytics collects app interactions and device identifiers by default. If the SDK ships and runs, the collection happened — declare it.
Auth SDK, account data missing
Firebase Auth means email, name, and user IDs for account management. Auth apps that declare no personal info are waving a flag at reviewers.
Crashlytics ignored
Crash logs and diagnostics are collected data with a diagnostics purpose. “We only get crash reports” still counts as collection.
Stale form after an SDK was added
The form described version 12; the binary is version 15 with two new SDKs. Regenerate the profile per version so every export is auditable.
Policy contradicts the form
The policy mentions analytics, personalization, or sharing that the form denies. Generate both documents from one reviewed profile.
Fix them at the source
Each mistake above maps to a permission or SDK signal the Data Safety generator flags for review automatically. The answering method — and why each mistake reads as deception to a reviewer — is covered in depth in the Data Safety section guide.
Keep going
Check your app against all seven
Upload the AAB, review the flags.