Recent discussions
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?sharmilashree6 hours agoLevel 1.6: Donut2Views0likes0CommentsEnable 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, MarkoSolvedmarkolisica6 hours agoLevel 1.6: Donut94Views0likes6CommentsPlay 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 regardsrPoyo9 hours agoLevel 1.5: Cupcake285Views1like7CommentsDevice 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.Solvedrpnexa10 hours agoLevel 1.5: Cupcake139Views0likes5CommentsInitial Android Management API device limit is 0 after enterprise creation – how can we test during quota review period?
Hello Android Enterprise Community, We are currently building a custom MDM solution based on Android Management API and have completed the full end-to-end workflow, including enterprise creation, policy creation and assignment, enrollment token (QR) generation, device command lifecycle testing, Pub/Sub notifications, and admin panel and backend integration. The enterprise is created successfully, however the initial device limit shows as 0, so we are unable to enroll any test devices at the moment. We have already submitted the Android Management API initial quota request form with a detailed business use case and supporting architecture documentation. Due to the holiday period from December 19 to January 5, we understand there may be delays in review. I would like to ask: Is there any recommended way to test device enrollment while the initial quota request is under review? Is a temporary or development test quota ever enabled for validation purposes? Are there any best practices to validate an MDM implementation before quota approval? We want to ensure our implementation fully follows Android Enterprise and Android Management API best practices. Any guidance from the community or Google team would be greatly appreciated. We are currently building a custom MDM solution based on Android Management API and have completed the full end-to-end workflow, including: Enterprise creation using Android Management API Policy creation and assignment Enrollment token (QR) generation Device command lifecycle (lock, wipe, compliance) Pub/Sub notifications for device status updates Admin panel + backend integration The enterprise is created successfully, however the initial device limit shows as 0, so we’re unable to enroll any test devices at the moment. We have already submitted the Android Management API initial quota request form (500 devices) with detailed business use case and supporting architecture documentation. Since there is a holiday period (Dec 19 – Jan 5), we understand review responses may be delayed. Questions Is there any recommended way to test device enrollment while the initial quota request is under review? Is a temporary test quota ever enabled for development or internal validation? Are there any best practices to validate an MDM implementation before quota approval?nishant350910 hours agoLevel 1.5: Cupcake28Views0likes2CommentsOutlook and Teams with PSTN calling in work profile
Hi today we raised a case with Microsoft for a specific work profile issue with their current Outlook and MS Teams implementation. I wanted to share this here, maybe there are some other customers/admins facing this issue. Our org started to move from Cisco to MS Teams PSTN calling some month ago and everything was fine, but I assume an update to either Outlook or Teams app was published and the issue started. Scenario: COPE or BYOD MS Teams and MS Outlook in work profile MS Teams has a PSTN line configured (either mobile or landline) Open Outlook, search for any contact and try to start a call to a mobile or desk number. The OS does not ask whether you like to use the phone on personal profile (as it did the last couple of years 😅) - it will hand over the call request to MS teams! You cannot decide to make the phone call with your Phone app :-( This breaks almost all use cases for our users. Even worse: A phone number like +49 123 828282 is transfered to MS teams app in a broken format and the call is made to +492492012320828282 💥😔 Compared to Google contacts in the work profile: The app is always handling the call request to the phone app on the personal profile and incorporate the MS Teams app. 🤔 Anyone else here in the community experiencing this issue? Thanks! Danielweberda12 hours agoLevel 2.2: Froyo110Views1like7Comments2025 Community Highlights: Thank you!
Hello everyone! As we look back on a fantastic year, we wanted to say a huge thank you. From lively forum debates and problem solving to in-person meetups; your energy, collaboration and expertise has made this community more vibrant than ever. To celebrate, we've gathered some of the best moments into one recap: A special thanks to our most active contributors: Moombas , Michel, jasonbayton, Kris, Yann_ROLAND, turquet, Alex_Muc, mattdermody, BenMcc, jarmo_akkanen, Rakib, Flo, jeremy, westd, Magcho, davidtse916, weberda Since we couldn't fit everything in, please share your own highlights below! (And, if you have 5 minutes, we would love to get your feedback on the community programs in this short community survey.) With 2026 already heating up with lots of exciting things, we look forward to driving the future of this community together. Thanks for a great year and we wish you a very happy festive season filled with food, fun and rest. AE Community Team [P.S - shoutout to Rose for creating this video 🤩]
Lizzie2 days agoGoogle Community Manager138Views7likes3CommentsIssue 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.virenbisht19952 days agoLevel 1.5: Cupcake26Views0likes1CommentGBoard - Suggestion Strip
Hi, We want to use GBoard on kiosk devices but we aren't able to remove the suggestion strip using managed configurations. All other settings can be configured fine though. The show suggestion strip configuration is set to disabled. But with versions 15.x and 16.x of GBoard it's still visible on the devices. And when checking the setting locally on the device it's still enabled (Disabling manually works fine) Back in version 14.x this configuration worked fine. Anyone else who has experienced the same thing? We've tested this on devices from Samsung, Bluebird, ELO, and Zebra. Android version doesn't seem to have any impact, just the GBoard version. // MagnusMagcho2 days agoLevel 2.0: Eclair387Views0likes19CommentsURGENT: Registration Blocked - "Oops Something went wrong" at DUNS Step (Ghost Application)
Hi Android Enterprise Community Team, We are currently blocked from the partner onboarding process due to a system error that seems to have locked our DUNS number in a "ghost" application state. Here is the chronological sequence of the issue: First Attempt: I initially applied using a generic Gmail address and was correctly declined. Second Attempt (Corporate): I followed the instructions and re-applied using my corporate email. The Error: This second application was marked as "Declined - Further information was requested but not received". However, I never received any email requesting further information (I have checked all Spam/Junk folders multiple times). The process seemingly timed out on the server side without notifying me. Current Blocker: Now, when I try to "Resume Onboarding" or start a fresh application via androidenterprise.dev with my corporate email, the system allows me to log in but throws a generic "Oops Something went wrong" error immediately after I click "Next" on the DUNS Number verification step. It appears my DUNS number is locked inside the previous "declined/closed" application, and the system throws an exception when I try to reuse it. I urgently need the onboarding team to RESET my application status or release my DUNS number so I can submit a fresh, correct form. ( By the way, there is no information why our application was declined. What must we do, we dont know at this point ) Thank you for your assistance. (This post was edited to remove personal information, in compliance with our guidelines)Solvedhmtcr2 days agoLevel 1.5: Cupcake79Views0likes5Comments
Explore other customer resources
Help Center
Explore step-by-step how-to guides.
Solutions Directory
Find solutions and partners.
Website
Discover more about Android's features.