Android Galaxy XCover 7 problems with .local adress
Hello we are facing a problem some of our Samsung Galaxy XCover 7 devices can only resolve an internal server with a .local address very slowly. This means that we cannot use the resource, as high latency leads to the connection being terminated. We use our own DNS server which comes with DHCP. If I change the DNS server manually using an app, but to the same DNS server that also comes with DHCP, we can reach the address without any problems and without long latency. (This happens over a VPN tunnel to the dns server) Does anyone have ideas?
Reverting Play Store Layout After Using Collections in Intune
Hello, We previously enabled the "Collections" feature in Managed Google Play, in Intune, to organize apps into categories. However, we would now like to revert to the default layout where all approved apps are visible in the Play store without needing to be added to a collection. We have fully managed Android devices. Currently, apps that are not explicitly added to a collection do not appear in the Play Store which is causing confusion for our users. According to the Google support article here: https://support.google.com/googleplay/work/answer/9146438?hl=en It states: "Note: Creating a collection changes the Play Store layout type which requires that all apps must be added to a collection to be visible. Deleting collections does not automatically revert back to the basic layout. Contact your EMM to determine how to revert back to the basic Play Store layout in their solution." The workaround currently is to add every single app into the collection but its easy to forget. I have also not been able to add more than one of our Managed Google Play webapps which makes them not visible to our users. We contacted Microsoft/Intune support, and while they attempted to help, they ultimately referred us to Google Support. However, I haven’t found a direct way to contact Google about this—only this forum. Has anyone else experienced this issue? Is there a known way to revert the Play Store layout back to the default view without using collections? Thanks in advance!Need Help with QR Enrollment for Multiple Devices in Educational Environment – Is External MDM Required?
Hi everyone, I'm managing a large number of Android tablets in an educational environment. I'm trying to enroll the devices using Android Enterprise with QR code enrollment, but I'm having trouble getting the QR method to appear. So far, only Zero-Touch shows as an option, but most of our devices were not purchased through Zero-Touch resellers, so we can't use that method. My main question is: Is it strictly necessary to use an external MDM (like Miradore, Intune, etc.) to generate the QR code, or is there a way to create and use it directly from the Google Admin console or natively through Android Enterprise? We want to deploy the tablets efficiently and avoid entering accounts manually. Ideally, each device would automatically enroll with our managed Google Play account by scanning a QR code after a factory reset. This is especially important in a school context, where we have many students and limited time for configuration. We are already registered in Google Workspace, and the tablets are in a dedicated organizational unit for students. The admin account is managed, and we are using the Android Enterprise platform linked to our domain. For reference, here are two YouTube videos showing the configuration steps I followed (which reflect our current setup): https://www.youtube.com/watch?v=jI-C_y1u8jE https://www.youtube.com/watch?v=h__pvfp559Q Any advice or clarification would be greatly appreciated. Especially if there’s a native way to enable QR enrollment without needing a full external MDM platform. Thanks in advance!
"This item isn't available in your country" showing on isolated apps on isolated devices.
All of a sudden I'm having issues installing apps through Managed Play on isolated devices. When navigating to the app directly I can see "This item isn't available in your country." The devices are in the US. Location services confirms this, the external device IP is also US based as well. I have cleared cache and app storage of Google Play and Google Play Services. I have upgraded Google Play Services. The devices are fully managed with manage service accounts. I have reset the account assigned to the device. I have tried to set the Country manually in Google Play setting but am unable to do so. It does not show a current country. I also see an option for "Switch to the United States Play Store" but tapping on it doesn't do anything. Any ideas or suggestions here?
OEM Unlock toggle not available
Hi all, Recently joined the community, first time poster here. TL;DR at the bottom. Hopefully my question has a simple solution but I've looked everywhere (except here of course). I'll try to keep this as simple as possible. Everything is in UAT if that matters. The important bits: Pixel 8a Build BP1A.250505.005.B1 No SIM or eSIM Android Enterprise registered to my UAT Tenant I'm testing some scenarios for automating device compliance with Omnissa using Workspace ONE Intelligence. To test this successfully I'm going to need to flash back to an older Build and probably more than once for demo purposes. The OEM Unlock toggle is not available however, and I this is preventing me from doing my testing. I've read conflicting posts elsewhere regarding carrier unlock, SIM and/or eSIM etc. ADB is working fine but flashing older images is just not working. Any help from the community on how to get OEM unlock enabled would be greatly appreciated. TL;DR: Need to flash a pre 250505 build to my Pixel 8a. Can't toggle OEM unlock as it's greyed out.
Play Protect Blocking Custom DPC Apps — How to Get Approval or Alternatives?
Hi everyone, I'm a developer who helps enterprises build custom DPC (Device Policy Controller) Reference Documentation apps to manage Android devices based on their unique requirements. Recently, Play Protect has started blocking the installation of custom DPC apps, even when these apps are signed and used internally. The warning claims the app may pose a risk due to access to sensitive data - even though it's strictly for enterprise use. To make things more difficult: Google is no longer accepting registration of custom DPC apps with Android Enterprise, which limits official distribution and management options. Android Management APIs don’t support all use cases, and also have quote limit. I’ve applied twice to join the Android Enterprise portal to build a SaaS-based device management platform, but both requests were rejected without a clear reason. My questions for the community: Is there any official way to get a custom DPC app approved or whitelisted by Play Protect? Are there any alternative ways to manage Android devices at scale (outside of AMAPI or legacy EMM)? How can new developers or startups gain access to Android Enterprise features when onboarding is currently restricted? Any help, direction, or shared experience would be greatly appreciated. Thanks, Kulwinder
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.The Ongoing Evolution of Android: Where Do We Go From Here?
Android has come a long way since its early days, evolving from a basic smartphone OS to a powerful platform that powers billions of devices worldwide. With every major release, we see improvements in performance, security, design, and user experience. From Android’s open-source flexibility to the introduction of Material You and AI-driven features, the platform keeps pushing the boundaries. One of the strengths of Android has always been its customization. Users love being able to tweak their device—from launchers and widgets to ROMs and root access. However, as Android becomes more polished and secure, some of these freedoms have become more limited. Is the trade-off worth it? Another topic worth exploring is Android’s fragmentation. While it gives manufacturers flexibility, it also creates inconsistency in updates and app performance. With initiatives like Project Treble and Android One, Google has made strides, but are we seeing real results? And now with AI integration, foldable phones, and powerful chipsets becoming the norm, it’s exciting to think about where Android is headed next. What are your thoughts on the current state of Android? Are you satisfied with the direction it’s going, or do you miss the old Android freedom? What improvements would you like to see in the next version? Looking forward to hearing everyone’s thoughts!
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
