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
Fido2 key and their issues using them on Android
First, do Android support using Fido2 keys on Android? Yes, it does support both using bluetooth, NFC and USB authentication. For reference: https://developers.google.com/identity/fido/android/native-apps But does it mean that it is straight forward to use it in a enterprise environment without hiccups? No, the support lacks many features that both Windows and iOS has supported for long time. If I buy a modern Fido2 with OTP support, will it work straight out of the box for using the USB? No, you need to disable the OTP support first. Here is how you can do that from yubikey manager, this works for Yubikey. Other vendors might have something similar. But for Fido2 keys without OTP support, it should work out of the box for USB-C, like Google titan. Why this happens, dont know. Can we use NFC for Entra ID authentication like we can on Windows and iOS? No. Android does not currently support CTAP2 for NFC, only for USB-C input. CTAP1 (FIDO U2F) supports certificate based authentication, but CTAP supports user verification with PIN and biometrics. Entra ID requires UV (user verification) before accepting login. As far as I know, there is also support for bluetooth. But I dont have any fido2 keys that support bluetooth yet. So why does this matter? With Android you can have shared devices with secure login for multiple users with a single log in for all supported apps, auto log off and many other possibilities. https://learn.microsoft.com/en-us/entra/identity-platform/msal-shared-devices Other sources/discussions: https://www.reddit.com/r/yubikey/comments/1oncuh2/whats_the_point_of_nfc_on_android/ https://www.reddit.com/r/yubikey/comments/13tlzoc/fido2_inconsistent_across_windowsandroid/ https://fidoalliance.org/specifications/
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.
Factory reset protection (FRP) or enterprise factory reset protection (EFRP).
Hello, since Android 15 we have encountered a huge problem with Corporate phones (enrolled in BYOD) for which users leave the company without deleting their account. We therefore found ourselves with locked phones that we cannot return to our reseller (who asks us for a large sum to unlock them) so I come to you to find a solution or a tool available to the technical teams to clean up. We are open to any advice or helpCommon 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
Workprofile creation failure using CUSTOM DPC
We use a custom DPC to create work profiles. On certain devices, profile creation fails with errors like STORAGE_UNAVAILABLE or work profile already exists. From bug reports, we can confirm the failure cause, but is there a way to detect these conditions directly in our app and handle them gracefully?”
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?
Android Enterprise Recommended Devices
Hello, Not sure if everyone uses this site or not (Android Business Device Solutions Directory - Android Enterprise) We provide this link to our end users to help them make a decisions on which device they purchase, we are a BYOD shop. It would be very nice if there was a way to export this list.
