Unable to upload bulk CSV file to ZeroTouch
Hi Team, Is there currently an issue uploading a bulk .csv file to ZeroTouch? It's giving me an error. See below. Steps below: I downloaded the sample .csv file then updated it with my data, then uploading it again to the portal as is without changing the name or file extension as seeing above, yet its giving me an error. This was working not long ago, just wondering if there is currently an issue. Thanks
No accounts found Zero touch
as per : ZTE Portal - no account found | Android Enterprise and ChromeOS Customer Communities - 4093 I'm an admin of a Google workspace instance, let's call it Acme, LLC. This is Google Workspace Business Plus I'm an admin (not owner) of a Android Zero Touch instance, with the ability to make changes to: Configs Devices Users Resellers, etc I've logged into Workspace.google.com for Acme, Inc. Gone to Devices, Mobile & Endpoints, Settings, Enrollment, Manage Zero Touch devices, Link, log in using AZTE user and get the rather lovely: MDM is set to advanced, by the way
Zero Touch phones randomly wipe themselves
Hello, We are a large corporate and mostly use Samsung phones as Android devices. Enrolment is being done via ZT portal to a default profile which is Corporate Owned Work Profile provided via Microsoft Intune. We are noticing an increased amount of cases where users set up their phones (no QR code, no text token) with default configuration added using DPC extras and within first few hours they would reset to a factory default state without any notice. This has become a real issue as it is affecting more and more people. Devices enrolled without ZT do not suffer from this issue, even though they are using the exact same enrolment profile. I saw many posts like this here and elsewhere on the internet, but no actual solution. What is the problem here and is it being actively looked by Google?Android 15 Setup Wizard loops at âAccept Google Servicesâ on Lenovo Tab M11 (TB311FU)
Hi all, I'm running into a blocking issue provisioning brand-new (and factory-reset) Lenovo Tab M11 - TB311FU devices on Android 15 with Android Management API (fully managed / dedicated, kiosk). On Android 14 everything worked fine with the exact same policy and enrollment flow. The issue only started after updating to Android 15. (this is my test device, i constantly factory reset it) Expected behavior: Standard QR (6-tap) provisioning to proceed past the âAccept Google Servicesâ screen, install Android Device Policy, enroll to my enterprise, and apply the kiosk policy, install app, and done. What happens instead: After Wi-Fi and scanning the AMAPI QR token, Setup Wizard reaches âAccept Google Servicesâ. Tapping Accept shows a spinner, then it returns to the same screen (loop). I simply cannot get past this point. If I reboot at this point, on the very first Welcome screen the device sometimes becomes unresponsive (neither 6-tap nor âNextâ reacts) until I factory reset again. Is there a known Android 15 Setup Wizard issue that can cause a loop at âAccept Google Servicesâ on Lenovo TB311FU? Any workarounds you'd recommend to get past the acceptance loop? When factory resetting, and setting up the tablet without scanning the qr code, i get past the Google Services no problem. When i install via qr-code on new fresh never used before tablets, that come pre-installed with Android 14, i don't have any issues. Same policy, same everything... except the Android version. Thanks in advance! /B
Android Enterprise Partner Application/Quota Status
Hi, We own and manage an asset management solution used by various clients. Recently (in the last 12 months) we have implemented an MDM/EMM type of solution that uses the Android Management API to enrol/register devices and assist clients with their asset management processes and managing risk through the Android Management API. Now, from an Android Management API perspective, we understand the permissible usage policies and believe we do comply with the requirement. When we originally started the endeavour, the quota on how many device can be registered was a default of 500 devices. We recently noted when some clients try to enrol/register devices, that during the set up process on their devices, that it states that they have reached the usage capacity limits. When we checked the project(s) associated with the clients, most have between 200 - 380 devices enrolled/registered which is below the 500 device qouta. More recently, we noted that the Android Management API permissible usage policies were changed/updated on 29 October 2025 from a default of 500 devices to having to request an initial quota of 500. This means that that enterprises or projects we have recently set up would fail. We submit a request for a quota increase on earlier projects and a request for an initial quota on a new project. This was more than a week, or 7 working days, ago. We also submit an application to become and Android Enterprise Partner on the 12th of November 2025 which we received a response with additional questions about two days later which we responded to promptly. The challenge here is managing client expectations and frustrations in not being able to enroll/register and additional devices, with one client looking to enrol/register over 5000 devices and another prospective client having over 15000 devices. Is there any way we can see the progress on the quota increase/initial quota requests and progress of the partner application or whether there is any other questions or concerns we can remediate to move forward? Its been a challenging week trying to manage our frustrated clients and really want to use the Android Management API and Android Enterprise much more in the future but the limitations are prohibiting us from doing so. Any assistance or perhaps someone we can contact would be appreciated.WPCO Enrollment into Google Workspace using Zero Touch
Hi there! I am implementing Zero Touch enrollment for our newly purchased Android devices. It is working well and our testing devices end up in "Fully Managed" state after enrollment. I have been wondering if the enrollment could be adjusted so the device ends up in "Work profile on corporate-owned" (WPCO) state instead. I have done a little research and Android spec should allow a device to end up in WPCO state after it is enrolled via Zero Touch. Is this end result achievable with following combination? Device: Samsung with Android 14 Enrollment: Zero Touch during device setup EMM: Google Workspace Google Workspace AFAIK does not have any switch for this in UI. Could the management mode be configured during Zero Touch by using DPC extras set in Zero Touch portal? Developer oriented documentation suggests this is governed by EXTRA_PROVISIONING_MODE. I have tried following Custom Configurations in Google Zero Touch portal so far (all targeting com.google.android.apps.work.clouddpc) : { "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"mycompany.com\"]", "PROVISIONING_MODE": "MANAGED_PROFILE" } } and { "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"company.com\"]" }, "android.app.extra.PROVISIONING_MODE": "2" } and { "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "<SIG-CHECK>", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_ROLE_HOLDER_SIGNATURE_CHECKSUM": "<SIG-CHECK>", "android.app.extra.PROVISIONING_ROLE_HOLDER_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "<TOKEN>", "com.google.android.apps.work.clouddpc.EXTRA_FORCED_DOMAINS": "[\"company.com\"]", "PROVISIONING_MODE": "MANAGED_PROFILE" } } In all three case the devices goes trough Zero Touch enrollment. Device Policy is installed. User is required to log in with a Google Account with company.com account. The device ended up in "Fully Managed" state in all three cases...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.
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.
