[Day 3] Dedicated to Dedicated: Non-negotiables for EMM/MDM in Rugged Android Deployments
Disclaimer: The following article captures the opinion of Matt Dermody, Senior Director of Enterprise Mobility at Manhattan Associates. The stances contained within are a reflection of Manhattan's specific focus on line-of-business Android devices, built on years of being "Dedicated to Dedicated." Background Manhattan Associates is a B2B software company specifically focused on best-in-class, line-of-business enterprise deployments of enterprise software such as Warehouse Management (WMS), Transportation Management (TMS), and Point-of-Sale (POS). These software deployments command high expectations of uptime and availability, and that ultimately encompasses the complete solution, including the mobile computers that the software runs on. Manhattan is dedicated to ensuring that our end customers have the best possible experience, and that involves ensuring that the dedicated devices running our software are also properly maintained and supported. Google defines a "dedicated device" as a company-owned device that is fully managed and locked down for a specific work purpose, often using a single app or a small set of apps. These devices are restricted from personal use and are used for business functions like point-of-sale systems, inventory scanners, or digital signage. Or in other words, all of the device types that Manhattan sells, deploys, and supports alongside our software solutions. In that sense, I guess it can be said that we are… Dedicated to Dedicated. Managing rugged, line-of-business Android devices is not the same as managing BYOD phones and laptops. These are mission-critical endpoints running specialized apps in warehouses, stores, yards, and DCs—downtime costs money and local IT is increasingly rare. Your EMM/MDM must control versions, files, firmware, and field support with precision. Anything less adds risk and operational drag. Situation Imagine having to explain to a CIO that a business-critical mobile app has automatically upgraded to a new version that breaks functionality, and there is no easy rollback available. Here is a preview of how that might look. That situation is all too common but can be prevented with the right EMM/MDM strategies. The mere thought of that possible situation keeps the Manhattan team up at night. We have spent years developing strategies to add predictability and stability into enterprise device deployments to prevent bad situations from ever happening. Philosophies & Strategies Here is a preview of some of the core philosophies surrounding Manhattan’s tailored approach to managing mission-critical device deployments. Some of these might be controversial, but these are the strategies that work for us. 1. App Distribution and Version Discipline Rigorous version control of enterprise apps—stage, canary, bulk rollout, and rollback—is a must. Rugged ops cannot afford “surprise” app updates or version creep. If you can’t downgrade quickly, you don’t control your risk surface. An EMM/MDM should offer direct installation of private APKs on fully managed devices. Auto-upgrades to the “latest only” through Managed Google Play can lead to instability and version drift. Look for a console that can deploy specific app builds to specific groups on your schedule. If your tool can’t install an APK directly onto devices, it’s the wrong tool for rugged. Period. You must target different versions/configs by environment—Stage, QA, Prod—often per site group. That includes app versions, config files, etc. 2. File Management for App and Scanner Configuration LoB apps often externalize key settings via JSON and similar external config files. For example, Zebra DataWedge uses .db files placed in a specific auto-import directory to control mission-critical scanner settings. Your EMM must place, update, and replace these files on demand and at scale—ideally without anyone touching a device. Emergency changes (host cutover, DNS rename, scanner tweak) should be a file push away, not an onsite scramble. 3. Remote Control and Log Retrieval Treat full-fidelity Remote Control as table stakes. Support must see what the user sees, drive the screen, and pull logs and files in one session. Anything “view only” or bolt-on only erodes speed to resolution. Relying on reports from the floor or grainy pictures of an error taken from another device are not sufficient tactics for troubleshooting mission-critical device deployments. When issues hit, you don’t want an insurance policy like Remote Control that can be used to quickly diagnose and test solutions; you want a tool. An EMM admin without Remote Control is effectively blind with their hands tied behind their back. 4. OEM-level Controls (Zebra/Honeywell) There are numerous configuration settings that enterprise-grade OEMs extend beyond the baseline Android Enterprise configuration APIs. These OEMs are generally years ahead of what is available in base Android from a configurability standpoint and often introduce configuration settings that may otherwise never arrive to the base OS. These granular configuration layers ultimately are what set enterprise-class devices apart from consumer-grade technology. It is therefore imperative that an EMM managing these devices has the capability to manage OEM configuration extension features directly. For Zebra, this involves execution of their MX XML, DataWedge behavior, button mapping, radios, and other rugged-specific controls—through native profiles or integrated mechanisms. OEMConfig is useful, especially for parity across EMMs, but you will hit practical limits in closed networks and with Play-dependent timing/visibility. OEMConfig is a lowest-common-denominator functionality that was designed as a bridge to enable limited AMAPI-aligned EMMs to manage OEM-level settings with the limited tools at their disposal. Your EMM should support both OEMConfig (at a bare minimum) and offer the flexibility of direct MX/file workflows so you’re not boxed in by the limitations of distributing device settings through a complex web of Google Play server infrastructure. Your EMM should offer the ability to manage settings directly on the devices it manages, without the added layers and black boxes of complexity. 5. Firmware and Security Patching Over-the-Air (OTA) upgrades are great, but only when the EMM admin is in complete control. Auto-upgrades from the OEM pushed out over the air can bring production to a halt when critical business functions break. At a bare minimum, they can bring a network to a standstill as large upgrades are forced through the ISP connection into the building or site. An EMM should therefore offer integrations with the OEM-specific OTA and/or firmware upgrade protocols to put the controls in the admins' hands. 6. Lockdown and Kiosk Modes Rugged devices should boot into the work, not into Android. Enforce kiosk/lockdown, strict app allow-lists, settings restrictions, and consistent UX across every DC and store. The EMM should offer configurability over what is displayed on the lockdown, including personalization and customization to offer links to additional items such as launching apps, toolbars, or script executions. 7. Enrollment that Fits the Reality of Rugged Use Android Enterprise Device Owner (AEDO) with a barcode-driven process (e.g., Zebra StageNow). It’s fast, repeatable, and minimizes user taps and mis-taps on the floor. Wi-Fi credentials can be encrypted in the barcode rather than shared haphazardly and manually entered by end users into the Setup Wizard. More granular control over initial network connectivity is also afforded as compared with the limited options available through DPC extras if using the designated AEDO QR method. Avoid Zero Touch Enrollment (ZTE) for rugged Wi-Fi-only devices. ZTE is not "Zero Touch" as it realistically pushes many touches (and possible errors) to end users. There is overhead and maintenance to unenroll and re-enroll devices into the portal as they go in and out of repair. Enterprise-grade devices are often covered under repair contracts due to the nature of the environments they’re used in. This means they are going in and out of repair relatively frequently, and ZTE portal management ends up causing more bottlenecks than the steps it’s otherwise designed to free up. StageNow barcode flows are fewer steps and far more reliable for DCs and stores. 8. Closed Networks and Offline Constraints Many rugged sites have limited or no access to Google services. Your EMM must support managed app configuration and device policies in ways that don’t depend on real-time Managed Play orchestration. If your only path is Play-mediated, you’ll struggle with timing, visibility, and outcomes. Look for an EMM that offers “offline” or standalone Managed Configuration support by reading and exposing the configuration schema of an uploaded Enterprise app. 9. Health Analytics, Drift Detection, and Scripting Device health analytics (compliance, connectivity, install status) are critical for early detection and fleet stability. Pair that with a scripting engine and policy-driven rules (e.g., automatic relocation, auto-heal) to keep devices in line without manual human intervention. 10. What to Deprioritize (and Why) BYOD-centric EMMs that can’t directly install private APKs, can’t push files, and don’t include Remote Control as a first-class capability will drag deployments and support. Many EMMs specifically lack the granular APK/file control, versioning/rollback discipline, and integrated Remote Control required for rugged Android in DCs and stores; workarounds add fragility and cost without closing the gaps. Bonus – Identity and SSO Newer EMMs are offering advanced capabilities around Identity Management and SSO across business apps. As enterprise-grade devices become more multi-purpose, more mobile apps are being installed, each often with its own separate login requirements. Over time, there will be increasing needs to supply SSO workflows on-device across these business apps and to offer a clean pathway to script and automate the cleanup of a prior user’s session across all apps as they log off and make way for the next user to log in. If in the EMM selection process today, look for an EMM that offers these capabilities. Even if those features are not needed today, it is almost certainly the next set of features enterprises will look for and need to adopt. The Quick Scorecard If you can’t answer “yes” to these with your selected EMM/MDM, you’re taking unnecessary risk: Can your EMM install a specific APK build directly to AEDO devices? Can you canary a new version to one site, schedule a 2 a.m. cutover, and roll back instantly if needed? Can you push a JSON config change and a DataWedge .db to 500 devices in under 10 minutes—no manual touches? Can support remotely control the screen and pull logs/files from the same session? Can you execute Zebra MX XML, enforce kiosk/lockdown, and set scanner behavior centrally across models? Can you deploy LifeGuard/.ZIP OS updates by group, with maintenance windows and rollback? Can you enroll with StageNow barcodes (AEDO) instead of relying on ZTE flows designed for non-rugged scenarios? Can you operate cleanly in sites with limited/blocked Google services, including offline managed config workflows? Bottom Line A capable rugged EMM/MDM gives you deterministic control over versions, files, firmware, and front-line support—at fleet scale and on your schedule. Prioritize direct APK delivery, file distribution, OEM-level controls, Remote Control, AEDO barcode enrollment, and firmware orchestration. Deprioritize BYOD-first tools and any workflow that forces you through black box Play timing or pushes enrollment burden to associates on the floor. I’d love to hear what the comments have to say. Am I way off base? Do you fundamentally disagree? Or were you nodding along as you read through this. Let me know below! Oh and "AI", forgot to mention the buzzword. Matt
Forced Auto Install Issues
Since mid-November '25, forced auto install is not functional for our organization. Apps are loaded and installable as work apps but do not progress as an auto install from our policy. Has anyone experienced a similar issue? No policy changes, no SW updates on the MDM client. Functionality just stopped working.
[Day 2] Mission Intune : When Migration Becomes a Mission (Almost) Impossible
Good Morning Everyone 🕵️ Deep within the digital infrastructure, a high-stakes mission is being prepped. Five mobility experts have been deployed to solve a massive puzzle: migrating tens of thousands of smartphones to Microsoft Intune. The Goal: Ensure a fluid, secure, and uninterrupted transition for thousands of users. The Battlefront: A complex landscape filled with legacy policies, mixed configurations, and strict deadlines. It’s a race against the clock where one wrong move could start a domino effect. From scripts to security protocols—nothing is left to chance. Failure is not an option. Following Broadcom’s acquisition of VMware in 2023, the Workspace ONE product is now owned by Omnissa. Broadcom’s commercial strategy, which has influenced its spin-off companies, had become highly aggressive toward all customers. Consequently, we have decided to migrate the management of our Android and iOS tertiary fleet to Microsoft Intune.. While we are familiar with Intune, several limitations should be noted: Reporting: Intune offers basic reporting through Microsoft Endpoint Manager and Power BI integration, but lacks the advanced, customizable dashboards available in Workspace ONE. Deployment Performance: Application and configuration deployments can be slow, with status updates often delayed due to Intune’s reliance on periodic device check-ins rather than real-time communication. iOS Management: Intune provides full functionality only for devices enrolled via Apple Business Manager (ABM). Non-ABM devices have restricted supervision capabilities, limiting advanced configuration and app deployment. Error Handling: Intune does not display granular error codes in its console. Troubleshooting often requires log collection from the device or use of Microsoft Support tools, increasing diagnostic complexity. Conditional Access & Compliance: Intune integrates tightly with Azure AD for conditional access policies, which is a strength, but requires additional configuration and licensing for advanced scenarios. App Protection Policies: Strong for Microsoft 365 apps, but less flexible for third-party apps compared to Workspace ONE. Migration Strategy Overview The project aims to migrate the entire mobile fleet—a few tens of thousands Android and some iOs devices—between September 2023 and December 2024. Cybersecurity requirements mandate a shift from COBO (with personal Google accounts allowed) to COPE, reinforcing corporate control and reducing exposure to security risks. Key Challenges Technical Constraints: Devices incompatible with Android 13 require hardware replacement. For most employees, migration involves full device reset and Intune re-enrollment—a complex, time-consuming process. Security Limitations: Backup tools cannot be authorized, increasing the risk of data loss and user errors. A recurring issue is failure to remove Microsoft Authenticator configurations, creating significant support overhead. Performance Impact: The Samsung Galaxy A32, previously adequate under COBO, performs poorly under COPE, affecting user experience. Status and Strategic Decision By June 2024, progress is far below target. To mitigate operational disruption and support overload, the strategy shifts: forced migrations are discontinued. Migration now occurs only during: Hardware replacement (obsolescence, failure, or breakage) Voluntary device reset This approach prioritizes stability and resource optimization while maintaining compliance with security standards. We’ve been with Intune for almost two years, we make do with it and we are hardly surprised anymore when something doesn’t work. If you have any questions, don't hesitate to reach out via the comments below Kris
Enable ADB debugging is grayed out - This setting is managed by your administrator
This issue was documented in 2021 but with no solution. My Chromebook is managed by my company and I am the manager. But Google tries to find the managed option to unlock for this to work in the administration interface for more than 15 days without success. By the way there are thousands of options in the admin interface it could be a clever feature to number them. If you are in front of the same issue please add your comments to this post. I hope that Google support will succeed to solve the issue soon because I developed my first app for Android on my Chromebook with Android Studio and I was able to download it to my phone before these 15 days.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
Fido2 key and their issues using them on Android
First, do Android support using Fido2 keys on Android? Yes, it does support both using bluetooth, NFC and USB authentication. For reference: https://developers.google.com/identity/fido/android/native-apps But does it mean that it is straight forward to use it in a enterprise environment without hiccups? No, the support lacks many features that both Windows and iOS has supported for long time. If I buy a modern Fido2 with OTP support, will it work straight out of the box for using the USB? No, you need to disable the OTP support first. Here is how you can do that from yubikey manager, this works for Yubikey. Other vendors might have something similar. But for Fido2 keys without OTP support, it should work out of the box for USB-C, like Google titan. Why this happens, dont know. Can we use NFC for Entra ID authentication like we can on Windows and iOS? No. Android does not currently support CTAP2 for NFC, only for USB-C input. CTAP1 (FIDO U2F) supports certificate based authentication, but CTAP supports user verification with PIN and biometrics. Entra ID requires UV (user verification) before accepting login. As far as I know, there is also support for bluetooth. But I dont have any fido2 keys that support bluetooth yet. So why does this matter? With Android you can have shared devices with secure login for multiple users with a single log in for all supported apps, auto log off and many other possibilities. https://learn.microsoft.com/en-us/entra/identity-platform/msal-shared-devices Other sources/discussions: https://www.reddit.com/r/yubikey/comments/1oncuh2/whats_the_point_of_nfc_on_android/ https://www.reddit.com/r/yubikey/comments/13tlzoc/fido2_inconsistent_across_windowsandroid/ https://fidoalliance.org/specifications/No accounts found Zero touch
as per : ZTE Portal - no account found | Android Enterprise and ChromeOS Customer Communities - 4093 I'm an admin of a Google workspace instance, let's call it Acme, LLC. This is Google Workspace Business Plus I'm an admin (not owner) of a Android Zero Touch instance, with the ability to make changes to: Configs Devices Users Resellers, etc I've logged into Workspace.google.com for Acme, Inc. Gone to Devices, Mobile & Endpoints, Settings, Enrollment, Manage Zero Touch devices, Link, log in using AZTE user and get the rather lovely: MDM is set to advanced, by the way
Android Enterprise Partner Application/Quota Status
Hi, We own and manage an asset management solution used by various clients. Recently (in the last 12 months) we have implemented an MDM/EMM type of solution that uses the Android Management API to enrol/register devices and assist clients with their asset management processes and managing risk through the Android Management API. Now, from an Android Management API perspective, we understand the permissible usage policies and believe we do comply with the requirement. When we originally started the endeavour, the quota on how many device can be registered was a default of 500 devices. We recently noted when some clients try to enrol/register devices, that during the set up process on their devices, that it states that they have reached the usage capacity limits. When we checked the project(s) associated with the clients, most have between 200 - 380 devices enrolled/registered which is below the 500 device qouta. More recently, we noted that the Android Management API permissible usage policies were changed/updated on 29 October 2025 from a default of 500 devices to having to request an initial quota of 500. This means that that enterprises or projects we have recently set up would fail. We submit a request for a quota increase on earlier projects and a request for an initial quota on a new project. This was more than a week, or 7 working days, ago. We also submit an application to become and Android Enterprise Partner on the 12th of November 2025 which we received a response with additional questions about two days later which we responded to promptly. The challenge here is managing client expectations and frustrations in not being able to enroll/register and additional devices, with one client looking to enrol/register over 5000 devices and another prospective client having over 15000 devices. Is there any way we can see the progress on the quota increase/initial quota requests and progress of the partner application or whether there is any other questions or concerns we can remediate to move forward? Its been a challenging week trying to manage our frustrated clients and really want to use the Android Management API and Android Enterprise much more in the future but the limitations are prohibiting us from doing so. Any assistance or perhaps someone we can contact would be appreciated.My application was rejected
Hello, good afternoon everyone. I'm writing to this forum to ask for help. A few weeks ago, I applied for the EMM and Enterprise Android Partner program. My application was rejected without any explanation in the emails. I'd like to know the requirements to join the program. We are a development company based in Guatemala and the United States (and soon in Mexico and Colombia), as we currently have a client requesting an MDM system for their Android device retail store. This is our first time applying to this program so we can offer our services to this client and any future clients who might be interested. If you could send me the program requirements so I can apply correctly, I would be very grateful. Have a good afternoon. Greetings from Guatemala.
Custom DPC app being blocked by google play services
Hi We have a custom MDM app which was built to enroll android devices with Device Owner. We have a backend which serves the configuration requires to install/block apps and settings. We are not using Android official management APIs, A few days ago we received a google play protect update on some of our devices and now whenever we try to enroll the devices using QR code enrollment it gets blocked by google play protect. Please help us understand what is required to bypass this so that we can continue to use our custom MDM app. thanks!
