Intermittent QR Code Provisioning Failures with Identical Source Code
I am experiencing inconsistent behavior with QR code provisioning for Android Enterprise and am seeking guidance from the community. The Issue: QR code provisioning works intermittently, but the failure pattern is inconsistent. A provisioning QR code generated from a specific APK build will work reliably. However, subsequent builds of the exact same source code from the same Android Studio project will sometimes fail. The device displays a generic "Contact your IT admin" error. What I've Verified: The APK is properly signed and the checksum in the QR code is correct. The server delivers the APK with the correct application/vnd.android.package-archive MIME type. The DeviceAdminReceiver is correctly declared in the manifest and the associated XML resource exists. The package name and component name in the QR code are 100% accurate. Comparing a "working" APK and a "failing" APK in APK Analyzer shows no differences in the core components (package name, receivers, resources). Question: Has anyone else encountered this? Are there known issues with Android's provisioning service being sensitive to certain aspects of the APK build output that are not related to the core functionality or signature? Any insight into how to achieve consistent, reproducible builds for provisioning would be greatly appreciated.
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!Default browser app not resettable
Hey! We are currently testing a few apps in Work Profile, for which we need 2FA. The second factor is a FIDO2 token that can be used via NFC or USB. If you have a FIDO2 token with USB-C, everything is fine. But we also have some with USB-A. If you don't have an adapter, you're more likely to resort to NFC. Chrome supports FIDO2/NFC directly, which makes logging in quite easy. However, most web views cannot do this, and a passcode must be entered manually. The pure FIDO2 NFC tag basically contains a URL with the passcode. You open the webpage via NFC, copy the passcode, and enter it when logging in. So far, so good. However, we encountered a problem that prevents us from using the FIDO2 token via NFC in the Work Profile properly. There are default apps for different categories such as browser, wallet, caller ID, etc. If you need to launch one of the app categories and there are several apps available, you will be asked which app you want to use and just for once or always. The app preferences can be reset via the settings so that the query will reappear the next time. This works without any problems with “Home app,” for example. But the Default Browser? No. The Browser app default remains after the reset. Even if a browser was set as the default and was deleted, it will just switch to another app and won't ask. The problem with a permanently set default browser is that links from NFC tags are immediately opened in the personal space. If there is a copy & paste lock on the work profile, you cannot use the code. (Unless you type >40 characters) If you are asked for an app to open the URL, you can also select the browser in Work Profile. Can anyone reproduce this behavior? Or does anyone know if something has changed for the Browser-Default in Android 15/16? On a device running Android 13, resetting the app defaults works reliably. It doesn't seem right that the browser default cannot be reset properly with Android 15/16.
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 help
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
GSF ID not generated after device enrollment on Android 15
Hi everyone, We’re facing an issue with devices running Android 15 — after successfully enrolling them in our Android Enterprise setup (Device Owner / Fully Managed mode), the Google Services Framework (GSF) ID is not being generated. This issue did not occur on Android 13 or 14; the GSF ID was available immediately after enrollment. However, on Android 15, the GSF ID remains empty even after waiting and rebooting. We’ve already tried: Factory reset and re-enrollment Checking Google Play Services version Ensuring the device is connected to the internet Waiting for Play Store sync Despite that, the GSF ID is still missing. Could anyone confirm if there’s a known change in Android 15 related to GSF ID generation, or if additional permissions/configuration are required for enterprise-enrolled devices to obtain it? Any guidance or workaround would be greatly appreciated.
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?
