Skip to content
data-safety-from-codeData safety from code

Data Safety Form Rejected? How to Fix an Inaccurate Form

Short answer: a flagged or rejected Data safety form usually means Google saw the app do something the form doesn’t declare. The usual source is an SDK: an ads, analytics or crash library sending data you didn’t list. Read the exact issue in Play Console, find the code or SDK behind it, then either declare the data or remove what sends it, and submit again.

What Google says

Section titled “What Google says”

From Google’s Data safety help page:

  • You alone are responsible for complete and accurate declarations.
  • If Google finds a discrepancy between the app’s behavior and the form, it may take enforcement action.
  • Apps that don’t become compliant can have updates blocked or be removed from Google Play.
  • Google tells you about issues by email to the account owner, a Play Console notification, and the Policy status page (Policy, then Policy status).
  • Google’s review of the form is not designed to verify that every answer is accurate. A form that passes review can still be wrong.

Steps to fix it

Section titled “Steps to fix it”
  1. Read the issue. Open Policy → Policy status and note exactly what it names: a data type, an SDK, a permission or a version code.
  2. List every SDK in the release build, including ones pulled in by other libraries. Running ./gradlew :app:dependencies --configuration releaseRuntimeClasspath shows the full tree.
  3. Check each SDK’s disclosure. Google points developers to their SDK providers’ guidance and to the Google Play SDK Index. The SDK pages here link the vendor pages for common SDKs.
  4. Check your own code for anything that sends data off the device: HTTP calls, uploads, database writes, analytics events, sign-in, AI requests.
  5. Check the merged manifest for permissions libraries add. An unused sensitive permission is better removed than declared.
  6. Decide for each finding: declare it, or remove the code or SDK that sends it. If you remove code, ship a new build. Older versions still distributed on Google Play count toward the form.
  7. Export a backup, update the form, check the preview, and submit.

Common causes

Section titled “Common causes”

These follow from Google’s rules. Each one is a gap between what the app does and what the form says.

  • SDK data left out. For example, AdMob’s disclosure lists device or other IDs, app interactions, diagnostics and approximate location. Google’s page says an Android Advertising ID is declared as device or other IDs.
  • Location derived from an IP address but no location declared. See IP address and location.
  • “No data collected” while the app includes an analytics, crash or ads SDK. See apps that collect no data.
  • Crash logs and diagnostics from a crash reporter left out. Google’s page notes that diagnostics collected together with a device ID still need “Diagnostics” declared.
  • Encrypted in transit: yes, with a plain http:// endpoint receiving user data.
  • Purchase history missing when your app or backend stores or verifies purchases.
  • An older version still on Google Play that collects something the latest one doesn’t.

CSV IDs that often need adding

Section titled “CSV IDs that often need adding”
  • PSL_DEVICE_ID (Device or other IDs)
  • PSL_APPROX_LOCATION (Approximate location)
  • PSL_USER_INTERACTION (App interactions)
  • PSL_CRASH_LOGS and PSL_PERFORMANCE_DIAGNOSTICS (Crash logs, Diagnostics)
  • PSL_PURCHASE_HISTORY (Purchase history)
  • PSL_DATA_COLLECTION_ENCRYPTED_IN_TRANSIT (the encryption question)

Each added type also needs its usage rows: collected or shared, ephemeral, required or optional, and purposes. See the CSV format reference.

Common mistakes when fixing

Section titled “Common mistakes when fixing”
  • Fixing only the item named in the notice. If one SDK was missed, others may be too. Do the full inventory.
  • Resubmitting without changes, hoping for a different reviewer.
  • Declaring everything “just in case”. Over-declaring makes the listing inaccurate in the other direction. Declare what the app and its SDKs actually do.
  • Importing a CSV without a backup. Import replaces the whole form.

With data-safety-from-code

Section titled “With data-safety-from-code”

The skill runs the inventory steps above: it matches dependencies, including transitive ones when you give it the Gradle dependency tree, flags code that sends data, and lists unused sensitive permissions. Its report shows what changed against your current form, and calls out added types, because under-declaring is the usual problem. It drafts the fix; you review it and submit. Get started.

Section titled “Related”

Want the form filled from your own code, with evidence? Install the skill. If this page helped,star the repo on GitHub.

Built by Sanikant. Set in Google Sans Flex (SIL Open Font License), icons from Material Symbols (Apache 2.0). Google Play is a trademark of Google LLC; this project is not affiliated with Google. Output is a draft for review: you are responsible for your Data safety declaration.