1. Status and responsibility
The Data safety form covers the app globally at package level. If any currently distributed version collects a data type in any region, the global form generally needs to represent that practice. Keep this page and the Privacy Policy consistent with the submitted form.
2. Reviewed build facts
Build dependencies and SDK disclosures change. Check the exact production artifact and the current Google SDK Index/disclosure at submission time.
3. Proposed top-level answers
| Play question | Draft answer | Why |
|---|---|---|
| Does the app collect or share required user data types? | Yes | Google Mobile Ads automatically collects and shares listed data. Core session information, selected video bytes, and Share files catalog metadata also move off the originating device to peer devices. |
| Is all collected user data encrypted in transit? | No | Google says ad SDK traffic uses TLS, but video uses cleartext HTTP and session, synchronization, and catalog messages use cleartext WebSocket. Play’s “encrypted in transit” badge requires the declaration to fit all relevant transmitted data. |
| Can users request deletion of an app account? | Not applicable: no app account | No sign-up, login, or publisher cloud profile exists in the reviewed build. Do not create an account-deletion URL unless accounts are added. |
| Does the app provide a general data-deletion request mechanism? | Publisher decision required | Core data is local/ephemeral and users can clear app storage; Google retains its own ad data. Do not mark “Yes” merely because uninstall is available. Review the exact current Play wording and support process. |
| Is the app committed to the Families Policy? | Do not claim until target audience and ad compliance are confirmed | The repository does not establish a child-directed design, Families SDK review, or child-directed ad configuration. |
4. Proposed data-type declarations
The table is deliberately conservative. “Shared” below is required for Google Mobile Ads because Google describes the listed SDK data as collected and shared. The user-initiated exception for user-initiated LAN video and catalog transfers is addressed separately.
| Play data type | Collected / shared | Purpose | Ephemeral? | Required or optional? |
|---|---|---|---|---|
| Location → Approximate location Derived from IP by Google Mobile Ads |
Collected and shared | Advertising or marketing; analytics; fraud prevention, security, and compliance | No / do not claim ephemeral for advertising profiles or reporting | Safest draft: required when ads are served, because the app has no universal ads-off switch. Confirm consent/ad-serving behavior for every region. |
| App activity → App interactions App launches, taps, video views; Watch together commands and Share files selections |
Collected and shared | Advertising or marketing; analytics; fraud prevention/security; app functionality for peer synchronization | No, because ad SDK handling is not only ephemeral | Safest draft: required. Confirm production AdMob behavior. |
| App info and performance → Diagnostics | Collected and shared by Google Mobile Ads | Analytics; fraud prevention, security, and compliance | No | Safest draft: required when ads are served |
| Device or other IDs Ad ID, app set ID, applicable account-related IDs; plus local random session/device labels |
Collected and shared | Advertising or marketing; analytics; fraud prevention/security; app functionality | No, because ad identifiers are not only ephemeral | Safest draft: required. A user may reset/delete the advertising ID, but that is not necessarily a universal collection opt-out. |
| Photos and videos → Videos One Host-selected Watch together video or independently selected videos from a Host-created Share files catalog |
Collected under Play’s off-device definition. The peer transfer may qualify for the user-initiated sharing exception. | App functionality | Yes for the publisher architecture: real-time local streaming, no publisher video store. Confirm how Media3/system caches affect the answer. | Required to use the applicable Host/watch or Share files feature, even though the Host chooses which files to expose |
5. How to treat the user-initiated local stream
Google’s definition generally treats data transmitted off the device as collected, even if processed only in memory. Google separately says a transfer to a third party may be exempt from the sharing label when it results from a specific user-initiated action and the user reasonably expects the transfer.
A Host explicitly chooses Watch together or Share files, selects the video files, and starts hosting; a Joiner explicitly chooses that Host and, in Share files, chooses an item. That supports the user-initiated-transfer exception for marking the peer media/catalog transfer as “shared,” but does not automatically remove “Videos” from collection. Catalog names can also reveal personal information chosen by the Host, so reassess the live form’s Files/documents and Personal info categories against the final implementation. Confirm the final answer against the exact Play form and legal interpretation available at submission.
6. Data types not observed in the reviewed app
No app code or permissions were observed for the following publisher features:
- name, email address, postal address, phone number, race/ethnicity, political or religious beliefs;
- user account credentials or authentication information;
- precise device location or background location permission;
- contacts, emails, SMS/MMS, call logs, microphone recordings, or calendar events;
- health, fitness, financial, payment, government-ID, or purchase-history data;
- camera capture, photo-library scanning, or broad storage access;
- publisher-operated cloud analytics, Firebase Analytics, or remote crash reporting.
“Not observed” is not a promise about future releases or Google’s internal ad processing. Re-audit the merged manifest, dependency graph, mediation adapters, and release artifact.
7. Third parties and recipients
| Recipient | Data/path | Disclosure action |
|---|---|---|
| Google Mobile Ads / UMP | IP-derived approximate location, app interactions, diagnostics, identifiers, consent/ad signals | Include Google’s current SDK disclosure and every enabled mediation/ad technology provider. |
| Peer Host/Joiner devices | Video bytes; catalog item name, size, media type and duration; device model label; random Joiner ID; local IP/ports; session mode; and Watch together playback state | Disclose in privacy policy; evaluate the user-initiated sharing exception in the Play form. |
| Android / device system services | One or more document-picker grants, NSD/mDNS, notification, media-playback or connected-device foreground-service operation, Media3 playback, and eligible app-preference backup/device transfer | System-service handling may fall outside collection in specified cases. Review current Play definitions; disclose that allowBackup is enabled and no custom exclusions were observed. |
| Publisher cloud | None observed for media, accounts, analytics, or support | Do not claim “no internet” because Google ads/consent use internet access. |
8. Deletion, retention, and app accounts
No WiFi Stream app account exists, so Play’s account-deletion URL requirement does not apply to the reviewed build. Do not add a fictional deletion page or claim that a Google account used by Android is a WiFi Stream account.
- Users can end/leave a session, clear Android app storage, revoke document access through Android controls, or uninstall.
- Clearing storage removes the app’s SharedPreferences, UMP state, and applicable retained document grants stored with the app, but not the original video files.
- Android Auto Backup/device transfer may retain or restore eligible SharedPreferences because
allowBackup="true"and no custom extraction rules were observed. Users manage backup copies through Android/Google backup controls. - The publisher has no core-session backend record to locate or delete.
- Google advertising data is subject to Google’s retention/deletion controls and the user’s Google/Android privacy settings.
9. Required publisher verification before submission
- Open the production AAB/APK dependency report and confirm exact GMA Next-Gen and UMP versions.
- Check whether AdMob mediation, advanced reporting, experiments, or additional ad technology providers are enabled.
- Decide whether Android backup is needed; add tested data-extraction exclusions or disable backup if local ad/consent preference state should not be transferred.
- Confirm the UMP privacy message is published for the production AdMob app ID and the in-app privacy entry point appears where required.
- Decide the global target audience; configure child-directed or under-age treatment only if legally and policy appropriate.
- Do not claim encrypted-in-transit while local HTTP/WebSocket remain cleartext.
- Resolve the strengthened UGC/content-exchange classification before release: Share files exposes a Host-created multi-file catalog for independent Joiner selection, while the app still lacks verified in-app Terms acceptance, reporting, blocking, and moderation controls.
- Host the Privacy Policy at a public, non-geofenced, non-editable HTTPS URL and link it inside the app as Play requires.
- Replace the publisher identity and contact placeholder, then make the Play listing entity match the policy.
- Repeat this audit whenever code, SDKs, ads, target audience, or data practices change.
10. Official sources
- Google Play: Provide information for the Data safety section
- Google Play User Data policy
- Google Mobile Ads Next-Gen data disclosure
- Google UMP privacy setup
- Google Play app account deletion requirements
- Android Auto Backup documentation
Sources checked 31 August 2026. Official policies can change without an app update.