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.
ZTE Enrollment Profiles Issue
Greetings everyone! New day, new challenge. I’ve received a number of Zebra tablets. We already use ZTE, which works fine, but as you know it assigns devices to a single profile based on the serial number. The issue is: These tablets (same model) will be used for many different purposes, and I don’t think it’s efficient to take each device out of the box, read the serial number, and manually assign it to a different ZTE profile. I could easily end up managing 200 different profiles. So my question is: Is there a way to let the device choose which group or category it should belong to during enrollment? For example, during setup the device could ask the user which category it belongs to and based on that selection it would automatically join the correct group and receive the appropriate configuration. Is this possible? Or am I dreaming? 😄 Has anyone faced this issue and found a good solution? Thanks in advance!
Intune Migrate Managed Google Play Account to Managed Google Domain
Hi there, I’m looking for clarification on Microsoft's recent update about upgrading tenants from a Managed Google Play account to a Managed Google Domain account in Intune. Intune Android Enterprise Update We have 130+ Android Enterprise devices enrolled in Intune with an old Gmail account we dont have direct access to. Our Intune connection was originally set up using this account back in 2023. Now we have the option to "Upgrade" our account but we need to understand the risks before we proceed. Microsoft says that we can continue managing devices under the new Entra‑linked Managed Google Domain account without deprecating the old method, and without device impact. Is the migration fully in‑place and non-disruptive? Meaning: No need to retire devices No re-enrollment No break in Managed Google Play sync No loss of approved apps or assignments Is this migration guaranteed to perform an in-place transition of the administrative account without: Breaking the existing Android Enterprise binding Generating a new enterprise ID Requiring any user/device actions Interrupting app delivery or policy deployment? Any advice from someone who has already completed the upgrade would be great! Thank you in advance for any clarification.
Option for MDM to place app shortcuts on home screen
We have a great wish to place shortcuts for specific apps on the home screen when the app is installed (or at a later point), but this doesn't seem to be possible. When we discuss this with our MDM provider (SOTI), we are told, it is a Google/Android limitation, and this seems a bit strange to me; is it really not possible to place shortcuts on the home screen to your own liking? I hope this resonates with others - or even better; that I can be corrected, and there is a smart and easy way to achieve this goal. We run all our Android devices as fully managed, if that is relevant.
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".
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?