Get up to speed with Android OTA firmware updates

The increased use of internet-connected Android devices means that applying over-the-air (OTA) firmware updates has become more important than ever. 

Android's popularity has grown because of its versatile nature and ease of use. The open-source OS is especially popular in industrial use cases because of its intuitive UI and ability to support a wide variety of hardware configurations. 

But the OS's popularity also opens the door to more security threats. As Android's global footprint grows, so does its appeal to attackers. By focusing on Android-specific flaws, they increase their chances of success by attacking common vulnerabilities. In this respect, firmware OTA updates become crucial.

Overcoming challenges with firmware over the air updates

It's not only hackers that are a major concern. Bugs in software also need to be accounted for. Carrying out widespread updates without OTA firmware update functionality requires immense resources. 

Unfortunately, implementing firmware OTA update functionality can be extremely complex when doing it on your own. Several security and tech-related factors need to be taken into account, and investment in the proper backend resources can be significant. The procedure for creating new builds and pushing them to devices is also phenomenally intricate. 

This complexity can lead to hesitation on the part of companies to implement OTA firmware updates because they can't do it in an economically viable fashion.

Let's look at what OTA firmware updates are, the challenges of how to update using firmware over the air, and how to easily incorporate an OTA firmware update strategy for your fleet of Android devices. By the end of this article, you should be able to answer the question, "How do Android OTA updates work?"

Why over the air firmware updates are important

Regular firmware Over The Air updates are a critical aspect of maintaining devices in top operating condition.

Some of the elements that OTA firmware updates address are:

With devices spread all over the world, this is an enormous cost-saver. 

When adding new devices to your fleet, it's important to consider that device's lifecycle. Without regular OTA firmware updates, the lifecycle is greatly reduced because devices are more likely to become obsolete. 

One extremely important point to grasp is that retrofitting OS updates is usually not possible at the maintenance site. OTA firmware update functionality needs to be considered thoroughly before releasing the device. 

How does an OTA firmware update work?

The wireless delivery of new firmware to mobile devices is known as over-the-air (OTA) updates. These updates deploy firmware to the device without needing to physically access the device. OTA updates ensure that the devices are kept up-to-date and continue to function optimally.

Image: Simplified OTA update process

How to update firmware OTA manually?

This varies per device but is typically done by navigating to the device's settings, clicking "About," and then clicking on Software Update (sometimes called System Update). If a new version exists, you can proceed to install it. This implies that there is an OTA firmware infrastructure in place.

Considerations for a successful over the air firmware update implementation

Before we dive into the specific technical details of facilitating OTA firmware updates, let's look at the major points to consider:  

Managing an entire fleet

A major factor for deciding to use OTA firmware updates is when you have an entire fleet of devices to deal with. Managing such devices on the ground is virtually impossible. At best, it's inefficient and costly. 

Unfortunately, many homegrown solutions don't properly account for the entire fleet and rather update each device individually. 

The more devices there are, the more chances the OTA firmware update has of running into errors. This can inadvertently lead to security and operational risks. 

New hardware configurations pose challenges for fleet managers because the originally built OS image needs to be customized to work on the specific hardware. This is why OTA firmware update systems mostly target single product lines and can't handle new device types out of the box. 

Retrofitting the OTA firmware infrastructure to new devices is often unfeasible. So a new version of the solution needs to be created, resulting in a byzantine labyrinth of "OTA update solutions" that are complicated to maintain. 

Ensuring a robust update process

The second major consideration is the robustness of the update process itself. Because OTA firmware updates are carried out unattended, they must be as close to flawless as possible. If errors occur, devices must still be left in operating condition. 

OTA firmware update implementations must consider potential errors caused by:

A robust OTA firmware update strategy would, at the least, implement a rollback solution for each of the above scenarios. A more complete solution would also implement:

Software integrity of the OTA firmware update

Using methods that are beyond the scope of this article, it is possible for an attacker to intercept an OTA firmware update and inject malicious code into it. The firmware itself might also ship with malware if the servers on which it was developed are not secured. 

Security practices and checks need to be in place to prevent these occurrences. 

Code signing is also crucial to prevent man-in-the-middle attacks. And the communication between the server and the device must be entirely encrypted. 

Building versus buying an OTA firmware update solution

It is, of course, possible to build your own OTA infrastructure. But building OTA firmware update architecture from scratch is a massively resource-intensive activity. 

That's because any resources fed to the OTA firmware update solution will be resources you're taking from your company's core business. 

The total cost of ownership (TOC)

The TOC of a system includes all the costs associated with the following:

And all of this over the system's lifecycle. 

Even if building your own OTA firmware update solution is cheaper to begin with (which is unlikely), the TOC to cover that system over its entire lifecycle adds up quickly. 

As mentioned previously, many homegrown solutions often only support a single product line because of the complexity of creating OSes that work on different configurations. Companies believe they'll be able to stick with their single solution — until they can't. Then they're faced with the extreme complexity of having to update their solution, so it builds automatically for each version.

We'll talk about some of these steps involved in the following sections. But the essence is that it's highly complex to maintain solutions that work on different devices.So every time you deploy a new type of device, the TOC roughly doubles. 

Scale changes the solution wildly

