Android OTA Updates: A/B Partitions, Delta Updates and Rollback
Once devices are in the field, fixing a single bug can mean sending someone on site — an absurd cost. OTA is not a feature to add later; it is an architectural decision made at kickoff, because it determines the storage configuration and partition table and is very hard to change afterwards.
A/B versus single partition: decide this first
Android update schemes fall into two families.
A/B dual partition (seamless update): the system has two complete sets of partitions. The update writes the new version to the standby slot, then flips the boot flag and takes effect on reboot. The device remains usable throughout download and write, with only the reboot interrupting service. More importantly, if the new version fails to boot, the bootloader automatically reverts to the last working slot — a failed update cannot brick the device. The cost is roughly double the system partition footprint.
Single partition (recovery-mode update): one system partition only, and the device is unavailable while the update is applied in recovery. Storage use is lower, but a power cut during the update, or a faulty new version, makes rollback difficult and can brick the device outright.
For industrial equipment, digital signage and unattended terminals — products where on-site repair is extremely expensive — the extra storage cost of A/B is almost always justified. Conversely, for highly cost-sensitive consumer set-top boxes whose users can reflash firmware themselves, single partition still has a place.
Delta or full-image updates
Delta updates transfer only the differences between versions, so the package may be a fraction of the full image — valuable over cellular links or where data cost matters. But there is a hard precondition: the version currently on the device must exactly match the delta’s base version. If the build number differs even slightly, or the user once flashed third-party firmware, the delta fails.
Full-image updates are larger but robust and independent of the current version. The common practice combines them: offer the delta first and fall back to the full image on failure. That saves bandwidth while protecting the success rate.
How rollback actually happens
A/B rollback relies on cooperation between bootloader and system: the bootloader maintains an “attempted boots” counter, and if the new slot fails to boot several times in a row it marks that slot unusable and switches back. After a successful boot, the system must explicitly confirm to the bootloader that this boot succeeded — that confirmation is what makes rollback work, because without it the bootloader cannot distinguish a successful boot from one that hung halfway.
Test this path deliberately in engineering: build a version that will fail to boot and verify the device reverts automatically. That is the only way to prove rollback actually works.
Signing and verified boot
Update packages must be signed, and the device should verify the signature before installing, preventing substitution with malicious firmware. Combined with a verified boot chain, this ensures the device runs only signed images. For export products this is not only a security requirement but increasingly a compliance expectation from channels and customers.
Plan the signing system early: how keys are generated, stored and rotated. Leaving it until just before mass production usually stalls on key management that was never set up.
Practical points
First, storage budget: A/B nearly doubles system partition use, so account for it in designs where capacity is already tight. Second, staged rollout: never push to every device at once; start with a small batch, confirm, then expand. Third, power loss during update: under A/B a cut simply means retrying, whereas under single partition it can brick the device — which is why power-loss protection and OTA must be designed together. Fourth, version reporting: devices must report their current version so the server knows coverage; otherwise you push and never learn whether it worked.
The X88 PRO 14 set-top box and the HS89 PRO 15 set-top box are both Android 14 platforms, while the 05A IPA-RK3588 industrial control board targets industrial use. For a finished-product project, confirm four things with the supplier at selection time: whether the BSP supports A/B partitions, whether verified boot is enabled, whether a delta generation tool exists, and what the recovery path is when an update fails.
Conclusion
The design order is: decide A/B or single partition based on field maintenance cost, then settle the delta-with-full-image-fallback strategy, then plan signing and key management, and finally test the complete “deliberately fail and roll back automatically” path. All four belong at kickoff — changing them later is extremely expensive.
