User Profile
mattdermody
Level 3.0: Honeycomb
Joined 2 years ago
User Widgets
Contributions
Re: [Day 3] Dedicated to Dedicated: Non-negotiables for EMM/MDM in Rugged Android Deployments
It can be possible in certain specific situations but is not always available. You can push a downgrade ZIP and an MX XML execution to process a downgrade via EMM. This will Enterprise Reset the device during this process which will in most cases orphan the device and force a re-enrollment into an EMM. If you architect certain parts of the solution like the EMM agent and Wifi network settings to be Enterprise Reset Persistent it can survive the Enterprise Reset and allow the device to reconnect to the EMM post downgrade. Granted it is not something you should depend on and it is certainly better to have proper hygiene around new version validation and controlled upgrades. It can however be useful in a pinch.[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. MattRe: [Day 1] Mobile Devices With a Sixth Sense: What Android Can Learn From Detection Dogs
I really love this concept of an established baseline combined with anomaly detection. So many of the compliance policies and profiles that are assigned are only there and in place after an extensive troubleshooting effort led to that particular stop gap or workaround as a solution to prevent a problem from occurring in the past. They are often written in blood, so to speak. As admins we have a lot of tools to stop the leak once it has started AND someone has told us about it. We tend to lack the proactive insights to let us know that a leak might be about to occur before it begins. Instead of just looking for x problem it would be great to have the added insight of noticeable changes detected from a given established baseline.Re: [Day 2] Mission Intune : When Migration Becomes a Mission (Almost) Impossible
I love this. Intune is not a "go to" it is a "have to". I've made it a personal mission to put as much content out as possible to warn others of the perils of Intune and am glad to hear similar horror stories being shared.Re: GBoard - Suggestion Strip
I do not have a case open with the EMM as it seemed to be an issue with Gboard specifically. This was evidenced by the fact that it was working perfectly fine previously in Gboard and it wasn't until an automatic push from Google Play to a new version did the previously working managed setting break. The suggestion strip was disabled properly on prior versions of Gboard and only started appearing again when Gboard was updated. I have even force uninstalled the upgraded Gboard to an older version packaged with the device firmware (v12.x) and that properly restored the desired adherence to the managed config setting to disable the suggestion strips. All of this seems to point to a bug with the Gboard app specifically and not an issue with the EMM and it's ability to apply managed configurations as far as I'm concerned. The EMM is SOTI MobiControl if that helps. Magcho what are you seeing this in?Re: DPC Extras issues
You can persist pretty much anything in the Enterprise directory on Zebra devices including EMM agents using Custom DPC. With that in mind if was enrolling a Zebra device I wouldn't be considering ZTE anyway since "Zero Touch" is a misnomer and I can enroll devices in a much more streamlined manner with Zebra StageNow.Re: GBoard - Suggestion Strip
I can confirm I am seeing this issue across a range of Gboard versions. This list is not definitive but I have seen it affecting these versions so far 15.8.4.793526320 15.9.1.799068799 16.0.5.804347959 16.0.6.804347959 16.0.7.804347959 16.0.8.804347959 16.0.9.804347959 16.0.11.804347959 16.1.1.809934391 I can confirm that "Show suggestion strip" is disabled in Managed Configurations but it is showing as enabled still on the device itself under Gboard settings. If I manually disable it on the device the bar disappears as desired. There appears to be a bug affecting Gboard's Managed Configurations.Custom app installation with AMAPI
Thanks to the keen eye of jasonbayton for spotting this update in the documentation: https://developers.google.com/android/management/manage-custom-apps The lack of this feature has been a key reason I've avoided any AMAPI based EMM (looking at you Intune!) for fully managed device deployments. This is certainly a welcome enhancement to AMAPI and one that I'm honestly surprised Google delivered on. I think I can finally see the writing on the wall that Custom DPC will eventually now die given that AMAPI is finally catching up. I still need file system push and pull for it to truly be a replacement but this is a major step in the right direction. What are the community thoughts on the matter?Re: Google Play update: new layer of security coming in 2026
Echoing what jasonbayton has already said, this is incredible news. Especially point #2: 2. Applications installed by EMM Device Policy Controllers (DPCs) will be exempt from requiring developer verification indefinitely. (For example, apps installed via Workspace ONE Intelligent Hub, Intune Company Portal, SOTI MobiControl, etc.)Re: [Announcement] Launching Android Enterprise Insiders & Registration
VERY Interested. Not sure if it matters but I have ~150 Org Ids across all of the different environments I manage. I can put an Org Id from one of my test EMM environments but I don't think that's going to be representative of the scale of environments that I interact with.Re: Android Developer Verification Requirements in AE
I would love for the same blanket exception that was applied to GPP to also be applied in this circumstance for apps installed on Fully Managed devices by a Device Owner DPC. In that situation an enterprise admin is electing to install a business app on assets owned by the same enterprise they do not need or want Google sitting in the middle of that dictating what they are or are not allowed to install on their own devices.Re: Disable random mac address during EMM enrollment
I am happy to hear this is acknowledged as an issue and it is being reviewed as a potential future DPC extra. With that being said, even with that possibly getting taken up, I suspect an actual resolution for AFahmy to be far away and likely out of reach on the current devices. I could be mistaken about this but introducing a new DPC extra that the device recognizes and leverages during the SUW would likely require an upgrade to the device OS first. I would therefore not get your hopes up about getting a solve for this particular batch of devices that is being deployed. It sounds like this issue might be resolved in the future on future OS versions through a DPC extra during the SUW but you may not have any options on your current devices. If it were me I would be exploring alternative staging networks for the equipment that are not MAC filtered / allow random MACs. If your OEM has an OEMConfig that supports MAC randomization disablement you can then apply that after the initial staging and enrollment process. You otherwise are going to be hard pressed to have MAC randomization disabled during that initial setup process when the device is first connected to the network.
