If you’ve ever worked with an MDM (Mobile Device Management) to build and manage an Android device fleet, you know how one-sided that relationship becomes once your hardware is in the field. You also know that’s because MDMs are built on a model that chiefly rewards shipping devices, not supporting them. It’s hard to blame them, either — in a world where getting devices to the edge has become a critical concern across dozens of industries, hardware talks. But if you’re scaling a mission critical Android device fleet, you’re already asking the kind of hard questions your MDM probably isn’t very eager to answer.
Why can’t I opt out of FOTA updates, or at least manage my own validation and rollout?
Anyone supporting devices in the field knows that the worst update is the one you didn’t know you were getting. Traditional MDMs aren’t interested in helping you responsibly deploy new firmware across your fleet, they’re interested in deploying it across their fleet. With dozens or even hundreds of customers all relying on the same hardware platform, MDMs are incentivized to provide a “one size fits all” approach to updates. When that update happens to reach your fleet, you’re left to either find a band-aid — a way to block the update — or take it. We don’t think this is very good!
At Esper, we’re built on a DevOps philosophy, and that’s exactly how we approach Android updates on our Esper Foundation for Android OS. We understand that organizations aren’t all alike; some may receive no benefit from updating a device to the latest Android platform version, while others may only want to deploy an update to a small subset of their fleet for testing (and some might even want rolling nightly builds). Whatever your philosophy about updates, Esper gives you the tools to manage and deploy them exactly when and where you want. You manage your software with an exacting degree of control — we think updating your fleet should feel exactly the same way. And we don’t see a way to do that without putting you in the driver’s seat of your fleet’s OTA strategy.
That’s why if you choose Esper Foundation for Android, you’ll have a partner in the Android business. We’re not just building a deployment and management platform, we’re building an operating system that is growing with our customers, their use cases, and the mission-critical roles their hardware fulfills. MDMs, by contrast, aren’t motivated by individual customer stories, and neither is their Android update philosophy.
Where are my “monthly” security patches?
If the update you really don’t want is the worst one, we all know which one takes second prize: The update you do want that doesn’t show up. Android devices — with or without GMS (Google Mobile Services) — are all eligible to receive Google’s monthly security patches. These patches address exploits that could leave your Android device fleet vulnerable, and (in most cases) should be deployed as soon as practical.
If you work with a traditional Android MDM, you just won’t get regular security patches. Top tier OEMs like Samsung may provide patches extremely quickly, but this is the exception, not the rule. Whether your MDM even offers patches is often beside the point, because it is the reliability and predictability of those updates that is so crucial from a device security standpoint. But missing Android security patches are going to be little more than a nuisance — and your MDM knows that. Like a strong password, you’re only going to miss that security patch when something goes very, very wrong. And while it may not be mission critical today, five years from now, you’ll want the peace of mind that your Android fleet is still protected.
With Esper Foundation for Android (Foundation), we offer a better way to keep your fleet secure today — and long into the future. We give our Foundation customers access to Android security patches within 30 days of their publication by Google. And for Foundation on x86, we give you up to ten years of updates. To learn more about what we’re building with Foundation (including on x86), check out this page.
Why can’t your management console just let me do… anything?
Managing your Android fleet with a typical MDM’s tools could be described, charitably, as a challenge. It’s doubtful anyone is truly happy with the tools their MDM provides for fleet management, and that’s why we built an incredibly powerful and customizable console. I could go on about why MDM consoles are underwhelming, but it’s probably easier just to tell you what ours can do.
You already know we support staged OTA updates, but how “staged” are we talking, here? With our console’s advanced pipelining tools, your subgroups can have subgroups (dawg). Only want your next application update going to the top 10% of your devices by engagement, and only then among those devices on the latest hardware revision that are also in a particular market or office? With Esper’s console, you can build it. We understand that the way you grow and scale your fleet is going to change the way you manage and deploy software as the complexity of that fleet grows. Pipelines also allow you to execute tasks on select groups of devices, like sending a reboot command to every device in the lab, or pushing an application update en masse out into the field.
We also understand that fleet management is a human challenge, and that maintaining and deploying Android devices with arcane MDM tools can slow down your business. Just as there’s no reason you shouldn’t be able to control your own OTAs, there’s no reason your team should have to spend weeks deploying the latest application build to devices out in the field, one by one.
Esper and Esper Foundation for Android were built on a simple truth: You know what’s best for your fleet. Your MDM was built on what’s best for theirs. That’s why Esper and Foundation are uniquely positioned to realize the kind of complex Android device deployment and management scenarios an MDM simply can’t.
Why am I stuck with your basket of hardware?
We established that when it comes to speed, MDMs can have a lot to offer. But that speed is meaningless if it can’t be applied effectively to solving your unique problems. If you need to iterate rapidly on hardware or support an extreme variety of form factors and use cases, a traditional MDM can leave you feeling locked in. As your company matures and evolves, so too will your needs from hardware partners, and MDMs are notoriously inflexible. That inflexibility could cost your business serious time and money.
No one wants to make the wrong bet when it comes to a platform, but with your MDM, you may be making a platform choice you’re not even fully aware you have the power to change. If your product development cycle pivots, it logically follows that your Android fleet management should be able to easily pivot with you. But with an MDM, your options for iterating and diversifying your hardware are on their schedule, not yours. This can present a difficult choice: switching MDMs entirely — and good luck with that migration of your existing fleet — or choosing a potentially suboptimal solution in order to avoid a huge headache.
Esper doesn’t think your product roadmap should be subject to the whims of a single partner. With the Esper console and Esper Foundation for Android, we’re setting you up to build and iterate for years to come — regardless of what “flavor” of Android you run or which hardware you choose to do it on. We practice what we preach, too: Esper is designed to manage the full gamut of Android devices, from consumer-grade GMS handsets to headless display signage running customized AOSP. We even support Android on x86 (no, really — ask us about it).
In five years, it’s probably hard to predict what your Android device fleet will look like. We want to make sure that no matter how diverse your hardware becomes, deploying and managing it will always be a seamless affair (unless you’re building smart pants, in which case, seams are advised). For more on Esper’s hardware compatibility, just head here.
Who is going to provision all this stuff?
I’ve been there: a brand-new shipment of machines arrives from your manufacturer, and that means someone is on provisioning duty. Understandably, your MDM really can’t be bothered to solve for the pain of deploying 800 devices in the field, each of which must likely go through a one-time setup process. Even Google’s own “Zero touch enrollment” for Android devices is not truly zero-touch, requiring some level of user input in order to connect to the internet and start the enrollment process.
With Esper Foundation for Android, you can build truly seamless, touchless provisioning (let us show you). Just ask our customers, one of whom is dropshipping devices straight into the field — power it on, and the device handles the rest, using our predefined configuration options in Foundation. Esper can even achieve this wirelessly: you can ship straight from the factory with a set of predefined network configurations, meaning your device can immediately connect on boot, and you can immediately begin managing it — a key consideration as more businesses explore the possibilities of 5G. From there, you can push app updates, pull device info, reboot, or start an OTA. That is true zero-touch.
It’s hard for us to overstate what a game changer touchless provisioning can be for fleets, and we hope you agree.
Am I getting on an airplane to debug?
Deployment on paper is not deployment in practice. Imagine, you’ve just kitted a hundred new devices and promptly shipped them out into the field. Two days later, you see ninety-seven of those new devices up and running error-free in your console, and you’ve got three trouble tickets. You try remote diagnosis, rebooting, and even to teach someone in the field how to generate a logcat (this, predictably, does not go well).
I made a career out of getting on airplanes to touch Android devices. You probably do not share my ambition. That’s why Esper Foundation for Android, in conjunction with our console and Foundation SDK, lets you do the kind of things remotely that just make sense. Want to livestream a logcat while the user is replicating an issue? We can do that. Just need to take over touch control? Easily done. Start a remote ADB session? Easy. We even can provide real-time outage alerts for your entire fleet, so you can spot problems before they’re… Problems.
As your Android fleet expands, the ability to remotely diagnose and resolve issues is crucial to meeting the challenge of scalability. We’re Android people, and we’re leveraging the power of that platform to build the kind of tools we would want as an Android fleet customer ourselves. Getting rid of the kind of work no one really wants to be doing — like flying across the country just to figure out someone entered a password wrong — is pretty high on our list.
How bad would a migration to Esper from my MDM actually be?
Not very! Nobody likes migrations, but we’ve worked to ensure the process for switching to Esper from your existing MDM solution is as simple as possible. We can get your existing Android fleet up and running in the Esper console (FYI: we can support very old versions of Android, all the way back to 4.4), potentially in a matter of days.
Want to know more about what we’re building?
Well, same. We thrive on the diversity of devices and applications our customers bring to us, because we believe the Android platform is ready to tackle the many tough problems true edge devices present. Managing that growth and scale is the challenge we know we’re uniquely able to solve, and we’d love to talk with you about what you’re creating, and how Esper can help you build it faster, stronger, and more sustainably.
And did I mention that this is just the tip of the iceberg? Esper is certainly happy to replace or augment your existing MDM, but we can offer so much more. Have a question? Just wondering how you can try Esper out? Want to build Foundation for a device in your lab? Get in touch and set up a demo, we’re happy to help.