Here's the problem nobody warns you about until you're standing in it. You've picked an OTA platform. You've solved firmware delivery on paper. Then someone asks the obvious question: how does the update agent get onto the ten thousand devices already sitting in warehouses, checkout lanes, and hospital carts?

And you realize you can't push it over the air. The thing that does over-the-air updates is the thing you're trying to install. You can't OTA the OTA.

TL;DR

• The OTA agent can't be delivered over the air to a device that has no existing OTA mechanism. The agent is the mechanism. This is the one bootstrapping constraint every fleet hits.
• There are three ways onto a device: bake it into the firmware image at the factory, push it as an app through an MDM the device already has, or sideload it by hand over USB.
• Which one you can use depends entirely on where the device is in its life. A device on the production line has every option. A device already deployed in the field with no management agent has almost none.
• The cost of getting this wrong isn't abstract. It's a technician physically touching every device, or a unit going back to a depot for a reflash.
• Esper Airwave supports all three paths and installs with your platform signing identity, not Esper's. For delivering to custom AOSP and non-GMS builds specifically, see How to Push OTA Updates to Custom AOSP and Non-GMS Android Devices.

Why You Can't Just Push the Agent Over the Air

Start with the thing that trips everyone up, because the whole rest of this decision flows from it.

An OTA platform delivers firmware to a device through an agent that lives on the device. The agent is what listens for an available update, pulls the package, writes it to the right partition, and reports back. No agent, no channel. The device isn't reachable.

So the bootstrapping question is a chicken-and-egg problem with no clever way around it. You cannot use the over-the-air channel to install the thing that creates the over-the-air channel. If a device has never had an update mechanism, there is no path that starts with "just push it remotely." Something, or someone, has to establish that first channel through a route that isn't OTA.

That's not a limitation of any particular platform. It's the shape of the problem. Every OTA vendor lives inside this same constraint, whether they say so on the pricing page or not. The honest version is worth stating flat: the first install is never free, and it's never remote-only. What you're actually choosing between is when you pay for it and how much it hurts.

Spoiler: the cheapest moment is before the device ever ships.

The Three Ways onto a Device

There are exactly three routes, and they line up almost perfectly with the three stages of a device's life.

Factory bake: the one that doesn't hurt

The best time to install the agent is the moment before the device has ever left your control. On a new production run, you bake the re-signed agent directly into the firmware image at the factory. The device ships with the agent already on it. On first boot, out of the box, it self-registers with the platform on its own. No IT admin, no technician, nobody touching anything.

This is the path you want for anything you haven't shipped yet. It turns the bootstrapping problem into a build-step you solve once, in the image, instead of a field operation you solve ten thousand times. If you're speccing a new device or a new production batch right now, this is the section that matters. Get the agent into the image and the entire rest of this article becomes someone else's problem.

The catch is obvious. Factory bake only helps with devices that haven't been manufactured yet. For everything already in the world, you're looking at the other two doors.

MDM push: the one that scales for deployed fleets

For devices already in the field, the good news is that most managed fleets already have a channel you can borrow. If a device is enrolled in any MDM that can push an app — Esper Deploy, or a customer's existing third-party MDM, doesn't matter which — that MDM can deliver the agent as a standard app install. No re-enrollment. No disruption to how the device is managed. The MDM is just the delivery truck for one APK, and once the agent lands, it stands up its own firmware channel independent of whatever that MDM does day to day.

This is the route that saves a deployed fleet from a physical recall. It scales the way an app rollout scales, because that's all it is. The requirement is simply that the device already has a management agent capable of pushing an app. Most enterprise-managed devices do.

Which is exactly why the third case is the one that keeps people up at night.

ADB sideload: the one you do with your hands

If a device is in the field and has neither a baked-in agent nor an MDM that can push an app, you are out of remote options. Full stop. Someone connects to the device over USB and sideloads the agent with adb, one device at a time, with the device in a mode that most production hardening policies deliberately turn off.

Read that back. For a fleet that shipped without an agent and without management, restoring OTA capability can mean a technician physically handling every single unit, or the device going back to a service depot for a firmware reflash. That's not a rollout. That's a recall wearing a different hat.

