Apps
148 TopicsIntune Migrate Managed Google Play Account to Managed Google Domain
Hi there, I’m looking for clarification on Microsoft's recent update about upgrading tenants from a Managed Google Play account to a Managed Google Domain account in Intune. Intune Android Enterprise Update We have 130+ Android Enterprise devices enrolled in Intune with an old Gmail account we dont have direct access to. Our Intune connection was originally set up using this account back in 2023. Now we have the option to "Upgrade" our account but we need to understand the risks before we proceed. Microsoft says that we can continue managing devices under the new Entra‑linked Managed Google Domain account without deprecating the old method, and without device impact. Is the migration fully in‑place and non-disruptive? Meaning: No need to retire devices No re-enrollment No break in Managed Google Play sync No loss of approved apps or assignments Is this migration guaranteed to perform an in-place transition of the administrative account without: Breaking the existing Android Enterprise binding Generating a new enterprise ID Requiring any user/device actions Interrupting app delivery or policy deployment? Any advice from someone who has already completed the upgrade would be great! Thank you in advance for any clarification.31Views1like2CommentsZTE Enrollment Profiles Issue
Greetings everyone! New day, new challenge. I’ve received a number of Zebra tablets. We already use ZTE, which works fine, but as you know it assigns devices to a single profile based on the serial number. The issue is: These tablets (same model) will be used for many different purposes, and I don’t think it’s efficient to take each device out of the box, read the serial number, and manually assign it to a different ZTE profile. I could easily end up managing 200 different profiles. So my question is: Is there a way to let the device choose which group or category it should belong to during enrollment? For example, during setup the device could ask the user which category it belongs to and based on that selection it would automatically join the correct group and receive the appropriate configuration. Is this possible? Or am I dreaming? 😄 Has anyone faced this issue and found a good solution? Thanks in advance!94Views0likes10CommentsOption for MDM to place app shortcuts on home screen
We have a great wish to place shortcuts for specific apps on the home screen when the app is installed (or at a later point), but this doesn't seem to be possible. When we discuss this with our MDM provider (SOTI), we are told, it is a Google/Android limitation, and this seems a bit strange to me; is it really not possible to place shortcuts on the home screen to your own liking? I hope this resonates with others - or even better; that I can be corrected, and there is a smart and easy way to achieve this goal. We run all our Android devices as fully managed, if that is relevant.214Views2likes28CommentsGoogle Play Protect's new policy for custom DPC
Apparently, Google has a new policy that only approved DPCs can be installed through QR Provisioning; otherwise, their installation will be blocked. Link: https://developers.google.com/android/play-protect/warning-dev-guidance#android_enterprise_dpc_enrollment The problem is that I am not able to understand how to apply for DPC approval. I found this page, but still not able to find out where to apply. Your help is appreciated. ThanksSolved642Views2likes7CommentsDevice financing at scale (10,000+ devices): compliant “restricted mode” on delinquency using Android Enterprise (Device Owner)
Hi everyone, I’m building an Android Enterprise device management solution and I want to keep everything fully compliant (Android Enterprise + Google Play policies). Use case: a company provides company-owned devices to customers under a leasing / device financing contract. We need to manage this at scale (10,000+ devices) across multiple customers/tenants. If a customer becomes delinquent, the company needs a temporary restricted mode (e.g., kiosk/limited access) until the account is back in good standing — with clear user notice, grace period, and contractual consent. What we want to control at scale: enrollment, policy assignment, app allow/deny lists, kiosk/lock task mode, updates, compliance reporting, and remote actions aligned with Android Enterprise best practices. Questions: Is this type of “restricted mode for delinquency” considered acceptable in the Android Enterprise ecosystem when devices are Company-Owned (Device Owner) and the policy is transparent/contractual? For 10,000+ devices, what is the recommended architecture: Android Management API (AMAPI) policies only, or a custom DPC (and why)? For distribution, is the safest path a managed Google Play private app per enterprise/tenant, or another approved approach for large-scale deployments? Any best practices to avoid being flagged by Play Protect / Play policy reviews for legitimate enterprise enforcement features (kiosk, app restrictions, device restrictions), especially at this scale? I’m not looking to bypass security or do anything hidden; the goal is a compliant enterprise solution. Thanks for any guidance or official documentation links.Solved110Views0likes8CommentsAMAPI requests for enterprises.applications.get and enterprises.policies.patch are failing intermittently
Is anyone observing AMAPI requests for GetApplication and PatchPolicies failing intermittently ? I am observing intermittent failures with the log - "googleapi: Error 503: The service is currently unavailable., backendError".64Views0likes3CommentsIssue 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.136Views0likes3CommentsPlay EMM API: Devices.get / Devices.list unavailable for extended duration
Issue Description : After device enrollment, Devices.get() and Devices.list() intermittently return “No Device was found”/an empty list for the same device for an extended duration greater than 15 mins. This behavior persists beyond the propagation delay described in the documentation, which is 2 mins. Impact: App Distribution affected Our EMM supports incremental app distribution: Fetch current device policy Merge additional apps Re-apply policy using Devices.update() When devices.get() / devices.list() are unavailable: We cannot retrieve the current device policy --> Incremental app distribution fails Detailed Reproduction Steps: Enroll device (afw#DPC_IDENTIFIER managed accounts method) Call Devices.update() to distribute apps that were pre-configured for installation during the enrollment process. Call succeeds Custom DPC adds managed Google Play account on Device Call Devices.List(enterpriseId, userId) → Returns empty for 15+ mins Call Devices.get(enterpriseId, userId, deviceId) → Returns 404 "No device was found" during this time Queries: What is the expected propagation delay for custom DPCs? How long should we poll and check if the deviceId is listed in devices.list()? Any workflow changes needed from our side? How do other EMMs handle incremental app distribution?79Views0likes3CommentsGoogle Play Protect's new policy for custom DPC
Apparently, Google has a new policy that only approved DPCs can be installed through QR Provisioning; otherwise, their installation will be blocked. Link: https://developers.google.com/android/play-protect/warning-dev-guidance#android_enterprise_dpc_enrollment The problem is that I am not able to understand how to apply for DPC approval. I found this page, but still not able to find out where to apply. Your help is appreciated. ThanksSolved151Views0likes2CommentsSamsung 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! DanielSolved4.5KViews2likes55Comments