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
Upgrade to a managed Google domain fails with "Your account wasn't created"
Unable to complete the upgrade to google domain for Google managed play account initiated from Microsoft Intune. User has a first and last name, it is Entra managed, Intune licensed, and it has an mailbox active. User has organization read and update permissions on Intune side. The Upgrade flow is initiated and it ends up failing in the final steps where the Google admin account is being created : I have tested successfully on other tenants, this is the only one where I am seeing this failure. Any hints to troubleshoot this will be appreciated.
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.
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?
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, MarkoInitial 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?Android 15 - Cannot set default password app
We use Microsoft Intune to manage devices. For the devices which have upgraded to Android 15, the end users can no longer select Microsoft Authenticator as their default application for auto filling passwords. I cannot find any settings in Intune to allow it. All devices are fully managed corporate owned devices. The devices are all Google Pixel 8 or 8a devices. Is this a bug in 15 or am I missing something?
