| name | play-data-safety |
| description | Complete and maintain the Google Play Data Safety form accurately, aligned to shipped SDKs. Use this when launching, adding SDKs, or auditing data practices. |
Play Data Safety
Instructions
Google Play requires every app to declare, via the Data Safety form, exactly what data is collected or shared, why, and whether it's encrypted in transit. False declarations are a policy violation and a common source of takedowns. This skill shows how to build an accurate, verifiable declaration.
1. Form Structure
Four sections:
- Data collection and security — is any data collected or shared? encryption in transit? deletion mechanism?
- Data types — for each type, purpose, whether collected/shared, whether optional.
- Security practices — encryption in transit, independent security review, deletion request URL.
- App categories — ad IDs, account management, etc.
2. Data Type Categories
Google's categories (high level — each has sub-types):
- Personal info (name, email, address, user IDs, phone).
- Financial info (payment, purchase history, credit info).
- Health and fitness.
- Messages (emails, SMS, in-app messages).
- Photos and videos.
- Audio files.
- Files and docs.
- Calendar.
- Contacts.
- App activity (interactions, search history, installed apps).
- Web browsing.
- App info and performance (crash logs, diagnostics, other app performance).
- Device or other identifiers (device IDs, advertising IDs).
- Location (precise and approximate).
3. Allowed Purposes
A single data type can be declared with multiple purposes:
- App functionality
- Analytics
- Developer communications
- Advertising or marketing
- Fraud prevention, security, and compliance
- Personalization
- Account management
Every purpose needs at least one concrete use in-app or in an SDK.
4. Build a Declaration Spreadsheet
Audit the app and SDKs, then record in docs/data-safety.yaml:
declarations:
- data_type: email_address
collected: true
optional_collection: false
shared: false
purposes: [account_management, app_functionality]
sources: [app_signup, firebase_auth]
- data_type: advertising_id
collected: true
shared: true
shared_with: ["admob"]
purposes: [advertising]
sources: [admob_sdk]
- data_type: crash_logs
collected: true
shared: false
purposes: [analytics, app_functionality]
sources: [crashlytics]
- data_type: approximate_location
collected: true
shared: false
purposes: [app_functionality]
sources: [app_direct]
5. Map SDKs to Declarations
Common SDK → data types:
| SDK | Likely declarations |
|---|
| Firebase Analytics | App activity, device identifiers, crash logs |
| Firebase Crashlytics | Crash logs, diagnostics, device identifiers |
| Firebase Auth | Email, user IDs |
| AdMob | Advertising ID (shared), approximate location |
| Facebook SDK | Advertising ID, app activity, device identifiers |
| Branch / Adjust / AppsFlyer | Device identifiers, app activity; often shared |
Check each SDK's official data-safety documentation and update the spreadsheet when bumping versions.
6. Encryption in Transit
You must declare if data is encrypted in transit. If your app and all embedded SDKs use HTTPS, declare Yes. Android 9+ default network security config blocks cleartext traffic; keep it:
<application android:usesCleartextTraffic="false" ... />
Don't add per-domain cleartext exceptions without a compelling reason.
7. Data Deletion
Declare how users can request deletion:
- In-app flow (preferred): a "Delete my account" option in settings.
- Web URL.
- Email address (less preferred; Google flags manual-only flows).
Implement the in-app path with a server-side job that cascades deletion across backend stores and within 30 days by default.
8. Submission via Play Publishing API
Data Safety is not part of supply; use the Play Publishing API directly to keep it in version control.
TOKEN=$(./scripts/play-token.sh)
curl -X POST \
"https://androidpublisher.googleapis.com/androidpublisher/v3/applications/$PKG/edits/$EDIT/datasafety" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d @docs/data-safety-payload.json
Alternatively, generate the payload from data-safety.yaml and paste into the Console UI until the API stabilises.
9. Audit Cadence
- Every SDK bump PR: reviewer checks
docs/data-safety.yaml diff.
- Quarterly: full audit — run
./scripts/grep-collectors.sh to surface any new APIs that send data off-device.
- Annually: legal/privacy review.
Example collector grep:
rg -n 'HttpUrl|fetch\(|URLSession|post\(|send\(' --type kotlin --type swift \
--glob '!**/test/**' --glob '!**/Tests/**'
10. Consequences of Mismatch
- Warning email from Play with a 14-day fix window.
- Removal from search / featured placement.
- Takedown for repeated or egregious misdeclaration.
- Policy strike which, accumulated, closes the developer account.
None of these are rare. Take the form seriously.
11. Interaction with Other Policies
- Families policy (apps for kids): stricter rules on advertising IDs and personalization.
- Background location: requires separate prominent disclosure and declarations form.
- Health Connect / Fitness APIs: additional developer policy attestations.
12. Checklist
