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?
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.
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
Initial 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?
Outlook 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! Daniel2025 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 🤩]
GBoard - 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. // Magnus
