How Firmware Over the Air (FOTA) Updates Work on Android

FOTA stands for firmware-over-the-air and is used to refer to a type of update system on modern smart devices like tablets and smartphones. Android is designed to accept FOTA updates, making updates an integral part of the operating system. This type of update is an essential part of keeping your devices secure and up to date — regular security patch updates are crucial to ensure devices are patched against an ever-growing list of Common Vulnerabilities and Exposures (CVEs).

In this article, we will go over some of the common reasons why you should consider including a FOTA update system in your dedicated device management deployment plan, how FOTA works on Android, and how you can use the Esper platform to simplify this process.

Why are OS updates important and how does FOTA make them simpler?

There are many reasons you should keep your dedicated Android devices up to date.

• Security: Every day more vulnerabilities are discovered, both in Android as well as the underlying Linux kernel. Every month, Google releases a list of these vulnerabilities that Android is affected by through its Android Security Bulletins. Google recommends that all OEMs update and configure their device firmware every month with the relevant security patches, though most consumer OEMs tend to prefer quarterly updates. For dedicated Android devices, it’s essential that the firmware version is kept up to date with regular security updates. It’s also recommended that the Linux kernel used in the device is kept up to date with the upstream branches, to ensure maximum security coverage. In most cases, it is not feasible to manually install updates to devices, especially in large fleets, which is why a FOTA software update system can be incredibly helpful.
• Feature Updates: While this may be relevant mostly for consumer devices, it’s still an important reason why you may want to consider a FOTA system. Improvements to Android’s feature set can come in two ways: through app updates and through system updates. Usually, features that involve hardware require changes to the Android kernel and/or the system. A FOTA system can help streamline this process by not requiring an onsite technician visit every time a minor feature is added.
• Android Version Upgrades: The mantra “if it ain’t broke, don’t fix it” is not quite relevant to Android. Even if your devices are running fine on an older version of Android, it’s important to remember that Google only supports a particular version of Android with security patches for three and a half years. If you intend on using your mobile devices for a relatively long time, and you want them to stay secure, you’ll need to plan for at least one major Android upgrade. Android version upgrades involve major changes to many parts of the system, making the process more complex than just a regular update. An automated over the air update strategy can simplify this process significantly.

How FOTA updates work on Android

Android has included support for FOTA updates since at least Android 1.6 Donut. While the initial implementation was somewhat crude, the design has since been updated significantly to the point where updates are seamless and barely noticeable. Before we dive into the different kinds of update architectures on Android, it is important to understand the basics of how an Android device’s OS files are structured. Android devices consist of some essential partitions that house specific files:

Bootloader: The bootloader is the first to load when a device is turned on. Its role is to verify the integrity of various partitions and load the kernel into the RAM. As there are multiple stages to the boot process, there are multiple bootloader partitions.  

/boot: The /boot partition consists of the Android Linux kernel, as well as the ramdisk (on pre-Android 13 launch devices), which is a set of scripts that determine the order by which processes are started by the system. 

/data: This is where all the user data, such as installed apps, app data, media (photos, downloads, etc.) resides. This partition is wiped when the device is factory reset. 

/recovery: The recovery is a mini operating system that acts as an interface to update other partitions while they are inactive. In devices without A/B update support, FOTA updates are applied by the recovery.

/system: The system partition contains most of the Android system files, such as system apps, system media (including the bootanimation, ringtones, etc.), low level C libraries, and the Android framework. 

/vendor: The vendor partition is similar to the /system partition, and it houses device specific system files, such as userspace drivers (extensions from the kernel drivers) and HALs (hardware abstraction layers). The vendor partition was separated from the system with Project Treble.

In addition to these, there may be other partitions as well, depending on the OEM’s device architecture. A FOTA update may update one or all of these partitions. With that in mind, there are two kinds of FOTA implementations on Android:

A/B (Seamless) updates

A/B updates are arguably the best option for FOTA updates. In order to completely streamline the update process, the device has two copies of all essential partitions, labeled _a and _b (ex: system_a and system_b). Each set of partitions is referred to as a slot. At any given time, only a single slot is considered active. When a FOTA update is deployed to the device, Android’s update_engine, borrowed from Chromium OS, downloads the update file and installs the update to the inactive slot. The next time the device is rebooted, it reboots into the updated slot, thus completing the update seamlessly. 

