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.
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
Initial Android Management API device limit is 0 after enterprise creation – how can we test during quota review period?
Hello Android Enterprise Community, We are currently building a custom MDM solution based on Android Management API and have completed the full end-to-end workflow, including enterprise creation, policy creation and assignment, enrollment token (QR) generation, device command lifecycle testing, Pub/Sub notifications, and admin panel and backend integration. The enterprise is created successfully, however the initial device limit shows as 0, so we are unable to enroll any test devices at the moment. We have already submitted the Android Management API initial quota request form with a detailed business use case and supporting architecture documentation. Due to the holiday period from December 19 to January 5, we understand there may be delays in review. I would like to ask: Is there any recommended way to test device enrollment while the initial quota request is under review? Is a temporary or development test quota ever enabled for validation purposes? Are there any best practices to validate an MDM implementation before quota approval? We want to ensure our implementation fully follows Android Enterprise and Android Management API best practices. Any guidance from the community or Google team would be greatly appreciated. We are currently building a custom MDM solution based on Android Management API and have completed the full end-to-end workflow, including: Enterprise creation using Android Management API Policy creation and assignment Enrollment token (QR) generation Device command lifecycle (lock, wipe, compliance) Pub/Sub notifications for device status updates Admin panel + backend integration The enterprise is created successfully, however the initial device limit shows as 0, so we’re unable to enroll any test devices at the moment. We have already submitted the Android Management API initial quota request form (500 devices) with detailed business use case and supporting architecture documentation. Since there is a holiday period (Dec 19 – Jan 5), we understand review responses may be delayed. Questions Is there any recommended way to test device enrollment while the initial quota request is under review? Is a temporary test quota ever enabled for development or internal validation? Are there any best practices to validate an MDM implementation before quota approval?Chrome OS + Crostini: The Missing Bridge to Android Development
Hello Community, I recently read an article about connecting a Windows PC to an Android phone, which got me thinking: we need a similar focus on connecting Chrome OS (via Crostini) to Android devices. Since both Android and Chrome OS are Google products, the integration should be seamless. If Google wants to grow Chrome OS adoption, developers are the ideal first target. However, making it easy for developers to build Android apps on Chrome OS must be a priority, and currently, there are significant friction points. The Technical Blockers My Android development on Chrome OS has been halted for over a month due to persistent issues: ADB Debugging on Managed Devices: My managed Chromebook (I am the admin) has the "Enable ADB debugging" toggle locked. Despite a month of searching, I haven't found a fix. Connection Instability: Both USB and Wi-Fi debugging work intermittently and then fail. I have tested this with a modern Android 15 phone and an older Lollipop tablet; the connection fails on both, pointing to an issue on the Chromebook side. USB File Transfer: There is a known issue transferring files from Crostini to USB devices (requiring a workaround of copying to the Chrome OS files app first). The Strategic Picture Google should not depend on Microsoft Windows for Android development. Chrome OS is already a high-quality product—I use it daily. For example, upgrading my Crostini VM from Debian 12 (Bookworm) to Debian 13 (Trixie) was a pleasure and required no reinstallation. This stability proves Chrome OS is a serious development platform, not just a "cheap" alternative. Addressing the "Aluminum OS" Rumors There is a current campaign discrediting Chrome OS, citing rumors about a new "Aluminum OS." I believe these rumors are misinterpreted. Rather than dropping Chrome OS, it appears Google is aiming for the high-quality device segment. Regardless of naming conventions, Google is walking securely, step-by-step, from a browser to a full OS. Conclusion I strongly advise Google to continue its efforts in making Chrome OS a high-end development platform. The community is involved and patient (a major quality of developers!), but we need these bridge issues—specifically ADB debugging and USB file transfers—solved to fully unlock the potential of the ecosystem.
