Can't configure notifications on my work profile
I hope someone here can help me, since I've been stuck in this issue for over a month now. I can not configure notifications on my work profile. I am the admin so should be able to allow this for users. I'll share some screenshots to illustrate the issue. First, the disabled notification: Then, the advice of gemini: The Solution: Change the Admin Policy You must log in to your Google Admin Console and change the setting that is blocking this. On your computer, log in to your Google Admin Console at admin.google.com. In the left-hand menu, navigate to: Devices $\rightarrow$ Mobile & endpoints $\rightarrow$ Settings Click on Android. This page lists all your Android policies. You are looking for the setting that controls app permissions. It is most likely in one of these two sections: Primary Target: Apps and data sharing Look for a setting like App permissions or App settings. The current setting is likely "Block user from modifying" or "Set to... (Enforced)". Change this setting to Allow user to configure or Let user choose. Secondary Target: Work profile Look for a setting like Work profile notifications or Lock screen notifications. While this usually just controls lock screen visibility, if it's set to "Hide all notifications," it may interfere. Ensure it is set to Show all notification content or Allow user to configure. Click Save at the top or bottom of the page. This option is simply not there!
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
Issue with Android Enterprise provisioning: afw#identifier invalid and Play Protect blocking app during QR enrollment
We are an organization using a third-party MDM / Device Policy Controller (DPC) solution to manage our Android Enterprise devices. The DPC application is published on Google Play and has been working for managed provisioning. Recently, we started facing issues during Android Enterprise enrollment, and we are seeking guidance on the correct and supported setup. Issues observed 1. afw#identifier enrollment When attempting enrollment using afw#<identifier>, the setup fails with errors such as invalid token, wrong setup, or unable to continue enrollment. This previously worked and now fails consistently, even though the DPC remains published on Google Play. 2. QR code–based provisioning When using QR code provisioning, the device completes initial setup but then Google Play Protect shows “App blocked by Play Protect” for the DPC. The DPC app is Play-approved and not sideloaded by end users. We have already submitted a Play Protect appeal through the official appeal form. 3. Distribution method For QR provisioning, the DPC APK is currently hosted on our own HTTPS server, and the QR includes: Device Admin component SHA-256 signature checksum Secure download location Despite this, Play Protect flags the app after provisioning. Clarifications we are seeking Are there recent changes or requirements for afw#identifier enrollment that could cause invalid token or setup errors? Does Play Protect apply additional checks during QR-based provisioning, even for Play-approved DPC apps? Is using a self-hosted APK download location still supported for Device Owner provisioning, or is Managed Google Play / Zero-Touch enrollment now required? Is there a supported way to allowlist or whitelist a legitimate enterprise DPC app so it is not blocked during provisioning? Are there recommended best practices for third-party MDM providers or enterprise customers to avoid Play Protect blocks during enrollment? We are not attempting to bypass Play Protect or supported security mechanisms. We want to ensure our Android Enterprise setup follows current Google-recommended practices and understand the correct approach going forward. Any guidance or clarification from the community or product experts would be appreciated.
Enable third-party Android mobile management
Hey Android Enterprise community, I'm trying to understand what the "Enable third-party Android mobile management" checkbox in Google Admin does. How does this affect situations where multiple Android Enterprises are bound to multiple EMM solutions? Will both Android Enterprise continue working if they are bound to different EMM solutions, even if only one is selected on the screen above? If I use the Enrollment token link method to provision a device and have no users in my Google Workspace, will switching the EMM provider in the dropdown below the checkbox have any effect? Also, does Authenticate Using Google affect provisioning if there are no users in Google Workspace? Thanks, Marko
GBoard - Suggestion Strip
Hi, We want to use GBoard on kiosk devices but we aren't able to remove the suggestion strip using managed configurations. All other settings can be configured fine though. The show suggestion strip configuration is set to disabled. But with versions 15.x and 16.x of GBoard it's still visible on the devices. And when checking the setting locally on the device it's still enabled (Disabling manually works fine) Back in version 14.x this configuration worked fine. Anyone else who has experienced the same thing? We've tested this on devices from Samsung, Bluebird, ELO, and Zebra. Android version doesn't seem to have any impact, just the GBoard version. // Magnus
12 deliveries of AE-mas (What shipped in Android Enterprise in 2025)
2025 was a big year for Android Enterprise. This was the year several long-missed features finally landed, Device Trust became a thing, zero-touch got a compliance and audit boost, provisioning saw a revamp, and the Android Management API quietly kept adding the sort of controls that make admins' lives easier. So, in the spirit of celebrating a strong year for the platform, here are 12 Features of AE-mas (let's not worry about the title.. I was strugglin'), in no particular order, chosen somewhat at random as - would you believe - the list could have been longer should I have chosen not to follow the 12 days of Christmas as the theme.. 12. APN overrides via AMAPI APN management finally arrived. In May 2025, AMAPI gained apnPolicy, allowing admins to define and enforce APNs directly through policy. This closes a long-standing gap for cellular deployments where “just set the APN” has historically been anything but. It's great to see this functionality pulled out of OEM config and into the AMAPI layer, giving admins access to on-device APIs that have been effectively off-limits for years. Read about APN here. 11. Developer verification for Android Developer verification isn't coming until next year, but we're talking about it already, and work is in progress to bring it to fruition now. Developer verification raises the bar for Play publishers by requiring stronger identity verification. For enterprise, it’s a supply-chain win: fewer convincing lookalikes, higher friction for malicious publishers, and a clearer answer when security teams ask “who made this app, exactly?”. There’s pushback in the community, there's a lot of misunderstandings about the requirements and ramifications, but hopefully as time goes on this will settle on both sides through further transparency and discussion. Organisations deploying private apps to their own tenants are currently exempt, but it remains a big change nonetheless, and organisations benefit from the wider boost in authenticity of apps and developers. I covered off more about developer approval here. 10. Device Trust from Android Enterprise This was the year Device Trust arrived. Device Trust enables real-time posture and integrity signals (Play Integrity verdicts, boot state, security patch recency, lock-screen presence, strong auth age, OS tamper signals) that can be evaluated continuously rather than only at enrolment, and on both managed and unmanaged devices. It's a huge boost for MAM-type deployments, security solutions, and allows traditionally EMM-dependent vendors the freedom to operate independently. This isn’t a small feature. It fundamentally changes how Android Enterprise fits into modern security architectures. I wrote more about Device Trust here. 9. Custom app management via AMAPI (CUSTOM install type) One of the most consequential releases of the year, perhaps even since AMAPI began half a decade ago. AMAPI introduced first-class support for installing and managing custom applications using installType: CUSTOM, backed by signing certificate validation (appSigningKeyFingerprints) and explicit install and uninstall commands. It allows organisations reliant on line-of-business (LOB) internal applications to ditch any and all wild-west sideloading for a policy-driven, verifiable deployment, which is exactly what enterprise actually needs. All without the need for uploading apps to Google Play. I wrote more about custom apps here. 8. Zero-touch portal audit logs and admin roles The zero-touch portal became auditable and permission-scoped in 2025. Google rolled out audit logs to the zero-touch customer portal, capturing all admin actions needed to ensure the platform is no longer a black hole of who did what. Alongside this came clearer admin role separation, reducing the blast radius of operational mistakes. For regulated environments, this turned zero-touch from a black box into something governance teams could actually trust. 7. Android 16 provisioning improvements One of the greatest improvements to the enrolment flow happened in 2025, and it was so long overdue! Android 16 brought a clear push toward more reliable setup flows, fewer steps, and the ability to update it on the fly, as opposed to being stuck adjusting it only on major version releases. I put out a video nearer the start of the year, while 16 was still in beta, which you can see on LinkedIn here. With this newer approach, Google is beginning to leave behind the old managed provisioning flows baked into AOSP, though they're still there as a fallback today. It'll be interesting to see how this evolves. 6. Application roles in Android Management API This was unexpected. Application Roles formalised entire classes of enterprise apps, including: COMPANION_APP KIOSK MOBILE_THREAT_DEFENSE_ENDPOINT_DETECTION_RESPONSE SYSTEM_HEALTH_MONITORING Apps assigned these roles can be exempt from background execution limits, power management, suspension, and hibernation on modern Android versions, with user control restricted by default. This isn’t just about companion apps - it’s about enterprise software finally being treated as first-class by the OS, and adds much-needed flexibility with far less configuration and overhead. 5. Default application management policy Admins finally gained control over default apps. AMAPI added a policy allowing admins to define a prioritised list of default applications per app type (browser, dialler, etc), setting the first qualifying app as default and preventing user changes. For compliance-sensitive fleets - browsers, diallers, PDF viewers - this is the sort of boring control that saves hours. It's predominantly Android 16+, but there's a few that go back a few versions of Android. Read more about default applications here. 4. RCS archival RCS has long been the compliance blind spot for Android Enterprise fleets, with SMS/MMS archiving handled by legacy tools while RCS was left out in the cold. In December, Google release a supported way to archive RCS/SMS/MMS on fully managed devices, with Google Messages as the mandated client. Once those prerequisites are met, admins can configure Messages to forward message bodies, metadata, and attachments to a SIEM/service/archival tool on a schedule or trigger with no needed workarounds or limitations of legacy solutions. It’s - to reiterate - Google Messages only for now (OEM messaging apps remain out of scope unless they add their own support), but it gives regulated orgs a sanctioned retention path for rich messaging at last. It has been met with quite a bit of mixed feelings, and even more FUD. I go into more detail about RCS archiving here. 3. App functions and cross-profile controls Android 16 brought app-to-app interaction under policy control. New settings allow admins to govern whether apps can expose app functions, and whether personal-profile apps can invoke functions exposed by work-profile apps, bringing finer control to cross-profile linking scenarios. Niche, but powerful for when this functionality takes off in enterprise workflows. 2. Android App Bundle (AAB) support in the Managed Play iframe This finally removed a long-standing enterprise limitation. In March 2025, Android App Bundle uploads became supported in the Managed Google Play iframe. Private apps finally gained parity with public Play distribution, including split APK delivery and more efficient installs. I wrote more about AAB here. 1. Android’s accelerated platform release cadence The change that underpins everything above. Android is shifting toward more frequent platform releases, with Android 16 landing far earlier than usual and signalling a broader move away from a single annual cadence. Harder to track? Maybe. I'm having a lot more fun poking around the Android Canary builds looking for unreleased functionality than I do sleuthing around AOSP code, though! Better for shipping enterprise capability without waiting a full year? Also yes. Signing off Android Enterprise levelled up across the board in 2025. From trust and supply-chain integrity to app management and provisioning improvements, the team set the bar really high this year. Let's hope the momentum continues in 2026! Which of these made the biggest difference for you this year, and what are you hoping lands in 2026? Happy holidays and here’s to a wonderful New Year!
