Firmware delivery with Esper Airwave is a phased process that begins when a firmware update is approved. Before an over-the-air (OTA) update takes effect, the Airwave agent must first:

• Discover the update via a configurable 24-hour polling interval or reboot
• Verify hardware model and delta package eligibility
• Meet specific local conditions like maintenance windows and battery thresholds 

Approving a firmware build in Airwave makes the build available for deployment, but there are a few checks that need to happen before the update is installed on the device. Here's a step-by-step breakdown of the entire deployment process in Esper Airwave, from approval to installation.

Step 1: Approval kicks off the delivery process

When you approve a firmware build in Esper Airwave, the test device sitting on your desk might not immediately update. That’s because approving a firmware update in Airwave makes a build available for deployment when devices check for updates. Approval is the first step of the delivery process, but the “Approve” action doesn't send an installation command or force every device to update immediately.

That distinction becomes clear when you think about the diversity of an actual fleet: Devices using the same hardware model may be running different firmware versions. Other devices might be in use, have low batteries, or be busy applying a different update.

Approval tells Airwave that the build is available for the device, but what happens next depends on the device itself. 

Approving the same build again can’t speed up delivery or force it to install faster (use that time for a coffee break instead). That’s because each step of the delivery path is required and how long it takes to progress through them varies by device.

Step 2: Devices check for new builds at defined intervals to find out if a new build is available

When the Airwave agent runs on a device it contacts the service to check for updates on a regular cadence. For that check to happen, the device needs to be registered, running, and connected to the network. By default, OSupdate checks happen every 24 hours. 

Need more frequent checks? We’ve got you. The OS update interval is configurable through managed configurations, so teams can adjust it to their deployment needs.

Step 3: Package eligibility is determined by hardware and current build

When you’re managing several hardware models through the same service, keep in mind that firmware discovery is scoped to the model the device is registered under. That means that builds made for Model A won’t be offered to a device registered under Model B. 

The firmware already running on a device also matters and is particularly important for delta packages, because a delta is built for a specific starting version. For example, a delta from v1.0.2 to v1.0.3 works for a device running v1.0.2. A device still on v1.0.1 can’t use that same package, even though v1.0.3 is the version you want both devices to reach. It needs a package eligible for its own starting version.

Esper Airwave evaluates eligible full and delta packages using their incremental build numbers. The target must be higher than the current build, and higher eligible targets take priority. If both a full package and a delta package lead to the same target build number, the delta is selected.

Approval is shared across the build, but eligibility depends on the device. In practice, this means multiple devices can check for updates at the same time and get different results — one device may receive a delta while another gets a full eligible package, and a third may find no matching update at all.

Same release. Different update paths.

A delta needs the right hardware and the exact starting version.

What happens when an update is already in progress?

The device’s local state is also considered: Airwave may have an eligible build available, but the agent still needs to account for any work already in progress. 

If an update is downloading or applying, the agent suppresses fresh checks. Fresh checks are also suppressed when an update’s been applied but still needs verification after a reboot. Starting another cycle at that point would overlap with one that hasn’t finished yet.

The agent also checks whether the newly offered build is already installed. Where numeric build comparison is available, it skips builds that aren’t newer than the running software.

Looking at a device that seems like it isn’t doing anything? It may already be partway through an update cycle, including the verification that happens post-installation. 

Step 4: Devices checked for installation conditions

Getting the right package onto the right device is one part of delivery, but successful delivery requires installing it under the expected conditions. If an eligible update is available, whether or not the device is ready for installation depends on update policies, battery level, and local update state.

"Eligible" doesn't always mean "Ready"

Installation waits for the applicable device conditions to be right.

Airwave integrates with Esper Deploy MDM’s Android device management update policies. If your devices have a maintenance window configured, installation waits until the policy allows it. Postponement policies can also hold back execution. 

Battery level requires a default minimum charge required is 30%. This is configurable through Managed Configurations. Below that threshold, installation is deferred and a retry is scheduled. Devices explicitly identified as having no physical battery bypass this check.

When these conditions aren’t met, a device can have an approved, eligible update and still be waiting for its maintenance window or sufficient charge. The firmware is available; installation is waiting for the device to be ready.

Step 5: Update is installed and verified 

When the applicable device conditions are satisfied, the agent proceeds with installation once the applicable conditions are met without an additional user-consent prompt in the standard automated OTA workflow. No one needs to be a human-in-the-loop standing at the device to approve the update. The Airwave agent applies the update and verifies it after reboot.

How to know if an update failed

Waiting and failing are different outcomes. When a device encounters an update failure, the Airwave Console shows a Failed state.

At that point, the investigation moves to the installation attempt itself. Device-side logs, update_engine status codes, and update service events help explain what happened. Reapproving the firmware or changing the polling interval will not explain an execution failure.

The status gives operations teams a starting point: did the device attempt the update and fail, or is it still waiting to reach that stage?

"Waiting" and "Failed" are different states

Back to the device on your desk

There are several steps between approving firmware and seeing a new version on the device. Esper Airwave handles that journey through configurable update checks, hardware and version matching, full and delta package selection, and installation conditions on the device.

Once you understand those steps, the original question becomes more specific. Has the device checked for an update since the updated firmware was approved? Is there a package that matches its hardware and current firmware? Is another cycle active, or is installation waiting for the maintenance window or battery level?

Those answers explain how an approved build becomes an installed update, and why the same release can reach different devices at different times.