Do the arithmetic on your next firmware rollout before you schedule it. A modern Android build runs 1 to 3 GB. Say yours is 2. Now push it to a fleet of 10,000 devices.

That's 20 terabytes of data leaving a server and landing on devices, for one update. Not for the year. For the update. Do it monthly and you're moving a quarter-petabyte a year just to keep firmware current — and every byte of it costs money, saturates networks, and drags out the window where half your fleet is on the old build and half is on the new one.

The full-package habit is the thing quietly making your rollouts expensive. There's a cheaper way to move the same update, and the reason it works is almost embarrassingly simple.

TL;DR

• A full OTA package is the entire build, 1 to 3 GB. Across a real fleet, that multiplies into terabytes of transfer per rollout — 2 GB × 10,000 devices = 20 TB.
• A delta (differential) update ships only the binary difference between the build a device is on and the build it's going to. For a device on a recent version, that can cut the payload by up to 90%. A 2 GB full update becomes roughly a 200 MB delta.
• The tradeoff: deltas are version-specific. A device has to be on a known starting build for its delta to apply. A device that skipped a version needs a different delta or the full package.
• The system has to handle that routing automatically, or the operational overhead eats the bandwidth savings. Esper Airwave routes each device to the right delta and falls back to the full package on its own.
• Bandwidth is one line item in the larger build-vs-buy question. For the full cost picture, see Building Android OTA Infrastructure vs. Buying It.

Why a Full OTA Package Costs So Much to Ship

A full OTA package is exactly what it sounds like: the complete firmware image, every partition, everything, whether or not it changed since the last build. It's the simplest thing to ship and the most expensive thing to move.

The expense doesn't show up on one device. It shows up when you multiply. One 2 GB download is nothing — it's a large app. Ten thousand of them at once is a 20 TB event that hits your egress bill, competes with every customer's own network traffic, and turns "push the security patch" into a logistics problem with a spreadsheet attached. The devices on metered or thin connections — the retail backroom on a shared DSL line, the clinic on a saturated uplink — are the ones that stall, retry, and stretch the rollout from hours into days.

And here's the part that stings: most of those 2 GB didn't change. A typical firmware update touches a fraction of the image. You're paying full freight to redeliver gigabytes of bytes the device already has, sitting on its own storage, identical to what you're about to send it. The full package doesn't know or care what's already there. It ships everything, every time.

That's the waste a delta is built to kill.

What a Delta Update Actually Is

A delta update — a differential update, if you want the formal name — ships only the difference between two builds. Not the new image. The change between the old image and the new one.

The mechanism is the same idea behind binary patching tools like bsdiff: compute a precise, byte-level diff between the outgoing build and the incoming one, package just that diff, and let the device reconstruct the full new image from the piece it already has plus the small piece you send. If the update changed 200 MB worth of an otherwise-identical 2 GB image, the device only needs the 200 MB. It already has the rest.

For sequential updates — a device on a recent build moving to the next one — that math lands at up to a 90% reduction in payload size. Your 20 TB rollout becomes something closer to 2. Same firmware, same devices, same result on the other end. A tenth of the bytes on the wire.

You're not moving less firmware. You're refusing to move the parts that didn't change.

The Catch: Deltas Are Version-Specific

Nothing this good is free, and here's the bill. A delta is computed between two specific builds, which means it only applies to a device sitting on the exact starting build it was computed from.

A device on v1.0 can take the v1.0-to-v1.1 delta. A device that's still on v0.9 cannot — that delta doesn't fit, because the bytes it expects to already be on the device aren't there. That device needs either a v0.9-to-v1.1 delta, if you generated one, or the full v1.1 package as a fallback.

In a real fleet, devices are never all on the same build. Some got every update on schedule. Some were boxed in a warehouse for two quarters and missed three versions. Some came back from repair on whatever image the depot had. So you don't have one delta — you have a matrix of them, and every device needs to be matched to the exact right one, or handed the full package when no delta fits.

