If you've received a message from Google Play Console saying your app violates policy because the Data Safety section is incomplete or inaccurate — you're in good company.
Having built and shipped apps since 2014 with a cumulative total of over 50 million downloads across my portfolio, this particular rejection has caught me off guard more than once. It's especially tricky for Rork developers, because Rork automatically includes several SDKs (AdMob, Firebase, Expo modules) that collect data behind the scenes — data you may not even realize you need to declare.
This guide breaks down exactly which SDKs collect what data, and how to fill out the Data Safety form accurately to get your app approved.
Why Rork Apps Are Prone to Data Safety Rejections
Google mandated the Data Safety section in 2022. It requires developers to disclose what user data their app collects, how it's used, and whether it's shared with third parties.
The catch for Rork developers is this: even if you didn't write code to collect data yourself, any SDK bundled in your app counts. If AdMob is collecting advertising IDs and you didn't declare it, that's a violation — regardless of whether you added that code intentionally.
The three most common failure patterns are:
- Missing AdMob advertising ID declaration: Ad SDKs always collect device identifiers. Not declaring this is one of the fastest ways to get rejected
- Overlooking Firebase Crashlytics: Crashlytics sends diagnostic data (crash logs, device info) to Firebase servers. This falls under "App Performance" in the Data Safety form
- Vague user content handling: Apps with chat features or photo uploads need to declare "User Content" data collection
SDK Data Collection Reference for Rork Apps
Here's a practical reference for the SDKs commonly bundled in Rork-generated apps.
AdMob (Google Mobile Ads SDK)
If your app uses AdMob, these declarations are required:
- Data type: Device or other IDs (advertising ID)
- Purpose: Advertising or marketing
- Shared with third parties: Yes (Google)
- User control: Optional (users can reset advertising ID)
AdMob Declaration Checklist:
✅ Device or other IDs → Collected: Yes
✅ Advertising or marketing → Purpose: Yes
✅ Data shared with third party → Yes (Google)
✅ User can request data deletion → Yes (advertising ID reset)
Firebase Crashlytics / Analytics
- Crashlytics: Collects crash logs and diagnostic data → declare under "App Performance"
- Analytics: Collects in-app behavior and device info → declare under "App Activity"
- Authentication: Collects email addresses or phone numbers → declare under "Personal Info"
Expo / React Native (Base Framework)
Expo itself doesn't collect data independently, but specific Expo libraries may require declarations. For example, if your app uses expo-notifications, you need to declare device token (identifier) collection.
How to Correctly Fill Out the Data Safety Form
Step 1: Identify All SDKs in Your App
Open your Rork project's package.json and search for relevant packages:
cat package.json | grep -E "(google|firebase|expo|revenuecat|analytics|admob)"Sample output:
"expo-ads-admob": "^3.0.0",
"@react-native-firebase/crashlytics": "^18.0.0",
"expo-notifications": "^0.27.0",
"react-native-purchases": "^7.0.0"
Use this list as your starting point for the Data Safety declarations.
Step 2: Check Each SDK's Official Data Safety Guidance
Most major SDKs publish guidance specifically for Google Play's Data Safety form:
- AdMob: Google publishes a sample Data Safety form for AdMob at the Google Mobile Ads Help Center
- Firebase: Firebase Console offers a downloadable CSV file with pre-filled Data Safety responses for each Firebase product
Step 3: Fill Out the Form in Google Play Console
In Google Play Console, navigate to the "Data Safety" section and work through each question:
- Does your app collect or share user data? → "Yes" (applies to nearly every app)
- Select data types: Check all types that match your SDK usage
- Select purposes: Advertising, analytics, app functionality, etc.
- Third-party sharing: Select "Yes" if using ad SDKs
- Encryption: "Yes" for HTTPS communications
- Submit for review: Don't just save — click "Submit for Review"
Common Mistakes and How to Fix Them
Mistake 1: Declaring "User Choice" When There's No Opt-Out
If you declare a data collection as "based on user choice" but your app doesn't actually provide a way for users to opt out, that's a contradiction. AdMob's advertising ID collection is functionally required to serve ads — it should be declared as "required for the app's functionality," not user choice.
Mistake 2: Missing RevenueCat Purchase History
If you've integrated RevenueCat for in-app purchases, purchase history (financial information) must be declared.
RevenueCat Declarations:
✅ Financial Info → Purchase history → Collected: Yes
✅ Purpose: App functionality (processing purchases)
✅ Shared with third parties: Yes (RevenueCat, Apple/Google)
This is one of the most frequently missed items in Rork apps that include subscription or one-time purchase features.
Mistake 3: Wrong Location Precision
If your app uses Google Maps or any location-based feature, you need to distinguish between "Precise location" (GPS, within 10 meters) and "Approximate location" (city or region level). Using the wrong precision category will result in a policy flag.
After Rejection: What to Know Before Resubmitting
Saving is not the same as submitting: After updating the Data Safety form, just clicking "Save" doesn't trigger a review. You must click "Submit for Review" — and typically submit a new APK or AAB alongside the updated form.
You may need a new build: If the rejection is about actual app behavior (unnecessary permissions, SDK misuse), updating your privacy policy URL alone won't be enough. Submit a new build with the behavior corrected.
Review timeline: After resubmission, expect 3–7 business days for Google to review. Submitting multiple times in quick succession doesn't speed things up — it resets the queue.
Align Your Privacy Policy With Your Declarations
The Data Safety form and your privacy policy must be consistent. If you declare data collection that your privacy policy doesn't mention — or vice versa — you risk another rejection.
Here's a template snippet for AdMob-using apps:
This app uses Google AdMob to display advertisements.
Google AdMob may collect your device's advertising identifier
to serve personalized ads. For more information, please refer
to Google's Privacy Policy.
Many Rork apps use the auto-generated Expo privacy policy as a starting point, which is fine — but make sure you've customized it to reflect every SDK you're actually using. For a broader guide on data protection in Rork apps, see Rork App Privacy Policy and Data Protection Guide.
Further Google Play Policy Resources
If you're dealing with other types of Google Play rejections beyond Data Safety — metadata violations, advertising policy issues, permissions policy — see How to Fix Google Play Policy Violations in Your Rork App.
Start with your package.json, write down every SDK you're using, and work through the Data Safety form one SDK at a time. Once you have the full picture of what data flows through your app, the declarations become straightforward.