Play EMM API: Devices.get / Devices.list unavailable for extended duration
Issue Description : After device enrollment, Devices.get() and Devices.list() intermittently return “No Device was found”/an empty list for the same device for an extended duration greater than 15 mins. This behavior persists beyond the propagation delay described in the documentation, which is 2 mins. Impact: App Distribution affected Our EMM supports incremental app distribution: Fetch current device policy Merge additional apps Re-apply policy using Devices.update() When devices.get() / devices.list() are unavailable: We cannot retrieve the current device policy --> Incremental app distribution fails Detailed Reproduction Steps: Enroll device (afw#DPC_IDENTIFIER managed accounts method) Call Devices.update() to distribute apps that were pre-configured for installation during the enrollment process. Call succeeds Custom DPC adds managed Google Play account on Device Call Devices.List(enterpriseId, userId) → Returns empty for 15+ mins Call Devices.get(enterpriseId, userId, deviceId) → Returns 404 "No device was found" during this time Queries: What is the expected propagation delay for custom DPCs? How long should we poll and check if the deviceId is listed in devices.list()? Any workflow changes needed from our side? How do other EMMs handle incremental app distribution?
Play Protect is blocking our DPC app — appeal already submitted, looking for guidance
Hello everyone, We are currently facing an issue where Google Play Protect is blocking our Android application during device provisioning. Context: - It is not distributed via Google Play (but is already published); it is hosted externally and installed during provisioning via QR code. - The app is properly signed, and provisioning works at the system level, but Play Protect blocks the app with the message “App blocked to protect your device.” - This started happening recently on new devices / factory reset devices. We have already submitted the official Play Protect appeal form as recommended in the documentation: The form was completed with all required information (APK, package name, signing certificate, use case, etc.). At this point, we are looking for guidance from the community: - How long does it usually take for the Play Protect appeal form to receive a response or decision? - Is there any additional step or channel recommended for Android Enterprise DPC apps in this situation? Any insights or shared experiences would be greatly appreciated. Thank you in advance for your time and support. Best regards
Issue with Android Enterprise provisioning: afw#identifier invalid and Play Protect blocking app during QR enrollment
We are an organization using a third-party MDM / Device Policy Controller (DPC) solution to manage our Android Enterprise devices. The DPC application is published on Google Play and has been working for managed provisioning. Recently, we started facing issues during Android Enterprise enrollment, and we are seeking guidance on the correct and supported setup. Issues observed 1. afw#identifier enrollment When attempting enrollment using afw#<identifier>, the setup fails with errors such as invalid token, wrong setup, or unable to continue enrollment. This previously worked and now fails consistently, even though the DPC remains published on Google Play. 2. QR code–based provisioning When using QR code provisioning, the device completes initial setup but then Google Play Protect shows “App blocked by Play Protect” for the DPC. The DPC app is Play-approved and not sideloaded by end users. We have already submitted a Play Protect appeal through the official appeal form. 3. Distribution method For QR provisioning, the DPC APK is currently hosted on our own HTTPS server, and the QR includes: Device Admin component SHA-256 signature checksum Secure download location Despite this, Play Protect flags the app after provisioning. Clarifications we are seeking Are there recent changes or requirements for afw#identifier enrollment that could cause invalid token or setup errors? Does Play Protect apply additional checks during QR-based provisioning, even for Play-approved DPC apps? Is using a self-hosted APK download location still supported for Device Owner provisioning, or is Managed Google Play / Zero-Touch enrollment now required? Is there a supported way to allowlist or whitelist a legitimate enterprise DPC app so it is not blocked during provisioning? Are there recommended best practices for third-party MDM providers or enterprise customers to avoid Play Protect blocks during enrollment? We are not attempting to bypass Play Protect or supported security mechanisms. We want to ensure our Android Enterprise setup follows current Google-recommended practices and understand the correct approach going forward. Any guidance or clarification from the community or product experts would be appreciated.
AMAPI requests for enterprises.applications.get and enterprises.policies.patch are failing intermittently
Is anyone observing AMAPI requests for GetApplication and PatchPolicies failing intermittently ? I am observing intermittent failures with the log - "googleapi: Error 503: The service is currently unavailable., backendError".Chrome OS + Crostini: The Missing Bridge to Android Development
Hello Community, I recently read an article about connecting a Windows PC to an Android phone, which got me thinking: we need a similar focus on connecting Chrome OS (via Crostini) to Android devices. Since both Android and Chrome OS are Google products, the integration should be seamless. If Google wants to grow Chrome OS adoption, developers are the ideal first target. However, making it easy for developers to build Android apps on Chrome OS must be a priority, and currently, there are significant friction points. The Technical Blockers My Android development on Chrome OS has been halted for over a month due to persistent issues: ADB Debugging on Managed Devices: My managed Chromebook (I am the admin) has the "Enable ADB debugging" toggle locked. Despite a month of searching, I haven't found a fix. Connection Instability: Both USB and Wi-Fi debugging work intermittently and then fail. I have tested this with a modern Android 15 phone and an older Lollipop tablet; the connection fails on both, pointing to an issue on the Chromebook side. USB File Transfer: There is a known issue transferring files from Crostini to USB devices (requiring a workaround of copying to the Chrome OS files app first). The Strategic Picture Google should not depend on Microsoft Windows for Android development. Chrome OS is already a high-quality product—I use it daily. For example, upgrading my Crostini VM from Debian 12 (Bookworm) to Debian 13 (Trixie) was a pleasure and required no reinstallation. This stability proves Chrome OS is a serious development platform, not just a "cheap" alternative. Addressing the "Aluminum OS" Rumors There is a current campaign discrediting Chrome OS, citing rumors about a new "Aluminum OS." I believe these rumors are misinterpreted. Rather than dropping Chrome OS, it appears Google is aiming for the high-quality device segment. Regardless of naming conventions, Google is walking securely, step-by-step, from a browser to a full OS. Conclusion I strongly advise Google to continue its efforts in making Chrome OS a high-end development platform. The community is involved and patient (a major quality of developers!), but we need these bridge issues—specifically ADB debugging and USB file transfers—solved to fully unlock the potential of the ecosystem.