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
Android Management API Returning HTTP 502
Hi, We have noticed that the Android Management API is currently not working. After a long delay, it returns an HTTP code 502 error. We have tested this across multiple accounts, and the behavior remains the same. Could someone provide clarification on this issue? Thank you.
Enhancing Android Enterprise OS Update Management
Hi, The way the Android API implements OS update management on Android Enterprise devices is not particularly useful for devices with user affinity. Are there any upcoming API changes for EMM solutions like Microsoft Intune? From my experience with the current API: AUTOMATIC – The OS update is installed as soon as it becomes available via OTA, which is not practical for real-time scenarios. WINDOWED – Similar to AUTOMATIC but with the limitation that OS updates can only be installed within a defined maintenance window. This means that if a user needs to update their device due to a software bug fixed in the latest OS version, they may not be able to do so immediately if the maintenance window is set outside working hours. Source: https://support.google.com/work/android/answer/13791272?hl=en#zippy=%2Cmanaging-system-updates-using-system-update-policies Suggested Improvements: Provide an option to control OS updates on BYOD (Work Profile only). I understand that when enrolling a device through Work Profile, only the work container can be managed via EMM. Google may need to reconsider this approach. It would be beneficial to have an approach similar to Apple’s, where EMM admins can manage OS updates (e.g., push specific updates, set deadlines, etc.) through DDM (Declarative Device Management - Source: https://support.apple.com/en-gb/guide/deployment/depc30268577/web ), even on BYOD devices (Device Enrollment) — without requiring supervision like DO (Device Owner mode). I’m aware that Samsung Knox E-FOTA exists, but it is limited to Samsung devices. Expanding this capability to all Android devices (like Google Pixel devices) would greatly improve update management in enterprise environments. BR, Marco
Issue with G Suite Apps Being Marked as Disabled in Play Store
Hi everyone, We are facing an issue where G Suite apps like Google Sheets, Google Drive, and Google Docs are installed on our managed devices, but when we check them in the Google Play Store, they appear as disabled. In some cases, the apps are randomly disabled, requiring manual re-enabling. We have verified: Google Device Policy settings Apps are approved and allowed in the managed Play Store Despite these checks, the issue persists across multiple devices with G Suite apps. Has anyone else experienced this issue? If so, do you know of any workarounds or if there is an ongoing Google-side issue causing this? For reference, I have attached a screenshot showing the issue. Looking forward to insights from the community! Thanks, RupeshHow to Handle Delisted Apps in Google EMM During or After Device Provisioning?
Hi everyone, We’re facing an issue where managed Android devices get stuck, preventing app installations when an app included in a policy is delisted from the Play Store. For example, we had the package “com.Xplayer” in a device policy, but when calling Products: get, it returned: “googleapi: Error 404: No product was found for the given ID., notFound.” However, this app was available earlier, and despite its removal, using the Devices: update API still updates the policy without any error or warning. Additionally, there’s a possibility that an app is present on the Play Store when it is approved and added to the policy but later gets removed or delisted by Google. This could lead to installation failures and devices getting stuck. Has anyone encountered this before? How can we prevent devices from getting stuck when an app is delisted? Does EMM automatically remove such apps from policies, or do we need to handle it manually by checking each package ID? Is there any way to get notified when an app is removed from the Play Store? Without a proactive mechanism, devices remain in a stuck state, making large-scale device management challenging. Any insights or best practices would be greatly appreciated! Thanks!
How to add, update, and remove pinned shortcuts as a Device Owner without user interaction?
I am developing an MDM (Mobile Device Management) application and need to manage pinned shortcuts programmatically as a Device Owner. Currently, I can add, update, and remove pinned shortcuts only with user interaction using ShortcutManager. However, I need to perform these operations silently (without user confirmation) since my app runs as a Device Owner. I checked the Device Policy API and Android Management API, but I couldn’t find any specific policy or method for managing pinned shortcuts as a Device Owner. I attempted to use ShortcutManager#requestPinShortcut(), but it still requires user confirmation. I reviewed the Android Enterprise Documentation but found no mention of pinned shortcuts management for Device Owners. Is there any hidden API or specific Device Policy setting that allows a Device Owner to manage pinned shortcuts without user interaction? If not, is there any alternative approach to achieving this functionality programmatically? Thanks
Migration from Airwatch to Android Management API
One of our customers is currently onboarded to Airwatch to manage their devices, but they want to move to our Android Management API (AMA) based device management solution. Is there any support available to silently migrate these devices? Or is the only way to wipe the devices and onboard AMA. I see there is support if we own the custom DPC application. But in this case since its owned by Airwatch its out of our control.How to prevent users from disabling global proxy settings on fully managed Android devices?
I develop a Custom DPC application for fully managed devices, and I am planning to configure global proxy settings for Android devices through our EMM Console. I want to restrict disabling these proxy settings, but I am unsure how to implement this restriction. I have reviewed the UserManager and DevicePolicyManager documentation but could not find any specific settings or policies to prevent users from modifying or disabling proxy configurations. Would anyone happen to know how to implement the restrictions that would prevent users from disabling proxy settings on fully managed Android devices? Thank you in advance for your help.
Deleting and Erasing Device Using the AMA API
When I use the Android Management API to delete a device from an enterprise, the device is deleted but the physical device is not wiped, I can still see that the Physical device is connected to the enterprise from the device it self. The device is in fully managed mood. I want to ask if this is the normal behavior, because I'm expecting that when I delete a device from an enterprise with AMA API, the physical device should be cleared and factory resetted?
