Cloud DPC poll latency on AMAPI - anyone solved sub-second kiosk transitions without a custom DPC?
Looking for input from other AMAPI customers / EMM operators.
We run a small managed Android fleet using Android Management API +
Android Device Policy. The workflow is dedicated-device, kiosk-mode
as default state, with periodic supervisor-driven transitions in and
out of kiosk for short operational windows.
Our pain point is latency on routine kiosk transitions. When we PATCH a
device's policyName from a non_kiosk variant to a kiosk variant, time
from API call to device-side behaviour change varies enormously:
- Best case: ~30 seconds (Cloud DPC awake)
- Typical: 3 to 8 minutes
- Worst seen: >4 hours (Cloud DPC asleep on idle devices, especially
on certain Vivo Funtouch builds)
Verified via device.lastStatusReportTime. Cloud DPC on idle devices
simply doesn't check in often. Our own WebSocket channel delivers in
<300 ms RTT, so the latency is in the Cloud DPC poll cadence, not in
our code or network.
What we've already done:
- Play Integrity attestation
- Stable applications[] policy (no incidental policy pushes)
- In-app identity rotation cache (no policy churn for routine refresh)
- WebSocket fast-path for informational delivery
- Minimised policy diffs
A few questions for the community:
1. Has anyone found a reliable way to trigger an immediate Cloud DPC
poll from server-side via AMAPI? device.issueCommand with
REQUEST_DEVICE_INFO sometimes seems to nudge it, but documented
behaviour and observed behaviour don't line up consistently.
2. Is calling Activity.startLockTask() / stopLockTask() from inside a
managed app (already in the lockTaskAllowed list) supported as a
way to engage kiosk independent of policy toggles? Reading the
docs, lockTaskAllowed=true grants permission, but actual
engagement requires a foreground call. If a managed app drives
that call itself, is that fine, discouraged, or fragile?
3. For anyone running fleets on Vivo Funtouch (Y22 / Y22s / V2521
in particular) have you worked around, accepted, or had Google
address the long Cloud DPC sleep behaviour? OEM aggressive
background management seems to be a real factor.
4. For those who've raised feature requests or had partner-level
conversations with the AE team in the post-Play-EMM-API era
any pattern on what gets responses vs goes silent? Aware new
custom DPC registrations are closed; curious whether anyone has
had a use-case-specific discussion produce something other than
"use AMAPI as-is".
We're not trying to replace Cloud DPC for what it does well
(enrollment, app distribution, permissions). The specific operational
need is kiosk transitions on the order of seconds, not minutes, for
safety-sensitive workflows.
Open to pointers, war stories, or "here's how we solved it" replies.
Happy to share more detail in DMs if anyone has hit the same.
