Would you underpin the management of a massive fleet to a technology with its roots in the 1960s? Believe it or not, that’s fairly common for certain dedicated device use cases, presenting a challenge for modern-day IT Operators to manage at scale, resulting in disproportionate resource burn compared to a more modern alternative.
Join me for a story about how Esper helped a customer in the retail industry utilize Esper’s and Google’s infrastructure to modernize such a solution using Android.
State of Config
The beginning of the configuration file is a bit murky. It likely started with the IBM Job Control Language (JCL) from the 1960s, instructing an IBM mainframe on how to run a job — it wasn’t a true configuration file, but it functioned similarly by laying out the execution parameters. Then came UNIX’s /etc/rc, which managed system startup scripts and configurations. Next was DOS’s config.sys, which configured the operating system’s hardware and software settings at boot (that’s when I started editing a config file). And, of course, there’s win.ini, which became the Windows registry — everyone’s favorite!
The key point is that we’re talking about a standalone piece of hardware where the config file was handcrafted for the hardware and use case at hand. The concept of fleet management was not mainstream — it was one person, one system. Config away.
AIDC (Automatic Identification and Data Capture) devices got their start during the transitionary period from non-networked to networked devices as wireless technologies advanced. These devices and the associated line-of-business applications require configuration in order to properly use the bar code scanner, spanning barcode symbologies and parameters, trigger modes, profiles, intent outputs, data formatting, user feedback, and more. This configuration was achieved via a config file, which in the early days worked fine. Fleets were small, and config files were actually more efficient than going through a UI to configure an AIDC device.
Config files were expanded to handle other “configuration” needs, and oftentimes proprietary configurations were built for enterprise apps. Config files proliferated.
In parallel, MDMs came along, evolving to offer the ability to push configuration files to devices, and even edit and modify them remotely — one device at a time. It fit very well into the “patch” approach IT Ops lived and breathed by for Windows.
Yet the config file was cemented as the mechanism for the majority of dedicated device configuration scenarios, resulting in lots of enterprise code and ingrained IT Ops processes around these use cases. Of course, MDMs catered (and still do) to these use cases as it is a major part of the IT Op day-to-day function. AIDC OEMs stepped up to improve the situation, like Zebra’s XML-based configuration file format via StageNow. But the core mechanism remained the same.
Google came to the rescue with infrastructure for a more modern approach! With Android Lollipop (5.0) in 2014, Google released application restrictions, which evolved to become Managed Configurations — an OS-level service that is part of the Android Enterprise framework and AOSP. It initially enabled IT Ops to tailor app behavior to meet corporate policy requirements, but quickly evolved, offering a set of capabilities that make it far superior to the config file approach:
- Centralized and remote management at scale: Instead of pushing a file, you can use an MDM via Google’s Play Store infrastructure to push Managed Configurations upon provisioning and then change them on devices in the field. No manual copying and editing of a file required.
- Security and Compliance: Via your MDM, you can enforce policies to prevent unauthorized modification of configurations, as this is all OS-level enforced. You don’t have to ship API Keys or auth tokens via local files. There is no file to tamper with!
- Dynamic and Real-Time Updates: IT Ops can update configurations remotely, without requiring user interactions or a multi-step process (like push file, then fire intent to get app to ingest). Changes happen instantly without restarting the application.
- Consistency and Scalability: Unlike config files, which you need to copy to each device, managed configuration is structured as key-value pairs in a JSON format. While it’s possible to create a DevOps job that can create and manage config files at scale, why bother? Instead, you can have a completely code driven approach via JSON using Android Enterprise and achieve true DevOps for devices, yet still make it easily available to the IT Operator for troubleshooting as well as deployment.
As you can see, an MDM is required because the MDM is talking to the Android OS, and that conduit is only available for Android Enterprise MDMs on GMS. Esper happens to be one of these MDMs of course — Silver Partner (noting we are not Gold because we focus only on dedicated use cases, nothing personal here!).
The direction from Google is that modern applications should be built to utilize managed configuration instead of config files, so there’s some work there that not everyone has been up for, given competing priorities and well worn IT OPs runbooks.
A big blocker has been AOSP. It's common for customers to have a mix of GMS and AOSP-based devices, which poses a problem for migrating to managed config, as most MDM providers only support this on GMS via Managed Google Play. Thus, customers were blocked from extending this nifty approach to their AOSP fleet with a typical MDM. To their delight, they discovered with Esper that’s not the case.
We saw the power of managed config and implemented our infrastructure to utilize AOSP’s support for it. With this, managed config can be built into and utilized by enterprise Android apps, whether they run on AOSP and GMS. Yes, that’s right, Esper brought the power of managed config to AOSP!
Now let’s get into this particular situation.
One Customer, Tens of Thousands of Config Files!
Imagine a customer with a large retail operation. They utilize AIDC devices for the typical use case of back-of-house, the storeroom with inventory, and such. Their OEM mix is typical — while not detailing their specific mix, we’ve seen similar setups many times: Zebra, Honeywell, Datalogic, Urovo, Newland, Bluebird, etc. The OEMs do not matter so much, as you are dealing with a mix of them.
They build their own enterprise app set for use at their retail locations. Over time, the use cases for these device types started to cross over into the front-of-house — enabling store personnel to check available sizes and inventory directly on the retail floor to create a better customer experience, for example. Then comes self-service, letting end customers utilize these devices for part of their shopping engagement. What previously was an employee-only use case is now something exposed to their customers. With that, the bar went much higher in terms of providing a smooth experience, utilizing the latest Android technology and corresponding OS releases. You are not going to do this on Android 11, which you could previously get away with when only employees were using the devices.
Since they develop their app set in house, for years they relied on config files. And these config files are bespoke to each device, containing device and store identifiers so they know exactly which device each app instance is running, and pack it with specific network information for each deployment location. This is in addition to the standard configuration parameters used for a bar code device.
Their IT processes were built around a unique configuration file for each device, which became a huge management nightmare for them — both from a build and maintenance perspective, as well as utilizing the incumbent MDM to manage them all. The percentage of IT time spent on file management was crazy.
I’ll be honest with you here — we have been in competitive selling situations where we have received objections from operators because we don’t have the level of support for a manual method to edit files that reside on a device. We can actually do it with a bit more set up, but for us it doesn’t map to our mission of managing large dedicated device fleets at scale.
Remember those shoppers who started to use the endpoints in the front of house? The customer wanted to give them Android 13. But they ran into a problem with Android 13 — new restrictions with storage and the associated file system removed access to a storage section where this media file is located. Since this is the core architecture their entire enterprise application suite is based on, accommodating this change would require a huge development effort and significant changes to their IT operational flow.
They could temporarily avoid this by their apps targeting an older Android SDK version, thereby still gaining access to these otherwise closed off storage areas. The tradeoff is they could not offer the modern experiences they needed to for customer-facing use cases. And, eventually, the older Android SDK version of Android be sunsetted, thus the apps would no longer be able to work on the latest Android release. Either way, the clock is ticking.
Clearly something needed to change. That’s where managed config comes into play. Instead of using a configuration file, we worked with the customer to lay out how they could modernize their enterprise app set to utilize managed config instead. Since managed config is essentially code-based, it enables them to build and utilize a cloud-driven infrastructure that generates the specific JSON block bespoke to each device in an automated fashion — all via API.
So rather than get into the massive file building game with the involved runbook (build each config file, use MDM to push the config file to the proper location — that you can’t access anymore on Android 13 — and then coordinate the firing of an intent that you have to do mop up on afterwards), instead they utilize an OS-driven capability to push both base configurations and any changes to each device.
With Esper supporting managed config on AOSP, they were able to cover their entire fleet and are now protected from any future consumer-oriented security clampdowns that may come with future Android dessert upgrades on GMS as well.
But there was one problem: How could they coordinate the endpoint specific details in an automated fashion? With Android 10, applications were prevented from fetching details that could fingerprint a specific device, the prime example being the device’s serial number. Protecting the consumer comes at the expense of the corporate-owned dedicated device scenario.
That’s where the Esper Device SDK comes into play. Via the device SDK, their app can fetch the unique identifiers for that device including serial number, IMEIs, and MAC address. This creates a dynamic situation where the app itself can call the device SDK upon install, gather the unique identifier, and pass it back to the customer’s cloud system where the proper JSON payload can be generated without human touch, and then pushed via API to the app to achieve full configuration via managed config — including the bespoke aspects for a single device.
Conclusion
Google’s managed configuration provides a modern means to configure applications at scale for dedicated device use cases. Being a modern device management infrastructure provider, Esper focused on delivering robust support for managed config for the dedicated device use case.
Adopting managed config makes your development and operational workflow easier — no more worrying about permissions for files (remember, Android keeps removing/changing file level permissions as you upgrade the OS) and no operational nightmare!
One customer in the retail vertical with AIDC and thousands of configuration files becomes an automated process using managed config and the Esper device SDK across GMS and AOSP, in an OEM independent fashion.
This move won’t happen overnight, but now the customer is on the road to a truly scalable, manageable device fleet — Esper style!
If you’d like to try out a modern MDM yourself, sign up for an Esper free trial.
Learn more about how Esper supports Managed Config:
FAQ
Keep Exploring
.png)
-25.svg){kind=small}
