If you have an Android app ready to publish, the Data Safety form is the part of Google Play submission most likely to bounce you back. It isn't code, it isn't design, and it isn't something your IDE checks for you — it's a self-declaration about what your app does with user data, and Google cross-references your answers against your app's actual behavior. Get it wrong and your release sits in limbo, or worse, an update to a live app gets blocked until you fix it.
This guide walks through what the Data Safety form actually is, the specific declarations that cause most rejections in 2026, how to fill out each section accurately, and the SDK and Android 17 wrinkles that catch even experienced developers. It assumes you've shipped an app — or you're about to, possibly one you just ported into Kotlin with Android Studio's new Migration Assistant — and you want to clear this form once instead of three times.
What the Data Safety form actually is#
Every app on Google Play has a "Data safety" section on its store listing — the table users see that says what data the app collects, what it shares, and whether it's encrypted. You populate that table by completing a form in Play Console. It's mandatory. Apps without an approved Data Safety section don't get published, and you can't push updates to an existing app while the form is incomplete or flagged.
The form is built around a handful of core questions, and everything else hangs off them:
- Does your app collect or share any of the required user data types?
- Is all of the user data collected by your app encrypted in transit?
- Do you provide a way for users to request that their data is deleted?
"Collect" has a specific meaning here: data is collected if it leaves the device — transmitted off the user's phone to your servers or anyone else's. "Share" means that data is then transferred to a third party. These two words do a lot of work, and misreading them is the single most common reason a form is wrong.
The data types you have to account for#
The form asks, for each category, whether you collect it, whether you share it, why, and whether it's required or optional. The categories in 2026 are broad, and "we don't really use that" is not the same as "we don't touch it." The categories include:
- Location — approximate and precise are declared separately
- Personal info — name, email address, user IDs, address, phone number
- Financial info — purchase history, payment info, credit score
- Health and fitness — health data, fitness data
- Messages — emails, SMS, in-app messages
- Photos and videos
- Audio — voice recordings, music files, sound files
- Files and docs
- Calendar and Contacts
- App activity — interactions, in-app search history, installed apps, other user-generated content
- Web browsing history
- App info and performance — crash logs, diagnostics, performance data
- Device or other IDs
For each type you collect or share, you also pick a purpose: app functionality, analytics, developer communications, advertising or marketing, fraud prevention and security, personalization, or account management. Be honest and be specific — declaring "advertising" when you mean "we use it to fix crashes" invites scrutiny, and under-declaring invites rejection.
The SDK problem nobody accounts for#
Here's where solo developers get burned. You may not collect a single byte yourself — but your dependencies do. A crash reporter, an ad network, an attribution SDK, a push provider: each of these can collect device identifiers, app activity, or location, and under Google's rules that counts as your app collecting it. If the SDK then uses that data for its own purposes — ad targeting, cross-app profiling, benchmarking — that's sharing, and you have to declare it as shared, not just collected.
The most common specific offender in 2026 is the device identifier. Android ID is explicitly classified as a "Device or other IDs" data type, and if any SDK in your build reads Settings.Secure.ANDROID_ID, you must disclose it — no exceptions, no "but it's just for analytics." Before you fill out the form, you need an actual inventory of what every SDK in your dependency tree reads and transmits. Most developers don't have that inventory, which is exactly why their declaration drifts from their binary.
Android 17 changes that affect your declaration#
Android 17, shown in stable form at I/O 2026, gives users more granular control over location: they can grant precise location only for specific tasks while the app is open, rather than blanket-approving it. That changes how you should think about your location declaration. If your app only needs precise location for one feature and otherwise runs on approximate location, declaring blanket precise-location collection now looks heavier than your actual behavior — and "declared more than you use" reads as carelessness during review, even though it's the safer-sounding answer.
The cleaner approach in 2026 is to match the declaration to the runtime permission your app actually requests, and to the per-task grant model Android 17 introduces. If you request precise location only contextually, your Data Safety declaration and your in-app permission prompts should tell the same story. Reviewers increasingly look at all three surfaces together: the manifest, the runtime prompt, and the form.
Encryption in transit and data deletion#
Two declarations trip people up at the end of the form. First, "is all user data encrypted in transit?" — for almost any modern app the answer is yes, because you're using HTTPS, but you have to be sure every network call is, including the ones your SDKs make. A single plaintext endpoint makes your "yes" false.
Second, the data deletion question. Google wants to know whether users can request deletion of their data, and increasingly whether they can do it from within the app or via a web URL. If you collect personal info or account data, having a clear deletion path isn't just a form answer — it's a policy requirement, and a missing one is a rejection.
A pre-submission checklist#
Before you submit the Data Safety form, run through this in order:
- Inventory every SDK in your build and pull its data-collection disclosure.
- Trace every network call, including SDK traffic, and confirm all are encrypted in transit.
- List the data types your app and its SDKs actually touch, and split each into collected vs. shared.
- Assign an honest purpose to each — match it to what the data is really used for.
- Reconcile location against Android 17's per-task grant model and your runtime prompts.
- Confirm a data deletion path exists if you collect personal or account data.
- Cross-check the finished form against your binary one more time — the form must describe behavior, not intent.
Expect the review itself to take time. Google may take one to two weeks to review a Data Safety submission, and longer if it flags an issue, so submit early rather than the night before your planned launch. A rejected form on a live app can block your updates entirely until it's resolved.
How Stora fits in#
The reconciliation step — making your declaration match your binary — is the part that's tedious to do by hand and costly to get wrong, and it's exactly what Stora's compliance engine automates. Stora scans the build, identifies which data types your code and bundled SDKs actually access and transmit, and flags where your Data Safety declaration diverges from real behavior before you submit — the same mismatch Google would catch, surfaced while you can still fix it cheaply. Alongside that, Stora generates the rest of your Play listing, captures screenshots across the device matrix, and publishes when everything passes, so the form is one checked box rather than a week-long rejection loop.
Conclusion#
The Data Safety form feels like paperwork, but it's really a consistency test: does your declaration tell the truth about your binary? Most rejections aren't developers lying — they're developers who didn't know an SDK was collecting a device ID, or who declared more location than they use, or whose plaintext endpoint quietly broke their "encrypted in transit" answer. Build the SDK inventory, match your declaration to your runtime behavior, submit early, and treat the form as a description of what your app does rather than what you meant it to do. Do that, and it stops being the wall between you and a live listing.