> For the complete documentation index, see [llms.txt](https://docs.appmysite.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmysite.com/app/download/android/google-plays-data-safety.md).

# Google Play's Data safety

### How to complete Google Play's Data safety form for an AppMySite app?

Google Play requires every developer publishing an Android app to complete a Data safety form. The form explains what user data the app collects or shares, why it is used, whether collection is optional, how users can request deletion, and whether the data is encrypted in transit.

This guide explains how to assess an Android app built with AppMySite. It covers the native app, third-party services such as Firebase, Sentry, and OneSignal, and any website displayed inside the app through a WebView.

{% hint style="danger" %}
This article is guidance, not a completed declaration for every AppMySite app. Your answers depend on your app version, enabled features, website, connected services, account settings, and backend. The Google Play developer is responsible for reviewing and submitting an accurate declaration.
{% endhint %}

#### 1. Before you start

Gather the following information before completing the Data safety form:

1. Your Android package name and current build or version number.
2. The features enabled in your AppMySite app.
3. The Firebase project connected to your app.
4. Your Sentry project, including its security, data-scrubbing, and retention settings.
5. Your OneSignal app and its privacy and retention settings, if push notifications are enabled.
6. Your website's privacy policy and information about data collected through login, forms, checkout, search, analytics, advertising, and uploaded media.
7. Your backend's logging, retention, deletion, and encryption policies.
8. Any older app builds still available on Google Play's production, open-testing, or closed-testing tracks.

{% hint style="warning" %}
Do not rely only on Android permissions when completing the form. Permissions indicate what an app can access, while the Data safety form describes what data the app and its connected services actually transmit and how that data is used.
{% endhint %}

#### 2. Understand Google's data safety requirements

Before identifying the data collected by your app, it is important to understand how Google defines collection, sharing, and other data-handling practices.

**What counts as collected data?**

Google generally considers data collected when it is transmitted from a user's device.

This includes data transmitted by:

* The app's native code.
* Third-party libraries or SDKs included in the app.
* The app owner's backend or website.
* A website controlled by the developer and displayed inside the app through a WebView.

Data transmitted directly to a third-party SDK provider must also be considered, even when it is not sent to the app developer.

**What counts as shared data?**

Data is generally considered shared when it is transferred to a third party for that party's own purposes.

Data processed by a service provider solely on the developer's behalf may qualify for Google's service-provider exception. However, this depends on the provider's agreement and how the service is configured.

For example, a service processing crash information only to provide crash reporting may qualify for the exception. An advertising provider using data to create profiles across different customers would generally need to be declared as sharing.

**Required versus optional data collection**

Data collection is optional only when users can choose whether that data is collected.

For example, users may be able to deny notification or location permissions. However, denying these permissions does not automatically stop other data collection, such as analytics or crash reporting.

Only declare collection as optional when the app provides a working control that allows users to prevent that collection.

**Ephemeral processing**

Data transmitted from a device must still be considered even when it is processed temporarily.

Use Google's specific definition of ephemeral processing rather than assuming that temporarily processed data is exempt from disclosure.

**Data linked to a user**

Data does not need to contain a person's name to be linked to them.

Identifiers such as app-instance IDs, Firebase installation IDs, Crashlytics installation UUIDs, OneSignal IDs, push tokens, and advertising identifiers may link information to an app installation or device.

These identifiers must be assessed even when the user's identity is unknown.

**Which app versions must be included?**

Google Play uses one Data safety declaration for each Android package name.

The declaration must cover the combined data-handling behavior of all app versions currently distributed through applicable active Google Play tracks, regions, and user groups.

This means that reviewing only the latest app build may not be sufficient if older versions remain available.

For more information, refer to <a href="https://support.google.com/googleplay/android-developer/answer/10787469" class="button primary">Google Play's Data Safety</a>

#### 3. Identify the data collected by your AppMySite app

An AppMySite Android app may collect or transmit data through its native features, third-party services, and connected website. The data collected depends on the app's build, enabled features, SDK configurations, and website functionality.

The following sections explain the types of data that may be collected by Firebase Analytics, Firebase Crashlytics, Firebase Cloud Messaging, Sentry, OneSignal, and websites displayed through a WebView.

{% hint style="warning" %}
The services described below may be present in AppMySite Android builds. Their behavior can vary depending on the app version and configuration. Review the services active in your app before completing the Data safety form.
{% endhint %}

### Firebase Analytics

Firebase Analytics measures app usage, user engagement, and interactions. It may automatically collect information about how users interact with your Android app.

**What data may Firebase Analytics collect?**

Firebase Analytics may collect:

* App launches, sessions, screen activity, and other app interactions.
* App version and installation source.
* Device model, operating system, language, and general device information.
* An app-instance identifier used to distinguish an app installation.
* Approximate geographic information derived from network information, such as an IP address.
* Notification interaction events when Firebase Cloud Messaging and Analytics are used together.

Firebase Analytics does not require a user's name or email address for its default measurements. However, custom events or user properties added by the app or website must be assessed separately.

**Why is this data collected?**

The primary purpose is analytics, including measuring app usage, engagement, feature adoption, and performance.

**Can users opt out of Firebase Analytics?**

No. Firebase Analytics data collection is mandatory in AppMySite apps, and users cannot opt out.\
\
The Android app should not be described as offering an Analytics opt-out unless collection is disabled until consent and the app actually provides a working consent control.&#x20;

Google documents options for disabling Analytics collection and advertising-ID collection, but SDK support does not mean those controls are implemented in every AppMySite build.

**How long is Firebase Analytics data retained?**

Data retention is controlled through the connected Google Analytics property.

For standard properties, the selectable retention period for user-level and event-level data is generally 2 or 14 months.

This setting does not necessarily remove aggregated information from standard reports.

Verify the actual retention settings in the connected Analytics property before completing your declaration.

{% hint style="info" %}
References:

* [support.google.com](https://support.google.com/analytics/answer/11593727)
* [firebase.google.com](https://support.google.com/analytics/answer/7667196)
* [support.google.com](https://support.google.com/analytics/answer/7667196)
  {% endhint %}

### Firebase Crashlytics

Firebase Crashlytics helps monitor app crashes, identify errors, and troubleshoot stability issues.

**What data may Firebase Crashlytics collect?**

Firebase Crashlytics may collect:

* Crash logs and stack traces.
* Application state when a crash occurs.
* Device model, operating system version, memory state, and other diagnostic information.
* Crashlytics installation UUID and Firebase installation ID.
* Fatal crashes, non-fatal exceptions, and application-not-responding events, depending on the implementation.
* Developer-defined custom keys, logs, and user identifiers when added by the app.
* Analytics breadcrumbs describing events shortly before a crash when Firebase Analytics is enabled.

**Why is this data collected?**

Crashlytics uses this information for app stability monitoring, diagnostics, and troubleshooting.

**Can users opt out of Crashlytics?**

Firebase Crashlytics supports opt-in reporting, but automatic collection is enabled by default.

Only declare Crashlytics collection as optional when the applicable app build disables automatic collection and provides a working user-facing control.

**How long is Crashlytics data retained?**

Firebase states that Crashlytics crash traces and associated installation identifiers are retained for 90 days before removal from live and backup systems begins.

{% hint style="warning" %}
Firebase Crashlytics does not normally capture screenshots of the Android screen. Crashlytics crash data should not be confused with Sentry screenshot attachments, which are explained below.
{% endhint %}

{% hint style="info" %}
References:

* [firebase.google.com](firebase.google.comhttps://firebase.google.com/docs/android/play-data-disclosure)
* [firebase.google.com](https://firebase.google.com/support/privacy/)
* [firebase.google.com](https://firebase.google.com/docs/crashlytics/android/customize-crash-reports)
  {% endhint %}

### Sentry

Sentry is used for crash reporting, error tracking, and performance monitoring in applicable AppMySite Android release builds.

Depending on the app's configuration, Sentry may collect diagnostic information and attachments when an error occurs.

**What data may Sentry collect?**

Sentry may process:

* Exceptions, stack traces, and crash information.
* Device, operating system, app version, network, memory, and runtime diagnostics.
* Performance transactions and profiling information.
* User-interaction breadcrumbs, such as taps and screen navigation.
* HTTP request breadcrumbs and request URLs.
* App-specific tags and contextual diagnostic values.
* Screenshots attached to error events.
* View-hierarchy attachments.

**Can Sentry screenshots contain personal or sensitive information?**

Yes. A crash or error screenshot can capture the visible app window. If a website is visible in the WebView, the screenshot may contain rendered website content, including:

* Names and contact details.
* Delivery or billing addresses.
* Search terms.
* Messages or form entries.
* Uploaded-photo previews.
* Payment-form content that is visible on the screen.

Crash screenshots should not be described as automatically masked unless the exact implementation has been tested and verified. Sentry Session Replay privacy masking is a separate feature and should not be assumed to apply to crash screenshot attachments.

{% hint style="warning" %}
Screenshot masking must be tested and verified for the exact implementation before declaring that sensitive information is automatically hidden.
{% endhint %}

**What information is included in a Sentry view hierarchy?**

An Android view hierarchy contains structural information about the app interface.

It may include:

* View classes and resource identifiers.
* Positions and dimensions.
* Visibility information.
* Parent-child relationships between interface elements.

In the Android implementation reviewed for this guide, view-hierarchy attachments do not extract WebView HTML, DOM content, typed text, or field values.

However, a screenshot attached to the same error event may still contain visible website content.

**Can Sentry collect search terms?**

Yes. Search terms may appear in Sentry even when the app does not create a dedicated search event.

For example, a search term may be captured:

* In the query string of a request URL recorded as an HTTP breadcrumb.
* In an exception or diagnostic message.
* Visually in a screenshot attached to an error.
* In custom context added by the app or website.

Whether this information is retained depends on the app configuration and Sentry's data-scrubbing settings.

**How long is Sentry data retained?**

Event attachments, including screenshots, persist for 30 days unless deleted earlier.

**Does Sentry automatically remove sensitive information?**

Sentry provides data-scrubbing controls, but their availability does not confirm that they are configured correctly for a particular project.

Review the following before making any claims about masking or filtering:

* Server-side data-scrubbing rules.
* Client-side `beforeSend` filtering.
* Breadcrumb filtering.
* Screenshot filtering.
* View-hierarchy filtering.

{% hint style="info" %}
References:

* [docs.sentry.io](https://docs.sentry.io/product/issues/issue-details/)
* [docs.sentry.io](https://docs.sentry.io/platforms/javascript/enriching-events/attachments/)
* [sentry.io](https://sentry.io/astro-assets/resources/legal/how-to-comply-with-gdpr-october-2024.pdf)
  {% endhint %}

### OneSignal

OneSignal supports push notifications when the applicable integration is enabled in an AppMySite app.

The information collected depends on the SDK configuration, enabled features, and data explicitly supplied by the app.

**What data may OneSignal collect?**

According to OneSignal's SDK documentation, it may collect:

* First-session and last-session timestamps.
* Session count and foreground usage duration.
* Operating system, device model, device language, timezone, and country.
* App version and application or package identifier.
* Notification permission status.
* Mobile carrier.
* IP address, depending on regional handling and account configuration.
* Push token and OneSignal identifiers.
* Notification delivery and click activity.
* GPS coordinates when location sharing is enabled and the user grants location permission.

OneSignal may also receive email addresses, phone numbers, external user IDs, tags, or custom events when the app explicitly sends this information.

**Why is this data collected?**

Depending on how OneSignal is used, the purposes may include:

* App functionality.
* Developer communications.
* Analytics.
* Advertising or marketing, when promotional notifications are sent.
* Personalization, when behavioral targeting is used.

**Can users opt out of OneSignal data collection?**

Users can control notification and location permissions on applicable Android versions.

However, denying these permissions does not necessarily prevent OneSignal from collecting other SDK or session information.

OneSignal also supports consent gating, but it must be enabled before the SDK is initialized.

Do not declare all OneSignal collection as optional unless the app implements the necessary consent controls.

**How long is OneSignal data retained?**

OneSignal states that:

* API message data is typically deleted around 30 days after delivery.
* Dashboard-created messages and much of the remaining app data may remain until manually deleted or until the OneSignal app is deleted.
* Subscriber retention varies by plan and activity.

Verify the connected OneSignal account's settings before declaring an app-specific retention period.

{% hint style="info" %}
References:

* [documentation.onesignal.com](https://documentation.onesignal.com/docs/en/data-collected-by-the-onesignal-sdk)
* [documentation.onesignal.com](https://documentation.onesignal.com/docs/en/handling-personal-data)
* [onesignal.com](https://onesignal.com/dpa)
  {% endhint %}

### Webview

An AppMySite app may display a website inside a native WebView.

Data collected through the website must be assessed separately from data collected by the native app and its SDKs.

Google requires developers to include data collected through a WebView when the developer controls the code or behavior delivered through that WebView.

Data collected when users independently navigate the open web may be treated differently under Google's guidance.

**What data may your website collect?**

Depending on its functionality, your website may collect or transmit:

* Account names, email addresses, phone numbers, and profile information.
* Login credentials or authentication tokens.
* Delivery and billing addresses.
* Orders, cart activity, purchase history, and subscription information.
* Payment information.
* Search terms and browsing activity.
* Messages, reviews, comments, and support requests.
* Photos, videos, documents, and other uploaded files.
* Precise or approximate location.
* Cookies, analytics identifiers, advertising identifiers, and marketing pixels.
* Server access logs, including IP addresses and user-agent information.

**Do third-party website services need to be included?**

Yes, where applicable.

Review any analytics, advertising, payment, chat, authentication, and hosting providers connected to your website.

AppMySite cannot determine all website data collection practices from the native app configuration alone.

**Does Google Play Billing collect payment information?**

Google Play Billing does not provide the app with a user's full card details.

However, if your website includes a payment form displayed through a controlled WebView, the website's payment-related data collection must be assessed separately.

{% hint style="warning" %}
Your Data safety declaration must account for both native app services and applicable data collection through your connected website. Reviewing only Firebase, Sentry, and OneSignal is not sufficient.
{% endhint %}

#### Firebase Analytics

Firebase Analytics measures app usage, user engagement, and interactions. It may automatically collect information about how users interact with your Android app.

**What data may Firebase Analytics collect?**

Firebase Analytics may collect:

* App launches, sessions, screen activity, and other app interactions.
* App version and installation source.
* Device model, operating system, language, and general device information.
* An app-instance identifier used to distinguish an app installation.
* Approximate geographic information derived from network information, such as an IP address.
* Notification interaction events when Firebase Cloud Messaging and Analytics are used together.

Firebase Analytics does not require a user's name or email address for its default measurements. However, custom events or user properties added by the app or website must be assessed separately.

**Why is this data collected?**

The primary purpose is analytics, including measuring app usage, engagement, feature adoption, and performance.

**Can users opt out of Firebase Analytics?**

Firebase Analytics supports controls for disabling Analytics collection and advertising-ID collection.

However, these technical capabilities do not mean that every AppMySite app provides an opt-out option.

Do not declare Analytics collection as optional unless the applicable app build disables collection until consent is provided and includes a working user-facing consent control.

**How long is Firebase Analytics data retained?**

Data retention is controlled through the connected Google Analytics property.

For standard properties, the selectable retention period for user-level and event-level data is generally 2 or 14 months.

This setting does not necessarily remove aggregated information from standard reports.

Verify the actual retention settings in the connected Analytics property before completing your declaration.

{% hint style="info" %}
References:

* [support.google.com](support.google.comhttps://support.google.com/analytics/answer/11593727)
* [firebase.google.com](firebase.google.comhttps://firebase.google.com/docs/crashlytics/android/customize-crash-reports)
* [support.google.com](support.google.comhttps://firebase.google.com/docs/crashlytics/android/customize-crash-reports)
  {% endhint %}

### Firebase Cloud Messaging

Firebase Cloud Messaging (FCM) supports the delivery of push notifications to Android devices.

**What data may Firebase Cloud Messaging collect?**

Firebase Cloud Messaging may process:

* Firebase installation IDs.
* Push-registration tokens.
* App version and Firebase SDK information.
* Notification interaction events when Analytics integration is present.
* Notification delivery metrics if optional delivery export is enabled.

**Why is this data collected?**

The primary purposes are app functionality and developer communications.

If push notifications are used to send promotional messages, advertising or marketing should also be selected as a purpose in the Data safety form.

**How long is Firebase Cloud Messaging data retained?**

Firebase retains installation IDs until deletion is requested through the relevant API.

After a deletion request, removal from live and backup systems may take up to 180 days.

#### 4. Review how your app handles user data

After identifying the data collected by your app's native services and connected website, review how that information is handled.

Google Play's Data safety form requires you to provide information about data collection, sharing, user choices, security, and deletion. Your answers must reflect the combined behavior of your app, its SDKs, website, and backend.

The following sections explain what you need to consider before completing these declarations.

**Are names and email addresses collected?**

Firebase Analytics, Firebase Crashlytics, and the native Sentry configuration reviewed for this guide do not require names or email addresses for their default operation.

OneSignal receives names or contact information only when the implementation explicitly provides the relevant information for features such as email, SMS, identity, tags, or custom attributes.

However, this does not mean that your app can automatically declare that it does not collect personal information.

Names, email addresses, and other personal details may be collected through:

* Website login and registration.
* Checkout forms.
* Contact forms.
* Loyalty programs.
* User profiles.
* Custom diagnostic logs or contextual information.
* Website content visible in Sentry screenshots.

Review your connected website, backend, and SDK configurations before selecting the applicable personal information categories.

{% hint style="warning" %}
Even when an SDK does not request names or email addresses by default, personal information may appear in custom logs, request URLs, diagnostic messages, or screenshots.
{% endhint %}

**Are search terms collected or retained?**

Search terms may be processed differently depending on whether users search through native app features or a connected website.

**Native app search**

Search terms may be:

* Stored locally on the device as search history.
* Retained until users delete the history, clear app data, or uninstall the app.
* Transmitted to an API as query parameters.
* Included in Sentry HTTP breadcrumbs or screenshots when an error occurs.

**Website search**

Search terms entered through a connected website may be recorded by:

* The website or backend.
* Website analytics services.
* Server access logs.
* Third-party search providers.

**How long are search terms retained?**

There is no single retention period that applies to all search terms.

Review the following separately:

* Local search-history storage.
* Sentry event retention and data-scrubbing settings.
* Website analytics retention.
* Backend and server-log retention.

The applicable retention period depends on where the information is stored and how the connected services are configured.

**Can users opt out of data collection?**

Different controls apply to different types of data collection.

Depending on the Android version and app configuration, users may be able to:

* Deny notification permission.
* Deny location permission.
* Disable notifications later through Android settings.

Some SDKs also support additional collection controls:

| Service              | Available technical controls                            |
| -------------------- | ------------------------------------------------------- |
| Firebase Analytics   | Programmatic consent and data-collection controls       |
| Firebase Crashlytics | Opt-in crash reporting and collection controls          |
| OneSignal            | Consent gating and subscription opt-out methods         |
| Sentry               | Collection disabling and data filtering through the app |

These capabilities do not necessarily mean that your AppMySite app provides corresponding user-facing controls.

For example, disabling notification permission does not automatically prevent analytics or crash-reporting services from collecting information.

{% hint style="danger" %}
Declare data collection as optional only when users have a working way to control that collection and the app honors their choice before or during collection.
{% endhint %}

Is the collected data encrypted in transit?

Google Play asks whether all collected user data is encrypted while being transmitted.

Firebase states that the end-user data described in its Android disclosure guidance is encrypted in transit using HTTPS. Sentry also states that data transmitted to its service is encrypted, while OneSignal requires TLS/HTTPS for its public-facing services.

However, the Google Play declaration applies to all collected user data, not only data transmitted through these SDKs.

**What should you verify?**

Before answering "Yes" to the encryption question, confirm that:

* Your website and every page displayed through the WebView use HTTPS.
* Forms, uploads, API requests, and images containing user data are transmitted over HTTPS.
* Website redirects do not switch from HTTPS to HTTP.
* Advertising, chat, payment, and analytics integrations use encrypted connections.
* No controlled website content transmits user data through unencrypted HTTP connections.

An Android app may be capable of loading an HTTP website. This does not mean that data transmitted through that website is encrypted.

If any collected user data is transmitted over HTTP, the correct answer to Google's all-data encryption question may be "No" until the website is corrected.

{% hint style="danger" %}
Do not declare that all collected data is encrypted solely because Firebase, Sentry, and OneSignal use encrypted connections. Your website, backend, and other connected services must also be reviewed.
{% endhint %}

**Is data shared with third-party service providers?**

Firebase, Sentry, and OneSignal may process information on behalf of the app developer.

Their data-processing agreements describe how applicable customer data is handled. However, the existence of these agreements does not automatically establish that every transfer qualifies for Google's service-provider exception.

For example:

* Firebase generally describes customers as controllers and Google as a processor or service provider for Firebase customer data.
* Sentry's Data Processing Addendum describes its processing of applicable service data according to customer instructions.
* OneSignal's Data Processing Addendum similarly describes its processor role for customer personal data.

Provider agreements may also cover service operations, security, legal compliance, product telemetry, and aggregated or de-identified information.

Optional integrations, advertising connections, and data-sharing settings can affect whether information must be declared as shared.

**What should you verify?**

Review the following for each applicable service:

* Which entity owns the Firebase, Sentry, or OneSignal account.
* Whether a Data Processing Addendum or applicable service-provider agreement is in place.
* Whether advertising, cross-service linking, product-improvement, or data-sharing options are enabled.
* Whether the provider combines the app's data with information from other customers for independent purposes.

{% hint style="danger" %}
Do not assume that information is never shared simply because a provider processes data on your behalf. Check the provider's agreement and actual configuration against Google's definition of sharing.
{% endhint %}

**How long is user data retained?**

Different services may retain information for different periods.

The retention period may also depend on the account plan, configured settings, data type, and deletion procedures.

The following table summarizes the retention information covered earlier in this guide.

<table data-header-hidden data-search="false"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Service</strong></td><td><strong>Retention information</strong></td></tr><tr><td>Firebase Analytics</td><td>Standard properties generally offer 2- or 14-month retention for user-level and event-level data</td></tr><tr><td>Firebase Crashlytics</td><td>Crash traces and associated installation identifiers are retained for 90 days before removal begins</td></tr><tr><td>Firebase Cloud Messaging</td><td>Installation IDs remain until deletion is requested; removal may take up to 180 days</td></tr><tr><td>Sentry</td><td>Event retention depends on the account plan and settings; attachments generally persist for 30 days unless deleted earlier</td></tr><tr><td>OneSignal</td><td>API message data is typically deleted around 30 days after delivery; other data retention varies by account settings, plan, and activity</td></tr><tr><td>Website and backend</td><td>Retention depends on the website's database, server logs, analytics services, backups, and other connected providers</td></tr></tbody></table>

These periods should not be treated as universal retention settings for every AppMySite app.

Verify the actual settings and deletion procedures of each connected service before making an app-specific statement.

**Can users request deletion of their data?**

Google Play's Data safety form asks whether users can request deletion of their data.

To answer this question, review the deletion mechanisms available through your app, connected services, website, and backend.

Check the following:

* Whether your website or backend provides account and data-deletion procedures.
* How user information can be deleted from connected services.
* Whether SDK identifiers and other collected information require separate deletion requests.
* Whether server logs, databases, backups, and uploaded files have applicable deletion procedures.

Firebase, Sentry, and OneSignal provide different deletion mechanisms, which must be reviewed against the services and configurations used by your app.

Do not assume that deleting an app from a device automatically deletes all information previously transmitted to third-party services or your backend.

{% hint style="warning" %}
The availability of a deletion mechanism in an SDK does not establish that your app provides a complete user-data deletion process. Confirm the actual procedures before completing this part of the form.
{% endhint %}

**Does data collection occur in preview or testing builds?**

Do not assume that an AppMySite Preview, test, or development build automatically disables data collection.

Whether information is collected depends on:

* The exact app binary and build type.
* Connected configuration files.
* Runtime feature flags.
* Whether each SDK is initialized.

Some monitoring services may be disabled in debug builds, while Firebase or another SDK may still initialize automatically.

To verify data collection in a particular build, review the actual binary, its merged Android manifest, or its runtime network traffic.

**Do testing builds need to be included in the declaration?**

Google Play's Data safety declaration must cover applicable app versions distributed through:

* Production tracks.
* Open-testing tracks.
* Closed-testing tracks.

Apps available only through an internal-testing track are treated differently under Google's guidance.

Review all applicable active tracks rather than relying only on the latest production build.

#### 5. Verify your app's data collection settings

Before completing Google Play's Data safety form, review the settings of the services connected to your AppMySite app. The information collected and retained may vary depending on your app's configuration, enabled features, and connected accounts.

The following checklists cover the settings that need to be verified for Firebase, Sentry, OneSignal, and your website or backend.

**Verify Firebase and Google Analytics settings**

Check the following in the Firebase and Analytics consoles:

* The Android app registered under your package name.
* Enabled Firebase products.
* Analytics data-retention duration.
* Google signals and advertising integrations.
* Ads personalization and data-sharing settings.
* BigQuery or other data exports.
* Crashlytics collection and custom data.
* Cloud Messaging delivery-metrics export.
* User-deletion procedures.

**Verify Sentry settings**

Check the following in your Sentry organization and project:

* Event retention for your organization's plan.
* Data-scrubbing rules and sensitive-field defaults.
* Whether screenshots and view hierarchies are enabled.
* Attachment-access permissions.
* Performance tracing and profiling sampling.
* URL query-string handling.
* User, tag, and context fields sent by the app.
* Data region and Data Processing Addendum (DPA) status.
* Event and attachment deletion procedures.

**Verify OneSignal settings**

Check the following in OneSignal:

* Whether the SDK is enabled for your app.
* Push, location, email, and SMS configuration.
* Consent gating.
* IP-address handling.
* External IDs, tags, and custom events.
* Subscriber and message retention.
* Dashboard-created versus API-created messages.
* Data deletion and export procedures.
* Account plan and DPA status.

**Verify website and backend settings**

Ask your website owner or developer to confirm:

* Every type of personal or sensitive data collected.
* Every analytics, advertising, payment, chat, authentication, and hosting provider.
* Cookie and tracking behavior inside the WebView.
* API, access-log, database, backup, and uploaded-file retention.
* Account and data-deletion procedures.
* HTTPS coverage and any mixed or cleartext HTTP content.

**Review the applicable Google Play data types**

Use the following matrix as a starting point for identifying the data types that may apply to your app.

This is a reference for reviewing your app's data collection practices, not a pre-filled declaration.

<table data-header-hidden data-search="false"><thead><tr><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Google Play data type</strong></td><td><strong>When it may apply</strong></td><td><strong>Common purpose</strong></td><td><strong>What must be verified</strong></td></tr><tr><td>App interactions</td><td>Analytics events, sessions, screen activity, notification clicks, Sentry interaction breadcrumbs</td><td>Analytics, app functionality</td><td>Active SDKs, automatic events, custom events, consent controls</td></tr><tr><td>Crash logs</td><td>Crashlytics and Sentry crash/error reporting</td><td>Analytics, app stability, diagnostics</td><td>Whether both services initialize; custom logs and keys</td></tr><tr><td>Diagnostics</td><td>Performance traces, memory/device state, network spans, ANRs</td><td>Analytics, app stability</td><td>Sampling, profiling, HTTP capture, account settings</td></tr><tr><td>Device or other IDs</td><td>App-instance IDs, installation IDs, Crashlytics UUID, OneSignal ID, push token, advertising ID</td><td>Analytics, app functionality, developer communications</td><td>Advertising-ID collection, account linkage, deletion process</td></tr><tr><td>Approximate location</td><td>Analytics or provider-derived country/region from IP address</td><td>Analytics, personalization, security</td><td>Whether IP/geolocation is stored and regional settings</td></tr><tr><td>Precise location</td><td>GPS supplied to OneSignal or an app/website feature after permission</td><td>App functionality, personalization</td><td>Feature enabled, permission flow, user choice, retention</td></tr><tr><td>Name and email address</td><td>Website account, checkout, contact forms, OneSignal identity features</td><td>Account management, app functionality, communications</td><td>Website/backend behavior and optional OneSignal fields</td></tr><tr><td>Photos and videos</td><td>Upload features or visible content in an error screenshot</td><td>App functionality or diagnostics</td><td>Upload destination, Sentry screenshots, retention and deletion</td></tr><tr><td>Search terms</td><td>Website/native search API, logs, request URLs, screenshots</td><td>App functionality, analytics, diagnostics</td><td>Local history, backend logs, Sentry breadcrumbs and scrubbing</td></tr><tr><td>Purchase history</td><td>Store purchases, subscriptions, website orders, analytics events</td><td>App functionality, account management, analytics</td><td>IAP/backend synchronization and website commerce stack</td></tr><tr><td>Payment information</td><td>Controlled website checkout, but not full card data from Google Play Billing</td><td>App functionality</td><td>Payment provider and whether sensitive fields ever enter app-controlled systems</td></tr></tbody></table>

#### 6. Complete the Data safety form in Google Play Console

Once you have reviewed the data collected by your app and verified the settings of your connected services, you can complete the Data safety form in Google Play Console.

The form requires you to declare whether your app collects or shares user data, how that data is handled, and the purposes for which it is collected.

**Steps to complete the Data safety form**

1\. Open your app in Google Play Console.

* Select the Android app for which you want to complete the Data safety form.

2\. Open the Data safety section.

* Navigate to App content > Data safety.

3\. Confirm whether your app collects or shares user data.

* Base your answer on the data collected or shared by your app, its SDKs, connected website, and backend.

4\. Answer whether all collected data is encrypted in transit.

* Consider all destinations to which your app transmits user data, including your website and connected services.

5\. Answer whether users can request data deletion.

* Base your answer on the deletion procedures available through your app, connected services, website, and backend.

6\. Select every applicable data type.

* Use the information gathered during your review to identify the data types collected or shared by your app.

7\. Provide the required details for each data type.

* Specify whether the data is collected, shared, or both.
* Indicate whether collection is required or optional.
* Indicate whether the data is processed ephemerally.
* Select the purpose or purposes of collection.

8\. Review the store-listing preview.

* Check the information that will appear in your app's Data safety section.

9\. Save the form as a draft if any information remains unresolved.

* This includes unanswered questions about SDKs, website data collection, retention, or service-provider arrangements.

10\. Review the declaration whenever your app's data-handling practices change.

* Recheck the form when you make changes to your app, website, SDKs, permissions, or connected services.

#### 7. Common mistakes and final checklist

Before submitting your Data safety form, review the common mistakes below and use the final checklist to confirm that you have considered the data collected by your app, its SDKs, and connected services.

**Common mistakes to avoid**

* Declaring that no data is collected because AppMySite itself does not request a user's name or email address.
* Ignoring data collected by Firebase, Sentry, OneSignal, advertising, payment, or chat SDKs.
* Excluding data collected through a website displayed inside a controlled WebView.
* Assuming that data collection is optional simply because an Android permission can be denied.
* Assuming that all crash-reporting services collect the same information.
* Declaring that screenshots are masked without verifying how crash screenshots are captured.
* Using a service's standard or maximum retention period without checking the actual account settings.
* Declaring that all data is encrypted because native APIs use HTTPS, even when the website loads an HTTP form.
* Reviewing only the latest app build when older versions remain available on active Google Play tracks.
* Assuming that pseudonymous installation identifiers are anonymous and do not require disclosure.

**Final checklist before submission**

Confirm that you have reviewed the following:

Before submitting the Data safety form, confirm that you have reviewed the following:

* The exact Android release artifact and version.
* All active Google Play tracks and older distributed versions.
* Firebase Analytics, Crashlytics, and Cloud Messaging.
* Sentry configuration, screenshots, breadcrumbs, and retention.
* OneSignal configuration and retention, if applicable.
* Website and WebView data collection.
* All applicable Google Play data types and purposes.
* Whether collection is required or optional.
* Whether data is collected, shared, or both.
* Data retention, user opt-out, and deletion procedures.
* HTTPS and encryption across all data flows.
* The privacy policy and information provided in the declaration.

{% hint style="warning" %}
Do not submit a declaration based on assumptions about SDK behavior, website data collection, retention, or security settings. Verify the information that applies to your app.
{% endhint %}

#### &#x20;8. Frequently asked questions

This section answers common questions about completing Google Play's Data safety form for an AppMySite Android app.

#### Can AppMySite complete the Data safety form for me?

AppMySite can provide information about the native app and its standard integrations. However, only the app owner can provide a complete declaration.

This is because the app owner controls the website, Firebase project, OneSignal configuration, optional services, backend, privacy policy, and Google Play account.

#### Does GDPR compliance automatically answer the Google Play Data safety form?

No. A service provider may offer GDPR-compliant terms and controls, but Google Play still requires a declaration of your app's actual data-handling practices.

This includes the data collected or shared, its purposes, security measures, retention-related practices, and deletion mechanisms.

#### Does the app collect names or email addresses through crash reporting?

The standard telemetry configuration does not deliberately assign names or email addresses to Firebase Analytics or Sentry.

However, this information may still appear in:

* Custom logs.
* Request URLs.
* Exception messages.
* Website content visible in screenshots.
* Website or backend data flows.

These sources must be reviewed before completing the declaration.

#### Are payment fields automatically hidden from Sentry screenshots?

No automatic masking should be assumed.

If payment information is visible in the app window when an error screenshot is captured, it may be included in the screenshot.

Secure-window behavior and payment-provider rendering should be tested. Screenshot capture should also be disabled or filtered on screens containing sensitive information.

#### How often should I review my Data safety declaration?

Review your declaration:

* Before publishing your app for the first time.
* Before submitting an update that changes how data is handled.
* After adding or upgrading an SDK.
* After changing website tracking or forms.
* Whenever Google or an SDK provider updates its disclosure guidance.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.appmysite.com/app/download/android/google-plays-data-safety.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.