Enrolment

249 Topics

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.
Solved
rpnexa
12 hours ago Place General discussions
315Views
0likes
11Comments
Not able to set wallpaper on managed chromebook using the Policy API from GWS
Hello Team, While testing the wallpaper management functionality using the Chrome Policy API, we observed that the wallpaper does not get applied on managed ChromeOS devices, even though the API calls return a successful response. When we upload the wallpaper image using the uploadPolicyFile endpoint, it successfully returns a valid downloadUri.and wallpaper gets applied on device. However, when we attempt to apply this uploaded image as a wallpaper using the Policy API, the request completes successfully (200 OK), but the wallpaper does not apply on the chromebook device. We’d appreciate your help confirming the following points: Are there any additional parameters, permissions, or policy fields required for either of the following? chrome.users.Wallpaper chrome.devices.managedguest.Wallpaper Are there any known propagation delays, caching behaviors, or policy refresh constraints that could affect wallpaper deployment on managed devices?
Solved
VishalSanap08
15 hours ago Place General discussions
75Views
0likes
3Comments
From setup to scale: your experiences with ChromeOS automatic enrollment
Hi everyone, Automatic enrollment can be a real game changer when you’re deploying at scale — whether that’s ChromeOS zero-touch enrollment for new devices or ChromeOS Flex remote enrollment for existing fleets. I’d love to hear how it’s been working for you in the real world: What did your rollout look like (drop-ship to users, office-based, hybrid, global)? What’s one tip or best practice you’d share with someone setting up their next automatic enrollment deployment? If you’ve used both ChromeOS zero-touch and ChromeOS Flex, what factors usually influence your decision in practice? If useful, we’ve got a great community guide on ChromeOS enrollment essentials and an informative ChromeOS Flex case study that’s worth a read too! Looking forward to learning from your experiences 👀 Speak soon, Rafa
Rafa
2 days ago Place General discussions
15Views
0likes
0Comments
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
Solved
rPoyo
4 days ago Place General discussions
687Views
1like
17Comments
Device financing at scale (10,000+ devices): compliant “restricted mode” on delinquency using Android Enterprise (Device Owner)
Hi everyone, I’m building an Android Enterprise device management solution and I want to keep everything fully compliant (Android Enterprise + Google Play policies). Use case: a company provides company-owned devices to customers under a leasing / device financing contract. We need to manage this at scale (10,000+ devices) across multiple customers/tenants. If a customer becomes delinquent, the company needs a temporary restricted mode (e.g., kiosk/limited access) until the account is back in good standing — with clear user notice, grace period, and contractual consent. What we want to control at scale: enrollment, policy assignment, app allow/deny lists, kiosk/lock task mode, updates, compliance reporting, and remote actions aligned with Android Enterprise best practices. Questions: Is this type of “restricted mode for delinquency” considered acceptable in the Android Enterprise ecosystem when devices are Company-Owned (Device Owner) and the policy is transparent/contractual? For 10,000+ devices, what is the recommended architecture: Android Management API (AMAPI) policies only, or a custom DPC (and why)? For distribution, is the safest path a managed Google Play private app per enterprise/tenant, or another approved approach for large-scale deployments? Any best practices to avoid being flagged by Play Protect / Play policy reviews for legitimate enterprise enforcement features (kiosk, app restrictions, device restrictions), especially at this scale? I’m not looking to bypass security or do anything hidden; the goal is a compliant enterprise solution. Thanks for any guidance or official documentation links.
Solved
gustavomartinez
4 days ago Place General discussions
69Views
0likes
7Comments
Playstore empty after enrollment
Hello, For the past two weeks, we have been experiencing issues during the enrollment of some of our devices. After enrollment, the Play Store is empty and no apps will install. This is a problem that has occurred before, and a fix was provided by Google (link). A case is currently open between our MDM vendor, Ivanti, and Google: link. (issue tracker 399818918) Are other people experiencing this issue? Our vendor has indicated that at least one other customer is currently facing the same problem. Best regards
Solved
Flo
4 days ago Place General discussions
106Views
2likes
4Comments
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
Solved
Bharat
9 days ago Place General discussions
500Views
2likes
4Comments
Issue: Play Protect Blocks DPC Installation During QR Provisioning on Android 14 / One UI 6.1
Hello, We use QR code provisioning to install our custom Device Policy Controller (DPC) app from a custom download URL (not Google Play). The exact same APK + QR configuration: Works on: Samsung Galaxy S20 — Android 13 / One UI 5.0 Blocked on: Samsung Galaxy S21 — Android 14 / One UI 6.1 Play Protect stops installation with the message: "App blocked to protect your device. This app can request access to sensitive data. This can increase the risk of identity theft or financial fraud." Provisioning QR: { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "<DeviceAdmin component>", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM": "<Package checksum>", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "<S3 bucket url>", "android.app.extra.PROVISIONING_LOCALE": "en_US", "android.app.extra.PROVISIONING_TIME_ZONE": "Europe/Helsinki", "android.app.extra.PROVISIONING_LEAVE_ALL_SYSTEM_APPS_ENABLED": false, "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME": "<Package name>", "android.app.extra.PROVISIONING_WIFI_HIDDEN": true, "android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE": "WPA", "android.app.extra.PROVISIONING_WIFI_SSID": "<WiFi SSID>", "android.app.extra.PROVISIONING_WIFI_PASSWORD": "<WiFi Password>" } Questions: Question 1: What changed in Android 14 or One UI 6.1 related to: - Sideloading DPCs during provisioning - Play Protect enforcement during QR setup Question 2: What is the new required approach to ensure the DPC installation is allowed? (e.g., signature checksum requirement, Play signing, allow list, new provisioning extras) Question 3: Is there updated documentation that describes the new DPC provisioning security rules? We need to understand the change and how to properly support Android 14+ devices in enterprise deployments. Thank you!
gekatz-mce
16 days ago Place General discussions
62Views
0likes
0Comments
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.
virenbisht1995
17 days ago Place General discussions
124Views
0likes
3Comments
Enable third-party Android mobile management
Hey Android Enterprise community, I'm trying to understand what the "Enable third-party Android mobile management" checkbox in Google Admin does. How does this affect situations where multiple Android Enterprises are bound to multiple EMM solutions? Will both Android Enterprise continue working if they are bound to different EMM solutions, even if only one is selected on the screen above? If I use the Enrollment token link method to provision a device and have no users in my Google Workspace, will switching the EMM provider in the dropdown below the checkbox have any effect? Also, does Authenticate Using Google affect provisioning if there are no users in Google Workspace? Thanks, Marko
Solved
markolisica
25 days ago Place General discussions
170Views
0likes
6Comments