So, for example, let’s say your device is currently using system_a and a FOTA update comes in. The system will download the update and the update manager installs it to system_b, which is inactive at the time. Upon reboot, the system will flip — system_a becomes inactive, while system_b becomes the new active partition with the new update applied. Rinse and repeat for every new FOTA update. 

There are advantages and disadvantages to this design.

Pros:

• Updates are quick and seamless with minimal downtime.
• In case the update is buggy/broken or if the update failed, you have the ability to boot into the older, working slot to avoid significant downtime.

Cons:

• The system files use twice as much space since each partition has a redundant counterpart, resulting in a slightly higher BOM cost and the need for more storage space. This is somewhat mitigated by the newer “virtual A/B” mechanism, which uses dynamically resizable partitions instead of fixed-sized ones and offers compression mechanisms to reduce storage requirements.
• The mechanism is more complex to support, as an updater needs to be made aware of slots.

Traditional (non-A/B or A-only) updates

The outdated, yet more common traditional update system is less impressive when compared to A/B updates. However, if you prefer simplicity or have storage constraints, this may yet be a good option to offer basic FOTA support on your devices. Devices set up for traditional updates have only one set of partitions, unlike A/B devices. The firmware also includes a recovery partition that is required to install updates to the main system partition (since it can’t be updated while it’s active). Like with A/B updates, there are advantages and disadvantages to this implementation. 

Pros:

• Uses half the space for the firmware as a similar A/B device, reducing BOM cost compared to A/B.
• The recovery allows for easier access for engineers to update devices manually.
• Simpler to set up.

Cons:

• Updates are not seamless, and the device may be offline for 15-30 mins while applying the update, depending on the size. 
• Since there are no redundant partitions, a broken update would require a manual rollback which can be challenging.
• Won’t be supported by future devices launching with Android 13.

The problem with self-managed FOTA updates: Cloud infrastructure

Most OEMs of consumer Android devices provide a FOTA service to push out updates. In that case, you’re dependent on the device maker for these updates and have limited control. Android provides some limited capabilities for when available firmware updates can be installed on target devices (typically a 30 day delay is the best you can get). 

OEMs are also prone to deprioritizing updates, particularly major version upgrades, since the focus is on selling their latest offerings. This approach may be fine for consumer devices but is a major challenge in enterprise scenarios.

In that case, in addition to preparing your Android device for OTA updates, you would also need to set up cloud infrastructure to host your OTA update packages and deploy them to your devices. The process becomes more complicated when there are additional requirements, such as the ability to selectively roll the update out to a group of staging devices before it is rolled out to the entire fleet.

How Esper can help set up and manage your FOTA updates

The process to set up FOTA for a dedicated device is much harder than it would seem for consumer Android devices. However, for customers using Esper Foundation for Android (Foundation) through the Esper platform, you can abstract away all the technical jargon and simply utilize our user-friendly cloud interface to deploy FOTA updates to any and all Foundation devices in your fleets on your schedule. 

In the console (within the Esper Software Updates page), you can view, manage, and deploy updated OS builds without the need for a third-party integration. You have the option to either approve and auto-update devices or use our Pipelines feature to deploy new builds in multiple stages. Using Pipelines, you can test, verify, and validate new Foundation builds in batches, starting with a small group of devices before deploying to a larger fleet, ensuring a smooth transition. You can also set specific times to install updates to minimize the impact of a potential downtime. Unlike manual or third-party solutions, Esper offers a reliable, granular level of control over OTA updates without leaving the console, providing confidence, flexibility, and efficiency in the OTA update processes.

Esper handles all the cloud infrastructure setup required so your update rollouts are worry-free. Devices running Esper Foundation for Android can support both traditional and A/B updates (depending on the device architecture) out of the box, which means no work needs to be done on the device end either. 

It’s also possible to apply Esper’s FOTA infrastructure to non-Foundation custom Android devices. We’d be happy to discuss your particular implementation and see if Esper can provide the FOTA infrastructure — just reach out to us, and we’ll see what we can do.

Esper Foundation for Android