This is the true cost of skipping the factory step, and it's why the boring build-time decision is the most important one in this whole article.

Which Door You Actually Get to Use

Notice that you don't freely pick among the three. The device's situation picks for you.

‍

The pattern reads top to bottom as a widening cost. The earlier you solve bootstrapping, the cheaper and more automatic it is. The later you solve it, the more it looks like manual labor and shipping logistics. There is no configuration, no premium tier, and no vendor that changes this ordering, because it's dictated by where the device is, not by what you bought.

Which is the actual strategic point hiding inside a technical article: bootstrapping isn't a feature you evaluate. It's a decision you make early or pay for late.

How Airwave Handles the First Install

Esper Airwave lives inside the same constraint as everyone else. What matters is that it supports all three doors, and that the identity story is right.

The Airwave Agent is a lightweight system app, and before it's installed it's re-signed with your platform certificate — yours, the OEM's, not Esper's. That re-signing is the whole trust model in one step. The agent on your devices carries your signing identity, which means only builds signed with your key ever reach your fleet, and Esper cannot push anything to your devices. The bootstrapping method changes; that identity guarantee doesn't.

On the factory path, the re-signed agent goes into the image using the same Seamless Provisioning repo already in play for device setup, and the device self-registers on first boot using its signing fingerprint and hardware model as its identity. A device whose fingerprint doesn't match a registered profile simply receives nothing — the identity check is also the security boundary.

On the MDM path, any MDM that pushes an APK can deliver the agent to a deployed device without re-enrollment. On the sideload path, it's adb over USB, device by device, for the hard cases with no better route in.

One honest boundary, because it belongs in the same breath: getting the agent onto the device is step one, not the whole job. Once it's there, Airwave handles delivery through a signed approval gate to the fleet, and on A/B-partition devices a failed update rolls back on its own at the bootloader level — that recovery is Android doing the work, not Airwave. The bootstrapping is the part this article is about. The delivery model is covered in the companion pieces.

The Boring Decision That Prevents the Expensive One

Almost nobody gets excited about the firmware image checklist. It's the least interesting slide in the hardware planning deck. But the line item that says "bake the OTA agent into the image" is the one that decides whether a future security patch is a click or a convoy of technicians.

You can pay for bootstrapping once, quietly, in the build. Or you can pay for it later, loudly, in the field, at a per-device rate, with someone's hands on every unit. Same install. Wildly different bill.

Do it in the image.

Get the Agent Baked In from Day One

Talk to the Airwave team about getting the agent into your firmware image before your next production run ships.

Request early access to Esper Airwave

FAQ

Can you install an OTA update agent over the air?

No. The OTA agent is the mechanism that receives over-the-air updates, so it can't be delivered over the air to a device that doesn't already have an update mechanism. The first install always happens through a non-OTA route: baked into the firmware image at the factory, pushed as an app by an MDM the device already has, or sideloaded over USB by hand.

What's the best way to install an OTA agent on an Android fleet?

Bake it into the firmware image at the factory, if the devices haven't shipped yet. The device then self-registers on first boot with no admin involvement. For devices already deployed, the best available path is pushing the agent as an app through whatever MDM already manages them. Manual USB sideload is the last resort for deployed devices with no management agent at all.

How do you get an OTA agent onto devices that are already in the field?

If the deployed devices are enrolled in an MDM that can push an app, that MDM can deliver the agent without re-enrolling the device. If they have no MDM and no existing agent, the only remaining option is sideloading over USB per device, or sending units back to a depot for a firmware reflash — which is why baking the agent in at the factory matters so much for anything you haven't shipped yet.

Does installing the Airwave Agent require re-enrolling my devices?

No. On devices with an existing MDM, the agent is delivered as a standard app install and the device's management setup is untouched. The agent stands up its own firmware channel independent of the MDM. For a full breakdown of how Airwave coexists with an existing MDM or none at all.

Whose signing key does the agent use?

Yours. The Airwave Agent is re-signed with your platform certificate before installation, so it carries your signing identity and only builds signed with your key reach your devices. Esper never holds your keys and cannot push to your fleet.