That matching problem is where a naive delta strategy falls apart. If a human has to figure out which device gets which delta, the coordination cost claws back everything you saved on bandwidth. The savings are only real if the routing is automatic.

How Airwave Handles the Routing

This is the part that makes deltas usable instead of just theoretically efficient. Esper Airwave tracks the current build version of every device in the fleet, and when you push an update, it routes each device to the correct package on its own — the right delta for the devices that can take one, the full package for the devices that can't.

You upload the update. Airwave reads each device's registered build version, matches it to the correct delta if one exists, and falls back to the full package automatically when it doesn't. No operator sitting with a spreadsheet deciding which of 10,000 devices gets which file. The device on last month's build gets a tiny delta. The device that came back from the depot three versions behind gets the full image. Both end up on the same new build, and nobody had to think about it.

That automatic fallback is the quiet, load-bearing piece. It means "use deltas" isn't a bet you're making on your fleet being uniform — it's just the default behavior, with the full package always waiting as the safety net for the devices that need it. You get the 90% savings on the devices that qualify and correctness on the devices that don't.

When the Full Package Still Wins

Deltas aren't always the answer, and pretending otherwise is how you get burned. A few cases where the full package is the right call:

A device too many versions behind, where no delta was generated for its starting point, takes the full image. That's not a failure — it's the fallback doing its job. A device enrolling fresh with no known prior build gets the full package, because there's no diff to compute against nothing. And for a small fleet where the total transfer is trivial, the operational simplicity of shipping one file to everyone can be worth more than the bandwidth you'd save splitting hairs over deltas.

The point isn't "always delta." It's "delta by default, full package when it's the right tool, and a system that knows the difference without asking you." Bandwidth savings that require you to babysit them aren't savings. They're a second job.

Move the Change, Not the Whole Build

Shipping the entire firmware image to every device, every time, is the expensive habit hiding inside your rollout schedule. Most of those bytes are already on the device. A delta refuses to pay to send them again, an automatic fallback keeps the devices that can't take a delta correct, and the whole thing works without a human routing files by hand.

Twenty terabytes or two. Same update. Your call.

See What Delta Delivery Does to Your Bandwidth Bill

Talk to the Airwave team about what fleet-scale OTA looks like when you're only moving the parts that changed.

Request early access to Esper AIrwave

FAQ

What's the difference between a delta and a full OTA update?

A full OTA update ships the complete firmware image — every partition, changed or not — typically 1 to 3 GB on a modern Android build. A delta (differential) update ships only the binary difference between the build a device is currently on and the build it's moving to. For a device on a recent version, the delta can be up to 90% smaller than the full package, because it excludes everything that didn't change.

How much bandwidth do delta updates actually save on an Android fleet?

For sequential updates on devices that are on a recent build, delta updates can cut payload size by up to 90%. In fleet terms: a 2 GB full update across 10,000 devices is 20 TB of transfer, while the delta equivalent for qualifying devices can bring that closer to 2 TB. The savings apply only to devices on a known recent starting build — devices several versions behind may need the full package.

Why can't every device just take the delta?

A delta is computed between two specific builds, so it only applies to a device already on the exact starting build it was made from. A device that skipped versions, enrolled fresh, or came back from repair on an older image doesn't have the bytes the delta expects, so it needs either a different delta or the full package. This is why automatic routing matters — the system has to match each device to the right package or the coordination overhead eats the savings.

Does Airwave choose between delta and full packages automatically?

Yes. Airwave tracks each device's current build version, routes devices that can take a delta to the correct one, and falls back to the full package automatically for devices where no applicable delta exists. There's no manual step to decide which device gets which file.

Is bandwidth the only reason to care about delta updates?

It's the biggest one, but not the only one. Smaller payloads also mean faster downloads on thin or metered connections, shorter rollout windows, fewer stalled or retried transfers, and less contention with your customers' own network traffic. All of it compounds at fleet scale. Bandwidth cost is one component of the larger build-vs-buy calculation covered in Building Android OTA Infrastructure vs. Buying It.