OTA Updates: What Are Over-The-Air Updates?

Over-the-Air Updates

An OTA (or “over-the-air”) update refers to a software or firmware update package distributed to a device (like an Android smartphone) via internet connection. This is as opposed to a “local” update, which uses files previously loaded onto a device to install a software or firmware update (perhaps by USB, SSD, SD card, or local intranet connection).

OTA updates are now the predominant method for updating the software and firmware of devices (firmware OTAs are sometimes called FOTA updates). This may seem like a given, but historically, OTA updates are actually a recent phenomenon. Imagine trying to update a television or printer’s firmware 15 or 20 years ago — it often wasn’t even possible. In the 1990s, most computer software still had to be updated via files delivered on physical media, like a floppy disk or CD. Today, a growing number of cars can now update their software via OTA.

Most commonly, OTA updates refer to software updates for products like Android and iOS smartphones, tablets, and IoT (internet of things) devices. While many of those updates might have been categorized as FOTA in the past — because they can be considered to update a device’s “firmware” — this distinction has largely disappeared. An OTA update may update a smartphone’s operating system, its cellular radio, applications, and hardware drivers in any number of combinations, so it’s easier just to think of any significant update to a computer as an OTA.

Software Deployment Made Easy

Why Update Over the Air?

Prior to the widespread adoption of OTA update systems, the methods by which a device’s software could be updated varied. Some software has been OTA-updateable for many years now, such as components of Microsoft’s Windows operating system. But on the other end of the spectrum, PC motherboard firmware must still be updated locally even today. The reason for the popularity of OTA updating, though, is simple: It makes updating computers much easier and more scalable.

Let’s go back to the motherboard example. How many people will ever bother to update the motherboard firmware on their home PC or laptop? The answer, generally speaking, is almost none! The process is tedious, manual, and requires the user to seek out the update payload (i.e., the files), load it into some sort of physical media, and follow exacting instructions to install it. This greatly reduces the likelihood anyone will ever update a given device or component at all. Devices and components that are not updated may suffer from security flaws, degraded performance, and bugs.

Compare the motherboard scenario above to a modern iPhone. The iPhone receives updates to iOS (Apple’s mobile operating system) on a regular basis, and they take just a few minutes for the user to install. Downloading the update occurs in the background, and installation can even take place overnight — when the phone is charging and not in use. This greatly increases both the pace of adoption and adoption rate of critical updates. This lowers exposure to security issues, reduces the likelihood of customer support requests, and may even extend the useful life of the product.

How do OTA updates work?

There’s no one way OTA updates work. From a very basic perspective, though, you can describe the OTA process as follows.

1. A company creates a software (or firmware) update for a given product or application.
2. This update is stored on a cloud server for distribution.
3. This company sends out a notification via a cloud-connected OTA service to the devices that need to be updated.
4. On receipt of the update notification, the device downloads the OTA update from the cloud server (often, user consent is required at this step).
5. Once the download is complete, the device validates the contents of the OTA package, then begins the OTA installation process (user consent is often required again here).
6. The device reboots, running the newly-installed software and / or firmware

The specifics are going to vary considerably depending on the device and operating system. Android devices, for example, have a specific OTA mechanism called “seamless updates” (or A/B updates), which is described in detail below.

How OTA works for connected Android devices

Partitions need to be flashed with the respective images that were shipped inside the zip, which means the zip must be extracted before images can be flashed on the device.

But, how is any of that possible when a device is up and running?

Installing system updates to non-mobile operating systems such as Windows, Ubuntu, and macOS means a machine has to be put into update mode. Regular functionality and operations on a non-mobile OS are impossible until updates are complete. This was also the case with Android until Android 7.0 Nougat was released in 2016.

Prior to 7.0 Nougat, Android devices had to boot into recovery mode to install updates by extracting system images from a zip file and installing factory images to the device partitions. When updates were finished, the device then booted up into an upgraded and new version of OS.

But, things changed. With Android 7.0 Nougat, ‘seamless updates’ were introduced, which are also known as A/B updates.

Streaming A/B updates for Android

A/B updates introduced a new way to install Android updates OTA. This approach involves two copies of each device partition, copy A and copy B. Android devices apply the update to a currently-unused partition when the system is running and idle.

A/B devices don’t need space to download an update package because they can apply the update as they read it from the network – or, stream updates. That’s why this OTA approach is called Streaming A/B.

Android 7.0 or newer devices that support A/B updates have two copies of each partition. These devices have a new partition scheme which typically involves:

1. /system_a
2. /system_b
3. /cache_a
4. /cache_b
5. /data_a
6. /data_b
7. /boot_a  
8. /boot_b
9. /recovery_a
10. /recovery_b

Implementation overview for A/B Android OTA

Here’s an overview of the implementation requirements for A/B Android OTA.

1. Device implementation

The Android OS needs to be shipped with an updater which can check for updates by comparing a key. If an update is available, the updater will download the zip and perform a basic integrity check.

If integrity checks are passed, the device updater passes the zip to the update_engine. The update_engine is a system service enabled by default on devices to support A/B updates.

Along with the zip, a config needs to be processed by the device updater. The config contains the file names and offset of the files inside the zip. Typically, an A/B update zip contains only one file – payload.bin – which contains compressed images of all partitions.

A/B Android OTA updates can either be STREAMING or NON_STREAMING:

• STREAMING reads the contents of the zip over the network and applies changes to a powered-up device.
• NON_STREAMING involves downloading the zip before applying device updates.

There are no device mode requirements to apply A/B Android OTA updates. These updates are simply applied to the second slot of each device partition. Once the update is complete, a reboot will switch the Android device to the newly-updated partition slot.

The A/B method leaves room for Android to revert back to the previous OS if there is a failure or performance issues.

2. Backend implementation

First, an API should work in the following fashion to check for updates:

Input:

1. Device name
2. Device ID
3. Current OS version on the device
4. Update channel

Output:

1. The latest version of the OS available for that device. The device ID is useful to perform staged rollouts where certain Device IDs are exempted from the latest version.
2. Link to an incremental zip that creates a bridge between the current OS version and the latest device. If no incremental zip is available, then a link to a full zip file should be returned.
3. Config details for the zip.

Here’s a Sample Config:

{    
"name": "SAMPLE-cake-release BUILD-12345",   
"url": "http://foo.bar/builds/ota-001.zip",   
"ab_install_type": "NON_STREAMING",  
"ab_streaming_metadata": {       
"property_files": [            
{               
"filename": "payload.bin",               
"offset": 531,               
"size": 5012323            
}        
]   
} 
}

Second and last, an API should deploy the device update:

Input:

• Zip file
• Target Device Name
• OS Version Info
• Incremental OR Full zip status.
• If the zip is incremental, it should provide an incremental update from the source version to the destination version. Multiple incremental zips can exist and must be uploaded.
• Incremental zips need to be provided for each version represented on devices, and when that’s not possible, it’s necessary to provide a full zip.
• Config details for each zip
• Update channel
• Sample Config

Output: None

Software Deployment Made Easy