Android Exchange Sync Problems: Contacts and Calendar Not Updating
Hello, I manage a fleet of more than 1,000 Samsung Android devices using Omnissa Workspace One (AirWatch), devices are enrolled in COPE. We use Gmail, Google Calendar, and the native Samsung Contacts app in the work profile, all synchronized through an Exchange ActiveSync connector. Since Wednesday, November 26th, we have been experiencing synchronization issues: - Contacts and calendar events saved on Exchange disappear after some time. - The Calendar app eventually shows an “Unauthorized Action” error and refuses to open. - Gmail continues to sync emails normally. The issue occurs randomly (sometimes after one hour, sometimes longer). Clearing Gmail’s app data and signing in again temporarily resolves the problem, but the issue always comes back. We've tryied uninstalling and reinstalling the app through our MDM but we can only do it user by user and we're not sure about it fixing the issue. We have no means to "rollback" Gmail's version to an older one through our MDM, i've tryied uninstalling recent updates on one of my test phones, it's seems stable for the moment. We noticed that Gmail received an update recently, and a couple of other fleet managers have reported the same problem since that update on Play store's comments. Have you identified any bug or recent change in Gmail that could affect Exchange/ActiveSync synchronization? Thank you in advance for your assistance.
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
Samsung Devices: Can't call from a personal app
Hi everyone we received some reports from our users in the last couple of month that suddently the phone app on COPE devices (Samsung A-series) starts to show "Can't call from a personal app" - Your organisation only allows you to make calls from work apps. Workaround: Reboot the device. For most of the reports this workaround has to take place once and the message is gone forever. A very small amount of devices starts to show this message again after a couple of weeks. Rebooting is resolving the issue again. Any idea of how to prevent this? Even emergency calls are not possible if this error is appearing! Does anyone else have seen this behavior? Raised a case with Samsung today. Thanks! Daniel
REQUIRE_ENTRY flag not working as expected
Hello, I am working on a Mobile Device Management system and just received a bug report about the Require Entry option when resetting a password. Since I set the Require Entry option I expect that the device does not accept any new password changes until I unlocked it at least once with the new credentials. This did not work. I was able to change the password numerous times over the Google API without logging in once. In your documentation here: https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand#ResetPasswordFlag it' s outlined that the flag should force the device to not accept any other password changes over the Google API by admins until the user has entered the new password. REQUIRE_ENTRY Don't allow other admins to change the password again until the user has entered it. I traced the issue through my software and checked all requests. My initial request to Google services looks like this. { "type":"RESET_PASSWORD", "resetPasswordFlags":[ "REQUIRE_ENTRY" ], "newPassword":"111111" } Here is clearly observable that the REQUIRE_ENTRY flag is sent to Google. Furthermore Google also includes the flag in it's response. { "name":"RouterSuccess", "code":200, "message":"OK", "data":{ "name":"enterprises/LC01zoikuz/devices/33c202b53a9b800c/operations/1764168989992", "metadata":{ "@type":"type.googleapis.comgoogle.android.devicemanagement.v1.Command", "type":"RESET_PASSWORD", "createTime":"2025-11-26T14:56:29.992Z", "duration":"600s", "newPassword":"111111", "resetPasswordFlags":[ "REQUIRE_ENTRY" ], "userName":"enterprises/LC01zoikuz/users/107976853558892540833" } } } So I assume that my API calls are working fine. Now I started to look into the adb logs of my device. I sent two reset password commands, one with the Require Entry option enabled and one without. I grepped the logs for "password" as a keyword and compared the results with a tool. Those are the logs of my request with Require Entry enabled: 11-26 10:16:45.367 2770 6955 I SDPLog : Reset password with token for user 0 11-26 10:16:45.654 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:829 - In import_key. 1000, Some("synthetic_password_293151ba28441a0d") 11-26 10:16:45.654 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:832 - synthetic password changed : 1000 11-26 10:16:45.655 1301 8837 I keystore2: system/security/keystore2/src/database.rs:2158 - In store_new_key "synthetic_password_293151ba28441a0d", uid=103, cert=false, cert_chain=false rebound=false 11-26 10:16:45.672 2770 6955 I SyntheticPasswordCrypto: Deleted SP protector key synthetic_password_a94cb138ecf734eb 11-26 10:16:46.071 2770 6955 I PasswordPolicy: isExternalStorageForFailedPasswordsWipeExcluded() : no admin enforce password policy. 11-26 10:16:46.091 6382 24694 I clouddpc: [PolicyUpdaterImpl.java:fromCache:214] From cache started [passwordPolicies, passwordRequirements, encryptionPolicy] forceComplianceReport: false 11-26 10:16:46.091 6382 24694 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: RequestPolicyUpdateFromCache details: [policyKeys=[passwordPolicies, passwordRequirements, encryptionPolicy], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:16:46.091 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyUpdateStarted details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:16:46.092 6382 7741 I clouddpc: [PolicyUpdaterImpl.java:reApplyAndExecuteCompliance:597] Updating policies: [encryptionPolicy, passwordPolicies, passwordRequirements] from cache with force report: false reportApps: false 11-26 10:16:46.096 6382 7741 I clouddpc: [PasswordRequirementsHandler.kt:apply:79] passwordPolicies is set, ignoring passwordRequirements 11-26 10:16:46.112 6382 7741 I clouddpc: [DefaultPasswordUtils.java:setPasswordRelatedPolicy:129] Applying password quality (server enum value): 65536 with scope: 0 11-26 10:16:46.113 6382 7741 I clouddpc: [PasswordPoliciesHandler.kt:applyResetPasswordToken$java_com_google_android_apps_work_clouddpc_base_policy_handlers_handlers:384] Reset password token already active 11-26 10:16:46.153 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyReapplied details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements]] metadata: [isNetworkConnected=true] And these are the logs without Require Entry activated: 11-26 10:17:14.229 2770 4719 I SDPLog : Reset password with token for user 0 11-26 10:17:14.517 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:829 - In import_key. 1000, Some("synthetic_password_89ec84ca283671b1") 11-26 10:17:14.517 1301 8837 I keystore2: system/security/keystore2/src/security_level.rs:832 - synthetic password changed : 1000 11-26 10:17:14.518 1301 8837 I keystore2: system/security/keystore2/src/database.rs:2158 - In store_new_key "synthetic_password_89ec84ca283671b1", uid=103, cert=false, cert_chain=false rebound=false 11-26 10:17:14.536 2770 4719 I SyntheticPasswordCrypto: Deleted SP protector key synthetic_password_293151ba28441a0d 11-26 10:17:14.935 2770 4719 I PasswordPolicy: isExternalStorageForFailedPasswordsWipeExcluded() : no admin enforce password policy. 11-26 10:17:14.953 6382 24694 I clouddpc: [PolicyUpdaterImpl.java:fromCache:214] From cache started [passwordPolicies, passwordRequirements, encryptionPolicy] forceComplianceReport: false 11-26 10:17:14.954 6382 24694 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: RequestPolicyUpdateFromCache details: [policyKeys=[passwordPolicies, passwordRequirements, encryptionPolicy], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:17:14.954 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyUpdateStarted details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements], forceComplianceReport=false] metadata: [isNetworkConnected=true] 11-26 10:17:14.955 6382 7741 I clouddpc: [PolicyUpdaterImpl.java:reApplyAndExecuteCompliance:597] Updating policies: [encryptionPolicy, passwordPolicies, passwordRequirements] from cache with force report: false reportApps: false 11-26 10:17:14.958 6382 7741 I clouddpc: [PasswordRequirementsHandler.kt:apply:79] passwordPolicies is set, ignoring passwordRequirements 11-26 10:17:14.974 6382 7741 I clouddpc: [DefaultPasswordUtils.java:setPasswordRelatedPolicy:129] Applying password quality (server enum value): 65536 with scope: 0 11-26 10:17:14.975 6382 7741 I clouddpc: [PasswordPoliciesHandler.kt:applyResetPasswordToken$java_com_google_android_apps_work_clouddpc_base_policy_handlers_handlers:384] Reset password token already active 11-26 10:17:15.012 6382 7741 I clouddpc: [EventLogManagerImpl.kt:logMessage:2049] Event logged: PolicyReapplied details: [policyKeys=[encryptionPolicy, passwordPolicies, passwordRequirements]] metadata: [isNetworkConnected=true] I compared both results but were not able to detect any differences on the device. Thank you and best regards lennartsp
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/
Widgets on COPE - MS Intune
Hey, Unfortunately there are no settings and/or no chance configure Widgets on COPE in MS Intune. There is specific setting in Intune restrictions config profile to allow/disallow Widgets for BYOD method. Is this problem tied only MS Intune or is this something for Google? Majority of our 10k fleet enrolled as COPE and it's a big gap not having widgets available for Work Apps. Thanks Jarmo
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.Issues Intune and okta enrollment
Hi all, I could use some help or guidance from someone who has experience with using Okta as IDP and Intune as MDM. The problem: When going trough enrollment (COPE), the Intune login page shows up. When entering the email, it forwards to Okta as it should. But after verifying with Okta, you should get back to a Microsoft confirmation but instead it shows a page not found error. It used to work, nothing has changed as far as we know and the issue is present on devices ranging from Android 13 to 15, different brands but mostly Samsung. Apple and Windows enrollment work as expected, no issues there. I can't find any related logging details in Intune and lack the knowledge of Okta (will add a support ticket there as well). So i'm kind of lost as to what is happening. Where do I need to look for the return URL for example? There are multiple Azure enterprise apps but i'm not sure which one to check and don't want to mess to much with this. Thanks!How can I enable “miles” or loyalty points in an Android app for a Western wear e-commerce site in Pakistan?
Hi everyone, I run an e-commerce website specializing in Western wear in Pakistan and I want to add a “miles” or loyalty-points system in my Android app. The goal is to reward customers for purchases, encourage repeat orders, and increase customer retention. Here are some of the features I’m considering: Customers earn a certain number of miles / points per purchase, depending on cart value. Miles can be redeemed for discounts or free items. Displaying miles balance in the user’s profile. Ensuring security / preventing fraud (e.g. fake orders just to collect miles). Possibly integrating the miles system across website + Android app. My questions are: What Android- or backend-side frameworks / libraries can help me build or integrate a loyalty-points system? How do others handle storing and syncing points (offline vs online)? What are good patterns to avoid abuse / fraud in such loyalty systems? Any advice for making the UI/UX for loyalty points (especially for customers in Pakistan) intuitive and engaging?
