Privacy-oriented explanation per connection
1 — Screen Control ↔ Android Management API (AMAPI)
Screen Control sends device-management configuration to Google AMAPI, including policies, commands, enrollment metadata, and app policy references. Screen Control receives AMAPI device-management data back, such as compliance state, applied policy state, device inventory, and app reports.
2 — AMAPI ↔ Device
The device receives provisioning and policy instructions through Google’s Android management components and reports management state back to AMAPI. This channel exchanges device-management data such as device identifiers, policy state, compliance state, installed-app state, and update/app-management status.
3 — Play Store ↔ Device
The device uses managed Google Play / Play Store to obtain approved apps and app updates. This is app-distribution traffic. By itself, this does not mean that end-user Google content such as Gmail, Drive, Calendar, Contacts, or personal account data is exchanged. See caveat explained below.
4 — Screen Control ↔ Device
Prowise also communicates directly with the device through Screen Control-specific mechanisms. This allows Prowise to provide additional configuration beyond standard AMAPI capabilities, see live online/offline device status, send push notifications, enable remote access, and issue certain commands or updates. This connection should be treated as a separate Prowise-controlled management channel, distinct from AMAPI and Play Store traffic.
5 — Screen Control ↔ Play Store
Screen Control can integrate with Google Play Store management interfaces, such as Google’s managed Play iframe approach, so administrators can access, approve, configure, and manage apps through the Screen Control UI. This is an administrative app-management flow, not a direct device telemetry flow.
Enrollment
For EDLA enrollment, Screen Control creates an enrollment token through the 1 — Screen Control ↔ AMAPI connection. This token is then applied during firmware installation and used by the device through the 2 — AMAPI ↔ Device connection to complete enrollment. The token ensures that the device is enrolled in the intended mode, specifically as a dedicated device and userless, and that the device is associated with the correct organisation in Prowise / Screen Control.
Google Chrome
Google Chrome is required for certain core functionality and is installed after screen enrollment. To limit user data sharing with Google, we recommend disabling Chrome browser sign-in through Screen Control app policies.
Note that this does not prevent users from signing in to Google websites in the browser, which may still result in data sharing with Google. This is, of course, possible with any web browser.
Administrators can remove Chrome entirely, but this is not recommended because it breaks sign-in to Central / Prowise services and may affect sign-in in other apps.
Summary
The enrollment mode is dedicated device, userless. In this mode, no specific end-user profile is logged in on the device for management purposes. Google uses an anonymous/userless account to facilitate Android Enterprise services such as policy enforcement and managed Play access.
This means the standard AMAPI/managed Play setup does not collect or exchange end-user Google content by default. The relevant data is primarily device-management and app-management data: device identifiers, policy state, compliance state, installed app state, update status, and similar operational metadata.
There is one important caveat: if Google apps are approved in Screen Control, installed on the device, and then a person signs in to those apps with a Google user account, that creates a separate user-account data flow. That app-level sign-in is outside the baseline userless dedicated-device management model. This is easily prevented by administrators by not approving additional Google apps.