OTA update

An OTA update moves a new software image from the manufacturer to a device in the field over a network. RFC 9019, the IETF architecture for IoT firmware updates, splits the job into roles. The author builds the image. A status tracker announces that a new version exists, reports what hardware and software each device runs and triggers the update. The firmware consumer on the device parses and verifies the manifest and stores the image. The manifest carries a sequence number, and RFC 9019 states that a device presented with an old but valid manifest must not be tricked into installing that firmware, because old versions can contain known vulnerabilities.

Android, the base for most custom phone and terminal systems, shows the same chain in detail. An OTA package must be signed with one of the keys the system expects, or installation rejects it. On non-A/B devices, packages received by the main system are usually verified twice: once by the system against keys in otacerts.zip and once more by recovery. Builds are signed with test keys by default, and the AOSP documentation warns that test keys are publicly known, so any released image needs its own release keys.

There are two kinds of package. A full package contains the entire final state of the device and installs regardless of what the device runs now. An incremental package contains binary patches against the files already on the device. It is smaller, but it installs only on the exact source build it was made from; on any other build the installation fails and the device keeps running the old system.

On current Android devices the installation itself uses A/B slots. The update_engine daemon writes the new version to the unused slot in the background while the user keeps working, and the bootloader switches slots on the next reboot. If the new slot fails to boot, the device falls back to the old one. The new slot is marked successful only after it boots and passes its checks. Virtual A/B has been the scheme since Android 11, and non-A/B updates are deprecated as of Android 15.

Most of the work behind OTA sits in the backend and the release procedure, and they decide whether a new version reaches the fleet or leaves devices that no longer boot. Requirements for a system that ships updates to a fleet:

• Signing keys are production infrastructure. Release keys live apart from test keys, outside developer laptops and CI logs, with a named owner. Whoever holds the key can ship code to every device.
• The version graph is data. For each target version the backend stores the full package, the source versions that have an incremental package, and the package URLs. Each source-to-target pair is unique, and the database enforces it.
• Every dimension of a build is explicit: region, signed or unsigned, user or userdebug variant. An incremental package built for the wrong variant fails on every device that receives it, so the backend validates that source and target match before publishing.
• The device falls back to the full package when an incremental installation fails, logs the error code, and reports which type of update it attempted.
• Releases are staged. A version goes to a test group first, then to growing percentages of each device group on a schedule, with pause and stop. A pause must also stop the schedule, and a device that already started installing must be able to finish.
• Devices report status back. Without per-device version and error codes the operator cannot tell a slow rollout from a failed one.
• Migrating release data is as risky as a release. Rollout states, group assignments and build variants have to survive a move to a new backend, and the move needs its own test pass.
• Old versions stay blocked. The backend and the device both refuse downgrades to a version with known vulnerabilities.

In the EU, the Cyber Resilience Act, Regulation (EU) 2024/2847, turns update capability into a legal requirement for products with digital elements. Under Annex I, vulnerabilities must be addressable through security updates, including, where applicable, automatic security updates enabled by default with a clear opt-out, notification of available updates and the option to postpone them. Manufacturers must provide mechanisms to distribute updates securely, and security updates for identified issues must go out without delay and, unless agreed otherwise for a tailor-made product, free of charge. Annex I, Part II, point 2 requires that, where technically feasible, new security updates are provided separately from functionality updates. Article 13(8) sets the support period at a minimum of five years; when the product is expected to be in use for less than five years, the support period matches the expected use time. The regulation applies from December 11, 2027; the reporting obligations of Article 14 have applied since September 11, 2026. RFC 9019 is an informational IETF document; it sets out the architecture and motivates a transport-agnostic manifest format for describing and protecting updates.

In the Raw Control OS project, update work started in 2019 with a test environment for analyzing and assessing the security of the Android updates published by Google before they went into the system. The production version of the system was prepared together with an OTA test and handed to the client for verification, and later OTA builds were issued on the client's request. A backend OTA service was drafted in 2021 but not completed in that project.

For Mudita, in 2026 we are building the second stage of the OTA platform behind its phones, including a new admin dashboard. We did not build Mudita's operating system. The scope covers publishing incremental updates, with a full package always available as the fallback and a unique link between each version and its predecessor; automatic generation of incremental packages in the build pipeline, with file names that encode region, version, signing, build variant and source version; validation of previous versions when a new one is configured; and staged rollout scenarios. A scenario has 1 to 10 phases, each set as hours after release (0 to 720) and a percentage of the group, with the last phase at 100%. One example is 5% at once, 20% after 48 hours, 50% after 120, 75% after 168 and 100% after 240. Devices in each phase are chosen at random.

In September 2026, the test migration to the new dashboard left all rollouts of published versions stopped; on production this would have blocked every update. That was fixed. A security audit of the platform's frontend and backend is in progress.