The scale of your OTA firmware update needs plays a massive role in how your solution will be implemented. Solutions for millions of devices vary greatly from solutions for thousands and solutions aimed at only a handful of devices. 

The larger the scale, the more complex the solution becomes. 

Scalability needs to be built into the solution from the beginning. But developing for scale is a lot more costly — and complicated. Similarly, trying to build scale into an existing solution that wasn't designed for it often requires rebuilding the entire solution from scratch. 

In either case, your company has to develop on a guess, either building scale into the solution from the start and hoping you do scale; or building for just a small number of devices and dealing with the consequences of scaling later. 

Building scalability into a solution that will never scale is like paying the salaries of an in-house team of 20 hot-shot lawyers whom you never use instead of paying for legal insurance at a fraction of the cost. 

Three categories to address when building an OTA firmware update mechanism

To build your own OTA infrastructure for Android, different technological decisions need to be considered along the way.

They roughly break down into three categories: 

Image: Categories OTA firmware update mechanism

Each of these categories has its own challenges and requires its own experts and resources to operate and maintain. 

OS image building

OS image building consists of the following:

Few people appreciate the sheer quantity of computing power required to build a single instance of Android. Lacking that computing power, a single build could take days. 

Using machines with 72 cores, you can build Android in less than an hour. But machines of this size aren't available to everyone. 

Automating the procedure adds further challenges. 

Monitoring the CVE database is another key function. You also have to match those reported vulnerabilities with any vulnerabilities already patched in your code. 

The more devices you support, the more dependencies you have to consider, including their maintenance and especially security patches. 

OS image hosting

Image hosting activities and elements are:

Your hosting server requires authentication so that not everyone can upload OTA firmware update images to the server. Ideally, the hosting server checks code signatures. This prevents the scenario of all your target devices starting an update then realizing the signature is invalid. 

OS image installation

Image installation breaks down into:

The client application can be programmed to allow user interaction or not, and it must be able to communicate with the update server to properly determine the version of the update to download. If the device determines that the version is correct, then it accepts the download. 

It also has to perform the verification of firmware update over the air before installing it. The client app must check everything again — version number, signature, etc. This is done before the installation, not after, to reduce failures. 

Depending on how your client is configured, you can run Android auto OTA updates or require user interaction (manual updates). 

There are many possible ways for an over the air firmware updates solution to be configured precisely. And these details are decided after the major infrastructure has been put into place. 

Finally, after installation, the device must check if the update was successful. If it wasn't, the device needs the ability to recover from the failure. 

Watch this talk by Igor at AOSP and AAOS Meetup to learn more about the three categories to consider when building an OTA update mechanism:

Where do product failures occur?

As you can see, the FOTA update (firmware over the air update) infrastructure is a monolith of different products, each requiring its own specialty and resources. 

OTA firmware updates can fail due to a failure at any of the above points across the three stages. 

This sheds light on a common misconception that the costs associated with risk exploitation are a fleet manager issue. They're not: The costs lie with the product builders because no Android fleet manager could address all of the above from their position. A fleet manager's job is simply: To manage the fleet and issue the OTA firmware update command when it is necessary. 

Product builders need to ensure that all elements of OTA updates are built into their products, so that fleet managers have the ability to update devices easily. 

Automated OTA firmware updates for Android

Mass-produced devices such as phones and tablets tend to come with built-in OTA firmware update functionality. These are pushed to devices by OEMs, such as Samsung and Huawei, in cooperation with telecommunications providers. 

These updates are typically user-driven, but it depends on the device and Android version. Such consumer-device updates are typically carried out to install new Android versions. 

In an industrial context, the matter is entirely different. 

OTA firmware updates require the necessary components on the device as well as the detailed backend infrastructure as described above. 

Fleet managers of several hundred or several thousand devices are unlikely to have the infrastructure in place to carry out OTA firmware updates on their fleets. 

Emteria's core business is to provide an Android solution that works across a wide variety of industrial hardware configurations. To make this happen, we have had to implement a full end-to-end OTA firmware update solution that takes care of every aspect of the OTA firmware update procedure. 

From building to testing, signing, hosting, versioning, releasing, and validating the installation — and so on for every single step in the process — emteria has put the elements in place to implement Over-The-Air software updates easily. 

From the fleet manager's perspective, the entire process is seamless: They simply work through our browser-based Device Hub that lets them control every aspect of the OTA firmware update. The infrastructure is all taken care of. The fleet manager must simply decide which devices get updated and which don't. The Device Hub also lets users experience the benefits of MDM (mobile device management). 

Fully automated updates

Unlike consumer-based devices, where the user must accept an update before it runs, emteria's OTA firmware updates can run entirely automatically or even on a schedule. User interaction is optional. 

This is crucial for many industrial contexts where devices are not user-operated but perform dedicated tasks entirely on their own. 

Easily carry out OTA updates for Android devices with emteria

Emteria has built a full-scale OTA firmware update platform. Customers can use the emteria over the air firmware update platform to update the Android versions on their devices. 

Emteria created its solution to cater to the millions of different custom devices that power the IoT ecosystem but which lack support from major OEMs. Using emteria, you can "plug into" sophisticated OTA firmware update functionality, from a dedicated supplier, and get on with your core business.