Is there any way to disable Google Play Protect (GPP) during QR code enrollment to avoid blocking an MDM app?
I am the developer of Headwind MDM, the open source MDM for Android. In December 2025, many of our users reported the same issue. While installing an MDM app by the QR code method, it is blocked by Play Protect: "This app can request access to sensitive data". A detailed description of the issue is here. As per Play Protect guidelines, this may happen if an app uses sensitive permissions—RECEIVE_SMS, READ_SMS, NOTIFICATION_LISTENER, and ACCESSIBILITY. We removed these permissions in May 2025, and at that time the issue was resolved. Unfortunately the issue re-appeared again in December, and we were unable to determine why Headwind MDM agent is blocked at the enrollment stage. Even removing all permissions from the manifest didn't resolve the issue! Looks like there is an AI which automatically blocks software in an opaque way (by signature or code similarity). Interesting - sideloading and installing the same MDM agent APK on a non-managed device doesn't trigger Google Play block! I'm not talking about the ethics as it was already discussed in another related topic. All I know is that this behavior of Play Protect is a critical threat to our MDM project. Technically, is there a way to bypass Play Protect, for example by adding a parameter in the enrollment QR code? P.S. I already submitted the appeal form. If you have a similar issue, please fill and submit this form, this may speed up the issue resolution.
Device Owner Enrollment Error: “Organization Has Reached Its Usage Limits” Even With Zero Devices
Hi everyone, I’m trying to enroll a fully managed Android device using the Android Management API. I generate an enrollment token, create the QR code, factory reset the device, and start the QR-based provisioning process. Everything works until the Android Device Policy step, where I get the following error: “Since your organization has reached its usage limits, this device can’t be set up.” I am unable to get past this point. Here is what I have already checked: Listing devices through the API returns an empty list. There are no enrolled devices at all. Billing is active on the cloud project and the Android Management API is enabled. Enterprise creation works, policies return correctly, and I can generate enrollment tokens without any issues. The device is correctly factory reset and the QR scan is working as expected. I tested with both a Workspace-based enterprise and a Gmail-based enterprise. The same limit error appears on both, even though both enterprises have zero devices. I moved the cloud project under my organization in Google Cloud to avoid any project-level quota problems. Based on everything I have checked, it appears that the enterprise (or account) has been automatically restricted to a device quota of zero, and the restriction has not lifted even after several days. I would like to understand the following: Is this quota lock normal for new enterprises, and how long does it usually take to lift? Is this quota tied to AMAPI commercial approval? Is it expected that zero devices can be enrolled before approval? Is there any way to request a quota review so that at least one test device can be enrolled? I am building a commercial EMM solution and simply need to test device-owner provisioning on a physical device, but I am currently blocked by this limit. Any guidance from the community or anyone who has dealt with the same situation would be greatly appreciated. Thank you.
Google Play Protect's new policy for custom DPC
Apparently, Google has a new policy that only approved DPCs can be installed through QR Provisioning; otherwise, their installation will be blocked. Link: https://developers.google.com/android/play-protect/warning-dev-guidance#android_enterprise_dpc_enrollment The problem is that I am not able to understand how to apply for DPC approval. I found this page, but still not able to find out where to apply. Your help is appreciated. Thanks
Unable to Add Work Profile on HONOR Magic V5 for Microsoft Intune Enrollment
Dear Android Enterprise Support Team, I am experiencing an issue while attempting to enroll my HONOR Magic V5 device into Microsoft Intune for device management. I just bought the device one week ago, but when I try to add a work profile, I receive the following error message: "Can't add work profile. A work profile can't be added to this HONOR Magic V5. If you have questions, contact your IT admin." This issue is preventing me from completing the enrollment process required by my organization. I have already consulted with my company’s global IT support team, and they confirmed that there is no alternative solution on our side. The only way to resolve this issue is for HONOR to make the HONOR Magic V5 compatible with the Microsoft Intune application and Android Enterprise work profile enrollment. Device Details: Model: HONOR Magic V5 OS Version: Magic OS 9.0.1 Android version: 15 Model: MBH-N49 Error Screenshot: attached as below Could you please advise if this device supports Android Enterprise work profiles or if there are any compatibility limitations? If there is a workaround or firmware update required, kindly provide guidance. Your prompt assistance would be greatly appreciated as this is impacting my ability to comply with company security policies.
Zero-Touch + Intune enrollment fails after Microsoft sign-in (redirects to portal.manager.microsoft.com)
Hi everyone, I’m experiencing an issue during Android Zero-Touch enrollment with Microsoft Intune. The process begins normally and progresses through all the expected steps: 1. Getting your phone ready 2. Checking info 3. “This device belongs to your organisation” 4. Setup your phone 5. Setting up your device 6. “This device isn’t private” 7. Google services 8. Updating device 9. Welcome to Chrome 10. Microsoft sign-in page The problem occurs AFTER I successfully sign in with my work account. Instead of continuing with Android Enterprise (intune) setup, the device opens this URL: **portal.manager.microsoft.com** This page shows “Page not found.” Immediately after that, the device shows: **“Can’t set up device. To finish setup, sign in to your work account.”** At this point the enrollment cannot continue. The device is assigned to a Zero-Touch configuration with the DPC: `com.google.android.apps.work.clouddpc` We also have a JSON configuration supplied from the Intune portal. Has anyone seen this behaviour before where enrollment fails right after Microsoft authentication and redirects to an incorrect URL? Is this likely related to the Zero-Touch configuration JSON, the DPC, or a known issue with Intune handover? Any guidance would be greatly appreciated. Thank you!
Common identifier between AMAPI & Require for setup app for validation
We are enrolling devices using AMAPI by generating a QR code with an assigned policy either for work profile or fully managed enrollment. During enrollment, the device prompts for a require for setup app, which, after configuration, returns RESULT_OK, marking the setup as complete and finalizing the device enrollment. Before returning RESULT_OK, To identify the enrolling device, the backend gets the device ID and enterprise ID from the Pub/Sub provisioning notification. The device ID (which matches the GSF ID) is then sent by the require for setup app to the backend for validation. This identifier is also used to enforce enrollment limits based on the enterprise license count. The Issue: Up to Android 14, retrieving the GSF ID was possible. However, in Android 15, it now returns null. Question: Is there an alternative identifier that can be used to identify the enrolling device—one that the backend can retrieve and that the setup app can also access during enrollment? Below is the information we receive from Pub/Sub when a device is enrolled: { "name": [*Hidden for privacy reasons] "managementMode": "PROFILE_OWNER", "state": "PROVISIONING", "enrollmentTime": "2025-04-04T06:17:02.751Z", "lastPolicySyncTime": "2025-04-04T06:17:02.817Z", "softwareInfo": { "androidVersion": "15", "androidDevicePolicyVersionCode": 10323580, "androidDevicePolicyVersionName": "128.32.3 (10323580)", "androidBuildNumber": "AP3A.240905.015.A2", "deviceKernelVersion": "5.15.149-android13-8-00010-gc2e0ba41ba85-ab12040008", "bootloaderVersion": "unknown", "androidBuildTime": "2025-03-11T13:26:50Z", "securityPatchLevel": "2025-03-01", "primaryLanguageCode": "en-IN", "deviceBuildSignature": "c9009d01ebf9f5d0302bc71b2fe9aa9a47a432bba17308a3111b75d7b2143456", "systemUpdateInfo": { "updateStatus": "UP_TO_DATE" } }, "hardwareInfo": { "brand": "Redmi", "hardware": "mt6835", "deviceBasebandVersion": "MOLY.NR17.R1.TC8.PR2.SP.V1.P51,MOLY.NR17.R1.TC8.PR2.SP.V1.P51", "manufacturer": "Xiaomi", "serialNumber": [*Hidden for privacy reasons] "model": "23124RN87I", "enterpriseSpecificId": [*Hidden for privacy reasons] }, "policyName": [*Hidden for privacy reasons] "memoryInfo": { "totalRam": "5865836544", "totalInternalStorage": "806965248" }, "userName": [*Hidden for privacy reasons] "enrollmentTokenName": [*Hidden for privacy reasons] "securityPosture": { }, "ownership": "PERSONALLY_OWNED" } *Updated by Community admin - removed due to privacy reasons 4 April
