Three things to know about planning an OTA update

Updates to the system used to be relatively straightforward. When developers need to modify something they have already distributed to the public, an updater is released for people to run. The user will run an updater that allows replacing old files with new ones and adding new ones. However, even with these "relatively simple" updates, there's a catch. What happens when a user-installed system is in an unexpected state? What happens when an upgrade is interrupted? These issues are just as important when various devices are online, sometimes requiring important security updates.

Many of today's updates are delivered over-the-air, over-the-air (OTA), and the possibility of poor connectivity, sudden signal loss, or power outages can have a catastrophic impact on what should be a minor update. These are the top three strategies you need to consider when planning to offer OTA updates.

1. Verification

The TCP protocol has a lot of validation built into it, so when you send packets to a device, you can usually be confident that every packet was received intact. However, TCP cannot report errors it doesn't know about, so it's up to you to verify the following:

• Have you sent all the documents required for the update? The device cannot receive content that was not sent.
• Is the document received the same as the one you sent? At a minimum, check the SHA sum to verify file integrity.
• If possible, use a digital signature to ensure the file is from a trusted source.
• Before allowing the update to begin, you must verify that the device is able to apply the update. Check permissions and battery status before submitting an update, and make sure your update process covers any unexpected user events, such as scheduled restarts or hibernation.
• Finally, you must verify that the update that is claimed to have completed successfully has actually completed. Before officially marking the update as complete for the system, check the file location and integrity on the target device.

2. Fallback and failure states

The worst case for an update is that the device is in a damaged state such that it can't even continue an aborted update. In this case, the updater file exists on the target device, but the process has been interrupted. This can leave the device in an unknown state, where some files have been replaced by newer versions and others have not. In the worst case, the updated files are not compatible with the ones that haven't been updated, so the device doesn't work as expected.

There are some strategies to solve this problem. The initial update steps might be to install a special boot image or environment dedicated to completing the update, and set a "flag" on the system to confirm that the update is in progress. This ensures that even if the device suddenly loses power during the update process, the update process will restart on the next boot. The flag indicating a successful update is removed only after the update is verified.

Depending on the target device's security policy and what you're updating, a special boot image may not be feasible or necessary. However, the principle remains the same. When launched, the update must establish an environment in which the pending update is the only way to solve the problem

However, the user (if any) should be able to delay or ignore the update until it has been granted permission to start.

3. Additional Updates

In many edge and IoT devices, the underlying layer of the target device is immutable. Updates will only be added to the known state of the system. Projects like Fedora Silverblue are proving that this model can work in many areas, so this extravagance may become commonplace. Until then, though, part of successfully applying an update is understanding the environment you'll be impacting.

However, you don't need an immutable core to apply additional updates. You can build a system that uses the same concept, with updates as a way to add libraries or packages without modifying older versions. As the last step in such an update, the executable with the updated path is the only actual revision you make.

OTA update

The world is becoming more and more wireless. For mobile phones, IoT devices, and edge computing, OTA updates are often the only option. Implementing an OTA update strategy requires careful planning and careful consideration of the impossible. You know your target device best, so plan your update architecture before you start coding.