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
Tenant has been unbound from Google Play console (Intune)
Hey @Community, we have a strange issue with out MDM (Intune) - It seems like, the link between Intune and Google has broken. Trying to enroll new devices are failing with "Invalid code". Trying to add new applications via "Managed Google Play" fails also with the message "Tenant has been unbound from Google Play console". Intune-Support says, that we need to contact Google, but there is no option for creating a case. So we decided to write you here (and hopefully you can help us ;) ). We still have the access to the used Google-Account.Zero Touch Enrollment Network Specifications
Hello! I'm looking for information regarding the network specifications for the Zero Touch Enrollment as well as any phone-home network requests. Are there any logs we can pull from ZTE or the Android device during enrollment? The reason I'm asking: We have thousands of devices that have been enrolled in SOTI MobiControl over the last few years, and about 1000 of these were enrolled via ZTE. We've had no issues with this until early March. I can't find a rhyme or reason for this, but certain devices that were successfully enrolled, configured by an MDM, QC'd, boxed up, shipped to the end user, and then powered on will get the message below before the eSIM is activated. These are Honeywell CT47 devices with dual SIM cards (1 physical Nano SIM and 1 eSIM). The device above was added to ZTE using the IMEI number over a month ago and was successfully enrolled, but when powered on later and connected to Wi-Fi, it reset itself before the eSIM could be activated. This issue is only happening to devices that are factory reset while on-site and connected to the Wi-Fi only. My best guess is that the Wi-Fi network is blocking something during the enrollment process, as this reset issue is not happening on devices that have been enrolled and working for months. Thanks for your time!DPC Extras issues
Hello, I hope you're doing well. I'm reaching out for assistance on an issue I'm experiencing with DPC extras on ZTE devices. Is there a method to implement DPC extras without using a QR code? It appears that even when configuring ZTE with DPC extras, some functionalities do not activate. Additionally, several design elements seem less than optimal. For instance, if you do not use a QR code before selecting the language—which, ideally, should be sourced from the DPC—there's an option presented to transfer data from another device. This option seems inappropriate for a company-owned device. Could this be improved? The next screen prompts a WiFi connection. Using a QR code skips this step, but users still need to manually confirm the WiFi connection. Could this be streamlined? Is it possible to enroll a device as an admin, reset it, and have the DPC extras from the QR code persist on the device until it connects to WiFi and verifies its management status? It seems everyone is adding devices to ZTE for security reasons, particularly for stolen devices, yet the reliance on QR codes adds unnecessary complexity. Could this process be made more user-friendly?
Bug? G-board removes additional languages post BYOD Enrollment?
We noticed a strange behaviour, If G-board has additional languages added apart from English like Polish or German, post enrolling into a work profile, the additional languages disappear from the keyboard. I was able to reproduce with Intune, WorkspaceOne and even TestDPC app. This is true even if no Device Restrictions are applied. It seems like a bug. Has anyone else seen this issue?
Assistance with Domain Already Linked to Android Enterprise
hello, I attempted to set up Android Enterprise using a Gmail account, but received a message saying, "This domain name has already been used." Could you please help me verify which Android Enterprise account is currently associated with our domain and advise on how I can proceed?Restoring Data on a Fully Managed (Device Owner) Android Device During Enrollment
Hello everyone, I’m testing the setup (enrollment) of a Device Owner / Fully Managed Android device, and I’ve run into a question about restoring data. When setting up a personal Android device, you typically get the option to sign in with a Google account and restore apps/data from a backup. However, when I try this on my test device with the fully managed (Device Owner) enrollment flow, it goes straight into the MDM provisioning process. I don’t see the Google sign-in page or any option to restore data from my Google backup. My questions: Is this the expected behaviour for Device Owner (fully managed) setups? Are there any official guides or best practices for restoring user data in this scenario (if supported)? Thanks in advance for any guidance or documentation links!
