Android device management and Android MDM are challenging to shop for. Dedicated devices like Android kiosks, point of sale systems, and even many consumer electronics require more powerful and sophisticated tools for management than traditional Android MDM (Mobile Device Management) solutions are capable of providing.

If your Android device management needs are complex — supporting mission critical dedicated devices like ordering kiosks, building software for multiple hardware targets, and distributing that software across many locations — there are key considerations you must make before deciding on an Android device management solution, and reasons you may want to go beyond a basic Android MDM and toward a full stack Android device management solution.

Do I need Android device management?

Do you have a group of Android devices that you want to control, doing things like restricting access to settings or apps, or to forcing the screen to stay on indefinitely? Then congratulations, you need Android device management! But first, let’s talk about what we mean when we say “Android device.”

First, is your Android device running “Android” (that is, with GMS), or is it running AOSP (without GMS)? If you’re not sure, check out our guide on GMS vs non-GMS.

If you’re using an Android device with GMS, you can start managing that device immediately with a tool like Esper for free. And even if your device doesn’t have GMS, it’s likely our platform supports it, but there’s more you should know.

Android device management for non-GMS (AOSP) devices

When you talk about “non-GMS” Android devices, you’re talking about devices running “AOSP.” The Android Open Source Project (known as AOSP) is the fully open source version of the Android OS, and it underpins more devices in more scenarios than it’s likely reasonable to list in a single place.

Manufacturers can utilize the open source code Google publishes as part of AOSP to assemble an OS, and Google has little control over these AOSP devices. And because they lack Google’s own mobile services and applications, they often too lack the necessary cloud APIs and support infrastructure to enable OTA application updates and firmware over the air (FOTA) updates — and this is where major device management challenges can begin.

But AOSP can also enable huge opportunities, as the platform offers a huge library of APIs and supporting documentation, a ready-made UI, basic stock applications, and cross-platform development tools.

Designed to receive FOTA upgrades in place (with minimal disruption using features like A/B system partitioning), AOSP can let you build devices that can meaningfully improve and iterate in the field with software and firmware innovations that are fully under your control.

Does Android device management let me control OTA / FOTA updates?

Deploying updates to the apps on your devices sounds simple enough, right? But if you need that app to roll out to specific groups of devices, with specific builds for particular hardware targets, and inside a specific timeframe (on a regular schedule), no traditional Android MDM is going to give you the tools to do it the right way. Even the Google Play Store (for GMS devices) isn’t a great fit if you need this level of precision and reliability when deploying software updates to devices.

Similarly, the ability to upgrade your fleet’s firmware over the air is a huge technical advantage. And much of the Android FOTA infrastructure problem has been solved … for Android smartphones. High-end handsets from Samsung and Google receive monthly firmware updates with security fixes, quarterly maintenance releases, and annual OS upgrades. Applications update seamlessly in the background, with the user rarely the wiser. Achieving similar results on a dedicated Android or AOSP system like a stationary kiosk, though, presents major challenges.

If you want to update the firmware on a retail store kiosk, you’ll need a distribution platform and infrastructure to manage it (read: a cloud). And what happens when something inevitably goes wrong? If your device’s manufacturer upgrades your firmware and it breaks a mission critical application, who do you turn to? Frequently, the answer is “no one.” Most device OEMs aren’t interested in bespoke firmware support (not unless you’re ordering in some truly huge quantities), and even if they were, don’t have tools designed to be used by third parties to manage these processes (let alone manage them precisely). Many won’t even allow you to opt out of upgrades you don’t want.

Advanced Android device management: Custom firmware

Once you have control over your AOSP firmware, OTA, and FOTA strategy, an entire world of new possibilities opens up. Your devices become fully manageable objects, allowing an incredible degree of control and customization. There are new challenges, too, but frankly, they’re the kind you want to have (when you have the tools to address them).

Most companies using AOSP to build firmware for their devices never have this “moment.” Instead, they’re frequently locked into the MDM waterfall software deployment cycle, in which a very fragile, very user-unfriendly, but very cheap management interface will allow you to deploy applications and set policy from the cloud well enough to reach your devices at a theoretically massive scale.*

(*Eventually. And probably not actually all of them. And you won’t actually know which ones received that update, or why they didn’t get it, or whether there’s something you could have even done to prevent a botched rollout in the first place… unless you decide to build all this telemetry yourself.)

MDMs have their place for things like managed personal devices, but when it comes to testing updates precisely, deploying at scale aggressively, and continuously monitoring rollouts, existing MDMs offer you little more than a batch script with PR.

Is Android device management easier with GMS?

If you’re disappointed by Android MDM offerings, you’ve likely investigated how easy it would be to just become GMS certified and roll with Google’s Play ecosystem and tools. For some companies, this is the best way to get there. If your timeline for certification isn’t tight, and if the Play Store is going to provide a major content value add to your device, Google has a path for you. But if your device is unusual in some way, or otherwise not cut in the cloth of a typical Android smartphone, you may start hitting some pretty big snags.

This post provides a thorough overview of how to think about building a GMS versus non-GMS Android device, which involves passing some extremely rigorous automated test suites. You can also check out Google’s CDD (Compatibility Definition Document). Consider it the ever-evolving sacred stone tablet that defines just what a “true” Android device is and will be, often forecasting changes years into the future. (Hey, nobody said building a multi-billion device ecosystem wouldn’t result in some seriously hefty documentation.)

Is there an Android device management (MDM) alternative?

Traditional Android device management won’t meet the needs of many devices and businesses. But you need to understand why.

Looked at from the lens of traditional Android MDM fleet management, app updates and FOTA are levers to be pulled, with the resulting fallout of failed end deployments to be managed and triaged — a sea of nails just begging for IT hammers (like a human being who has to go on-site and troubleshoot a botched device update directly). Dealt with ad hoc, the problems of deployment can be mitigated and managed with MDM tools to a degree, but you’ll never truly escape the inherently crude, indiscriminate nature of those daunting deployment levers.

Once you’ve accepted that “necessary evil,” it’s easy to brush off other solutions as more trouble and cost than a migration would be worth. But if you added up all the hours you spent trying to make that square MDM peg fit into a round Android device management hole (and all the time your dev team could be spending on iterating software instead of software deployment), we strongly believe most orgs would see the math differently. Practicing proper Android DevOps would not only save them money, they’d create better products for their customers — and be able to do so faster and with far greater flexibility of scale.

If you’re ready to take the Android DevOps plunge, come talk to us.