We talk a lot about DevOps for Android at Esper. But without deep dev tools, that vision is but a vapor. More fundamentally, managing massive fleets requires a code-driven approach. And while an important component, a system centered around a web-based console doesn’t cut it at scale.
Every facet of Esper’s platform is fortified with developer tooling — from our cloud down to Esper Foundation for Android. Whether you’re a cloud dev, DevOps engineer, Android developer, Android OS engineer, or an IT pro, the Esper platform allows you to focus on using code to automate workflows and add new capabilities. With our tools, you have precise control over your entire development process, and you’ll be able to easily implement critical functionality at scale because they’re already in place. If you’re a developer involved in building a modern solution driving an Android fleet, we think Esper is the obvious choice across a variety of roles and needs.
We’ve broken down how different developer roles can take advantage of Esper’s tooling (while understanding that, at times, there will be an overlap of the roles and the tools used.)
Cloud developers have been an afterthought for traditional MDM systems. The reason is obvious: MDM was built for BYOD (Bring Your Own Device), which is a function traditionally handled by IT. However, as dedicated Android device fleets increasingly become a core part of business infrastructure, being able to integrate a management platform with your cloud is absolutely critical to success. And it needs to be in the native form you expect — REST.
Esper Cloud APIs
Our cloud APIs bring fleet management into your modern cloud-based solutions using the industry REST standard. You can make your Android devices first-class citizens in your automated solution, and cloud developers can closely coordinate a cloud-driven solution at a granular device level. Device telemetry can be used to drive automated configuration changes on the fly in a dynamic fashion — and much more, it’s up to you.
(We have a CLI and Python SDK too – keep reading!)
DevOps engineers are responsible for the automation of processes in a cloud-driven, app-centric solution. Most DevOps engineers have never even thought about device management. And why should they? There was nothing to automate!
Now with Esper, you can use our REST APIs to tap into your existing automated build process. Automatically upload new app builds to the Esper Cloud. Use our pipeline service to define stages via API to push first into your test lab, canaries, and then a staged customer rollout — blast radius limited! Tie into device telemetry to roll-forward, and use device and app telemetry to stop (rollback is on the way — stay tuned). The Esper App Cloud and app install APIs are available now, with pipeline APIs currently available to select preview users.
Dedicated Android app developer
Most Android developers only care about the Android SDK and the target Android API level. Android developers targeting dedicated device use cases have been underserved. While Android provides fine tooling for consumer and enterprise app development, there are real canyons to bridge for dedicated apps.
Android is designed for consumers, and many OS-level capabilities are walled off to Android application developers. But dedicated devices are corporate assets, driving critical revenue or business operations that require deeper access and greater control. The Esper Device SDK fills that gap, exposing APIs on Esper-managed devices that enable new capabilities and use cases previously unavailable to the Android app developer. Simple examples include fetching the device’s serial number for precise alignment with your cloud implementation, full control over exposing curated system settings, or self-configuration of APNs for mobile data scenarios. And if something is missing that makes sense for us to expose, we’re all ears.
Esper Android Studio plugin
Android developers live in Android Studio. You tend to interactively build your app, and need to get it into the test lab. Our Android Studio plugin lets you directly upload your APK to the Esper cloud, making it easy to install on your device fleet. If you work with your DevOps engineer (as you should), your upload can trigger a pipeline for automated test lab and canary deployment. Slick, and code-driven!
Android Studio has great emulator coverage. Just one problem: They’re almost exclusively centered on consumer device types. In the dedicated device world, the Android devices you target can be very non-standard. With unusual display sizes and resolutions, special interface features, and heavily customized OS builds, they often bear little resemblance to their smartphone kin. Furthermore, obtaining the actual hardware for testing can be challenging, forcing developers to kludge by targeting imperfectly matched emulators. To help, we’ve built emulators for AOSP and Foundation that you can install in Android Studio. For larger customers, we can help you create a custom emulator for your specific hardware to light up large application development teams and specialized ISVs that want to target your bespoke hardware.
Developers love the command line. Who doesn’t feel the power pulling up the command prompt to fire up an adb session? As you grind on getting your app to run on the target hardware, you can interact with our cloud via the CLI to do things like manually push app builds, change device configurations, and even factory reset if you happen to pull a foobar (Editor’s note: Keith, don’t make me Google developer slang). All nicely fit into the Android Studio IDE. Of course, you can go to the terminal at any time — code as you like, it’s your life.
Secure remote ADB
Ugh! You got the call: Your app is crashing and you have no idea why. Your user on the other end thinks a bug report is about the cicada plague last summer. No worries!
For all Foundation devices (and other select devices from our OEM partners), you can initiate a secure, fully remote adb session without any user intervention. Do whatever you need — get a logcat, run adb shell — all from the comfort of your workstation. For other Esper-managed devices that don’t run Foundation, you can still initiate a secure remote adb session with a semi-technically-capable individual at the other end. We’ve done it ourselves on behalf of customers, and while we won’t tell you it’s easy, it’s way easier than getting on a flight halfway across the country.
If you’re in a deployment scenario where adb isn’t allowed, we expose this feature as a policy you can disable to completely prevent its use. And if you only want occasional access, you can set a session duration to make sure the connection isn’t left open.
Do you want better harmony with your cloud dev and DevOps engineer? All of this helps!
Android OS Engineer
We know you. You like to work with esoteric hardware and Android builds. But even if you may be a hardcore Android engineer, there’s absolutely nothing hardcore about manually enrolling AOSP devices into management. And wouldn’t it be nice to take some heavy lifting off your plate with APIs that can be used by you, as well as developers working at a higher level?
Esper Device Provisioner
Yes, yes, you can enroll an Android device into Esper using adb. For Android Enterprise devices, why bother? There’s good infrastructure for that. However, what about an AOSP (non-GMS) device? That’s where the Esper Device Provisioner comes in. It’s an application that runs on Linux, Windows, and macOS, and it’s built specifically for provisioning AOSP devices (although it works with GMS devices as well). You can log into your Esper Cloud account and access all the onboarding configurations (policy, apps, and settings) defined through provisioning templates. Then, just connect to your device via adb — whether USB, Wi-Fi, or Ethernet — and we take care of the rest.
Our provisioner is designed to work with prerelease code, enabling you to install apps from unknown sources, disable the package verifier during provisioning, and conveniently upload apps locally or via URL to use for the provisioning session. Multiple adb commands can be passed during provisioning via the Device Provisioner. You even have the flexibility to collect detailed logs to help us troubleshoot any provisioning problems during your device development process.
Foundation and the Foundation SDK
We make our own distribution of Android built specifically for dedicated and custom devices. It supports various ARM-based targets as well as x86. Foundation includes support for seamless provisioning, remote control, and touchless secure remote adb. The Foundation SDK is included in Foundation and lets you dynamically define the boot animation setup flow.
Contact us if you are interested in using Foundation for your custom device — there is an MOQ, and we need to determine the feasibility of targeting your hardware if it is not currently supported by Foundation.
If you need to build your own AOSP-based image, we can still help! Our seamless provisioning, remote control, and touchless secure remote adb are all available via a private git repository. Both an NDA and an MOQ are required, please contact us to find out more.
IT pros frequently own the provisioning, health, and maintenance of dedicated Android device fleets. These are the people who, while not full-time developers themselves, frequently use developer tools to automate job functions, saving their organizations valuable time and money. The tools we suggest for this crowd: Python SDK, EAST tool, JSON Settings, and the Namespace API.
Use your Python scripting skills to control and monitor your device fleet. The main intention of this SDK is to provide a straightforward Python environment to drive the Esper Cloud API, letting you execute large or complex batch jobs that might be tedious and time-consuming in the console.
The Esper API Support Tool (EAST) is a simple application that you install, and it’s supported on Windows and macOS. EAST provides easy access to a selected set of our cloud APIs, and IT admins can use it to run bulk jobs that aren’t feasible via the Console. With EAST, you can log in to your endpoint and avoid dealing with including credentials for each action you take, and it nicely displays information about your fleet or device via the interface.
While our provisioning template provides a rich set of configuration options, many more are available through our Esper agent that runs on your fleet. We make these easily available through what we call JSON Settings. To use it, you simply need to craft an appropriate JSON payload, drop it into your provisioning template, and your device will be provisioned accordingly. For example, you can set an APN and turn on roaming for the devices you provision with that template.
Note that the specific JSON settings available can vary from device to device. You can verify what’s available on your device by running a set of adb commands to inspect their returns. For more, check out this post.
This API provides the same capabilities as JSON Settings, but for making on the fly changes to devices already deployed in the field. If you need to make some adjustments to your configuration not made available through the console or the EAST Tool, Namespace done through a tool like Postman is the way to go. This blog post provides the details on using our Namespace API.
Through Esper, developers involved in creating, rolling out, and managing dedicated device fleets now have a cadre of specialized tools just for them. Additionally, our tooling is making the vision of DevOps for dedicated Android device fleets a reality, and we’re just getting started. We hope you enjoyed this tour of the different developer tools. Check out our support documentation resources for help, or get in touch with us if you have any questions.