Ways to Fill the Data Safety Form Compared

There are four common ways to get Google Play’s Data safety form done. They answer different parts of the problem, and several work well together. None of them makes you less responsible for what you declare.

At a glance

	By hand in Play Console	fastlane google_data_safety plugin	SDK vendor guidance	data-safety-from-code
What it is	Play Console’s own form	A community fastlane plugin	Pages each SDK vendor publishes	An open-source agent skill
How answers are decided	You answer each question	You answer interactive prompts	The vendor describes its own SDK	Your code and SDK disclosures, plus questions code can’t answer
Reads your code	No	Its README describes prompts, not code scanning	No	Yes: manifest, Gradle files, Kotlin and Java source
Covers your own code and backend	If you remember	If you remember	No	Own code yes; backend only through your answers
Evidence for each answer	None recorded	None recorded	The vendor page, per SDK	file:line or a vendor link, in a report
Output	The live form	A CSV, and an upload action	Text to read	A CSV and a Markdown report
Upload	You submit in Play Console	upload_google_data_safety with a service account	n/a	You import the CSV; API upload only if you ask
Works unattended in CI	No	Upload yes; the prompt action is interactive only	n/a	No, it is a review step

By hand in Play Console

You open App content → Data safety, read each question, and answer it.

Better at: nothing to install, and you see every question in Google’s own words with Google’s help text beside it. For a small app with one or two well-documented SDKs, this is often the quickest route.

Weaker at: it relies on you knowing what every SDK and code path sends. Nothing records why you answered the way you did, so the next update starts from memory.

fastlane google_data_safety plugin

fastlane-plugin-google_data_safety by Owen Bean, MIT licensed. Its README describes two actions:

• prompt_create_data_safety_csv walks you through questions about how your app uses data and saves the answers as a CSV. It is interactive and has no non-interactive mode.
• upload_google_data_safety uploads a CSV to Play Console using a service account JSON key, from a file or raw content.

Better at: fitting into an existing fastlane release lane, and uploading a reviewed CSV without opening Play Console. The upload action works with any valid Data safety CSV, including one made by hand or by another tool.

Weaker at: the prompts still depend on you knowing the answers. The README doesn’t describe reading your project or SDK disclosures.

SDK vendor guidance

Many SDK vendors publish a page saying what their SDK collects for Play’s Data safety form, for example Firebase, AdMob, RevenueCat and OneSignal. Google’s help page tells developers to check this guidance, and the Google Play SDK Index links to it where the vendor has provided it.

Better at: it is the most authoritative source for what a given SDK does, written by the people who build it. Any other approach, including this skill, depends on it.

Weaker at: it is one page per SDK, each in its own format. It can’t know which SDKs your app includes, which optional features you turned on, or what your own code sends. Some vendors don’t publish a Play-specific page at all.

data-safety-from-code

This project. An agent skill that scans an Android codebase and writes the Data safety form as a CSV for Play Console import, plus a report with evidence for every answer.

Better at: the inventory. It finds SDKs in Gradle files and version catalogs, and transitive ones when you give it the dependency tree. It matches them against a knowledge base built from vendor pages, flags code that sends data off the device, lists unused sensitive permissions, and asks you only what code can’t show. Every answer in the report links to a file:line or a vendor page, and the report shows what changed from your current form.

Weaker at: it can’t see your backend, SDK console settings, WebView content or older app versions; it asks you or lists them for review. Its knowledge base covers a fixed set of SDKs, and some entries are marked inferred where the vendor has no Play-specific page. It needs an AI coding agent that can run skills, and Python 3.9 or later. The output is a draft you review, not a finished declaration.

Using them together

These aren’t exclusive. A reasonable flow:

1. Run data-safety-from-code to get a draft CSV and an evidence report.
2. Check the SDK entries in the report against each vendor’s own page.
3. Review the CSV in Play Console’s import preview, or upload it from CI with fastlane’s upload_google_data_safety once you trust your process.

See how the skill works or get started. Common questions are in the FAQ.