Recent discussions
My application was rejected
Hello, good afternoon everyone. I'm writing to this forum to ask for help. A few weeks ago, I applied for the EMM and Enterprise Android Partner program. My application was rejected without any explanation in the emails. I'd like to know the requirements to join the program. We are a development company based in Guatemala and the United States (and soon in Mexico and Colombia), as we currently have a client requesting an MDM system for their Android device retail store. This is our first time applying to this program so we can offer our services to this client and any future clients who might be interested. If you could send me the program requirements so I can apply correctly, I would be very grateful. Have a good afternoon. Greetings from Guatemala.
zero-touch; Owner credentials lost
Hi, we have a few Zebra devices registered for zero-touch and plan to use zero-touch for all regular mobile devices. the registration and all existing accounts linked to it was created by team members that are unfortunately no longer with us. i do have access to one account with administrator permissions but the account with the "owner" permission was not handed over and credentials are basically lost. which steps are necessary to recover ownership?
Issues with use of Personal Digital Certificates on Android Devices Managed via Google Workspace MDM
Hello everyone, I’m reaching out from my company as we have encountered an issue with the installation and use of personal digital certificates issued by FNMT (Spain) on Android devices managed through Google Workspace MDM. The certificates install correctly, but apps that should use them (e.g., for Wi-Fi authentication or access to internal services) do not detect or recognize these certificates. We have tested on unmanaged Android devices, and the certificates work fine there, so it seems related to Google Workspace MDM management. We’ve confirmed with the certification authority (FNMT) that their certificates comply with standards. Google mentioned that MDM should not block certificates unless there is a policy configured to do so. However, this problem seems to persist regardless. Additionally, other companies have reported similar issues with personal certificates issued by different certification authorities, which suggests a possible systemic incompatibility or configuration issue within the Google Workspace MDM environment affecting the proper functioning of these certificates. Has anyone else experienced this? Are there known workarounds or configuration tips that could help? Any insights or advice would be greatly appreciated. Thanks in advance! Francisco
Help Needed: Re-registering MDM After Already Signed Up Error
Hello Android Enterprise Community, I’m trying to set up my MDM, but I keep encountering the following error: "Someone at testmdm.xyz has already signed up." I have previously attempted to remove the Android Enterprise enrollment from my domain, unlinked the MDM, and followed all standard steps. However, I am unable to re-register the MDM, and my attempts to enroll devices fail. I would greatly appreciate guidance on: How to fully clear any previous Android Enterprise enrollment associated with my domain Steps to re-register an MDM successfully Any best practices or troubleshooting tips to avoid this issue in the future Thank you in advance for your help. Any advice from experienced admins or Google support is highly welcome. jasonbayton Best regards, Khaled[Community poll] What are your thoughts on…Android Enterprise training?
Hello everyone, I hope you are doing well. Last year we asked you here in the community about your interest in a possible security certification, we had a great response (and we will be providing an update on this soon). We wanted to expand this further to gauge your interest in providing Android Enterprise training modules. While some of you might be familiar with our Partner Academy resources, this would be specifically looking at training content tailored to your needs as a customer. It would be great to hear you thoughts. Please take a moment to answer the short poll below (or click here to view the form in separate tab). If you have any additional thoughts/details you'd like to share, please add a comment in this thread. Massive thank you for your time and we look forward to hearing what you think. Lizzie Loading…
Custom DPC app being blocked by google play services
Hi We have a custom MDM app which was built to enroll android devices with Device Owner. We have a backend which serves the configuration requires to install/block apps and settings. We are not using Android official management APIs, A few days ago we received a google play protect update on some of our devices and now whenever we try to enroll the devices using QR code enrollment it gets blocked by google play protect. Please help us understand what is required to bypass this so that we can continue to use our custom MDM app. thanks!
How to view and remove enrolled devices, and how quotas are applied
We are developing a solution using Android Management. While enrolling a fully managed device, provisioning now fails with: - "Can't set up device" - "Since your organization reached its usage limits, this device can't be set up." This did not occur until yesterday. We are trying to determine whether this quota limit is enforced by the Android Management API (EMM side) or by Google Workspace when connecting to a third‑party EMM. If the limit is on the EMM side, is the quota granted per project? We have two Google Cloud projects using the Android Management API; the issue is only affecting the newer project. Questions: 1) Where can we monitor quota usage for Android Management? 2) If we have reached a quota, is there a way to remove previously enrolled test devices, and would that resolve the issue? 3) Where can we find detailed information about quotas and currently enrolled devices?
Intermittent QR Code Provisioning Failures with Identical Source Code
I am experiencing inconsistent behavior with QR code provisioning for Android Enterprise and am seeking guidance from the community. The Issue: QR code provisioning works intermittently, but the failure pattern is inconsistent. A provisioning QR code generated from a specific APK build will work reliably. However, subsequent builds of the exact same source code from the same Android Studio project will sometimes fail. The device displays a generic "Contact your IT admin" error. What I've Verified: The APK is properly signed and the checksum in the QR code is correct. The server delivers the APK with the correct application/vnd.android.package-archive MIME type. The DeviceAdminReceiver is correctly declared in the manifest and the associated XML resource exists. The package name and component name in the QR code are 100% accurate. Comparing a "working" APK and a "failing" APK in APK Analyzer shows no differences in the core components (package name, receivers, resources). Question: Has anyone else encountered this? Are there known issues with Android's provisioning service being sensitive to certain aspects of the APK build output that are not related to the core functionality or signature? Any insight into how to achieve consistent, reproducible builds for provisioning would be greatly appreciated.
SCEP Certificate Fails with Multiple Root CAs on COPE/COBO (Works on BYOD)
Hi everyone, We're running into a certificate issue with our Android Enterprise deployment and hoping someone here has encountered something similar or can point us in the right direction. We're using Microsoft Intune as our MDM solution with COPE and COBO enrolled devices. This affects all Android devices regardless of manufacturer, including Google Pixel devices running Android 16 with the latest security patch. The devices use SCEP certificates for Wi-Fi authentication. In early September, we rolled out new Root CAs via Intune. These new Root CAs are used for creating SCEP profiles for Wi-Fi authentication. The devices now have both the old, still valid Root CA and the new Root CA installed. The problem occurs when a device tries to obtain a new SCEP certificate issued by the new Root CA. In this case, the Android device attempts to verify the certificate chain using the old Root CA, which fails because the certificate was issued by the new Root CA. As soon as the old Root CA is removed from the device via MDM, the certificate verification works as expected. Interestingly, the entire process works without any problems on Android devices with personal enrollment (BYOD). We've tested creating a new SCEP profile, but unfortunately that didn't help. Only removing the old Root CA solved the problem. The issue now also occurs with BYOD devices as well. Has anyone dealt with a similar situation during a Root CA migration on Android Enterprise devices? We're trying to understand why COPE and COBO devices behave differently than BYOD devices in this scenario, and whether there's a configuration we're missing that would allow both Root CAs to coexist properly during our transition period. Thanks in advance for any help you can provide.
