Seeing spike in HARDWARE_BACKED_EVALUATION_FAILED for Android 16 devices.
We are seeing a spike in HARDWARE_BACKED_EVALUATION_FAILED in https://developers.google.com/android/management/reference/rest/v1/enterprises.devices#securityrisk field in AMA Device response. We are seeing this mostly in the Android 16 customers and for some users it went away without any change on their side. So it does not seem anything wrong with the devices and seems random. Anyone else facing this with AMA or play integrity?
AMAPI Provisioning Stuck on Registration Screen
I'm facing an issue with AMAPI device provisioning. I created a policy, generated a token, built a QR code, and scanned it on a tablet. The device successfully got added under my enterprise (I verified this using the API). However, for the past 2–3 days, while the QR code scanning works, the device gets stuck on the registration screen with a large circular loader for at least 15–20 minutes. After that, I get an option to factory reset the device. Even after the failure message, when I run my script to check for new devices, I can see that the failed device appears under my enterprise. The device's state from the AMAPI response is PROVISIONING. Despite being stuck on the failed screen, I tested sending commands to the device (like reboot and wipe), and surprisingly, they work. This has left me very confused if the device setup failed, how are commands still working? Initially, I thought it might be a device-specific issue, but I tried it on another device (which was never enrolled before), and I’m seeing the same behavior. For reference, here's the structure of the QR payload I’m using: { "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "20Characters" }, "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver", "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup", "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg" }
Android Enterprise BYOD not honoring auto-connect setting for WiFi
Hi, We have an issue in our tenant with BYOD device enrollment (Personally owned with Work Profile). We use Intune as EMM. We want to push a WiFi policy to our devices but we do not want to preconfigure auto-connection for our users. Our users must manually connect to the network. The problem is that this setting is not supported for BYOD in Intune, so we have no control over it. In addition, the default behaviour of the devices (tested in Realme, Xiaomi, Nokia, Google, Samsung phones) is that autoconnect is enabled by default. Even if the user disables it, next Intune sync enables it back. Finally, I checked the policy via graph API and I see that: "connectAutomatically": false, "connectWhenNetworkNameIsHidden": false, "wiFiSecurityType": "wpaEnterprise", Is this setting not honored by the OS? Is there anything we can do about it?Intune COPE Device - Google Calendar crashes
Hello everyone, We have the problem that when I want to make the Google Calendar app available on a COPE device, it crashes after the welcome screen with the message "action not allowed". On Work Profile Only/BYOD it works without any problems. Are you aware of this problem? Could this be related to Intune automatically/default blocking the Google accounts in COPE? Thanks, Regards, Daniel
unable to enroll the Samsung S25 ultra into Intune as BYOD.
Hi Team, We are unable to enroll the Samsung S25 Ultra devices in Intune as BYOD. We are getting the "Can't add work profile " error during the enrollment process. So far we received couple of requests for same issue and the affected users count is increasing day by day. We have reached to Microsoft team as well, they suggested to check with Samsung team.
Common identifier between AMAPI & Require for setup app for validation
We are enrolling devices using AMAPI by generating a QR code with an assigned policy either for work profile or fully managed enrollment. During enrollment, the device prompts for a require for setup app, which, after configuration, returns RESULT_OK, marking the setup as complete and finalizing the device enrollment. Before returning RESULT_OK, To identify the enrolling device, the backend gets the device ID and enterprise ID from the Pub/Sub provisioning notification. The device ID (which matches the GSF ID) is then sent by the require for setup app to the backend for validation. This identifier is also used to enforce enrollment limits based on the enterprise license count. The Issue: Up to Android 14, retrieving the GSF ID was possible. However, in Android 15, it now returns null. Question: Is there an alternative identifier that can be used to identify the enrolling device—one that the backend can retrieve and that the setup app can also access during enrollment? Below is the information we receive from Pub/Sub when a device is enrolled: { "name": [*Hidden for privacy reasons] "managementMode": "PROFILE_OWNER", "state": "PROVISIONING", "enrollmentTime": "2025-04-04T06:17:02.751Z", "lastPolicySyncTime": "2025-04-04T06:17:02.817Z", "softwareInfo": { "androidVersion": "15", "androidDevicePolicyVersionCode": 10323580, "androidDevicePolicyVersionName": "128.32.3 (10323580)", "androidBuildNumber": "AP3A.240905.015.A2", "deviceKernelVersion": "5.15.149-android13-8-00010-gc2e0ba41ba85-ab12040008", "bootloaderVersion": "unknown", "androidBuildTime": "2025-03-11T13:26:50Z", "securityPatchLevel": "2025-03-01", "primaryLanguageCode": "en-IN", "deviceBuildSignature": "c9009d01ebf9f5d0302bc71b2fe9aa9a47a432bba17308a3111b75d7b2143456", "systemUpdateInfo": { "updateStatus": "UP_TO_DATE" } }, "hardwareInfo": { "brand": "Redmi", "hardware": "mt6835", "deviceBasebandVersion": "MOLY.NR17.R1.TC8.PR2.SP.V1.P51,MOLY.NR17.R1.TC8.PR2.SP.V1.P51", "manufacturer": "Xiaomi", "serialNumber": [*Hidden for privacy reasons] "model": "23124RN87I", "enterpriseSpecificId": [*Hidden for privacy reasons] }, "policyName": [*Hidden for privacy reasons] "memoryInfo": { "totalRam": "5865836544", "totalInternalStorage": "806965248" }, "userName": [*Hidden for privacy reasons] "enrollmentTokenName": [*Hidden for privacy reasons] "securityPosture": { }, "ownership": "PERSONALLY_OWNED" } *Updated by Community admin - removed due to privacy reasons 4 April
Managed Google Play private app not available on Corporate-owned devices with work profile
Hi community, I'm encountering a strange issue and could use some guidance. A Google developer account released an app to Managed Google Play (so it's automatically private and not available on the public store) and entered our organization ID in the appropriate field. We can find the app on the iframe in our MDM (Microsoft Intune in this case), select it, and assign it to groups. Everything looks good: BYOD deployments (Personally-owned devices with work profiles) can install the app from the Managed Google Play store. However, COPE devices (Corporate-owned devices with work profiles) cannot search for it, and it's also not visible in the app collections we've created. Could there be a setting in the Google developer account's store listing that prevents availability for COPE devices? I've exhausted all options in Intune, including multiple store syncs, with no success. Intune is telling me, that the App is available to install on the specific COPE devices, but it does simply no appear. The only thing left to check is the Google developer account that released the app for us. Has anyone else experienced this issue? Any hints or suggestions would be greatly appreciated. Thanks! Walter
