From Google to your phone: The life of an Android security update

At the beginning of every month, Google releases the monthly Android Security Bulletin and starts to send updates to Pixel phones. It’s great that the company is transparent about what is going on and how things are being fixed even if you’re not the type of person who likes to read the source code.

There is a lot of work that goes into these patches before they are made public, and there is even more work involved before it comes to other phones — if it comes at all. Let’s take a look at how the sausage is made and try to have a better understanding of why the timeline for security patches is a little blurry.

First you fix Android

Android is a complicated beast. Over 5 million lines of code, it exists to help companies that make mobile products get up and running with a complete application platform including access to Google Play and other services. It’s not something that can be used as-is; these companies spend a lot of time trying to get Android tailored to merge into the other software they may be using to create a nice homogenized operating system.

Google has some rules about how this should be done should a company want to include its services, but manufacturers have a long leash on how the final product is built.

This code is where a security patch comes to life. Someone, be it a security researcher or just an average Joe, finds a flaw in a phone that could be used to lessen the device’s security layer. If that flaw isn’t something an OEM created, the Android team is tasked to find out what’s happening, why it’s happening, and how to fix it in the least disruptive way.

If a security flaw is found and it’s part of the base Android code, Google has to fix it then send it along to everyone else.

Often, the flaw isn’t something Google can fix. Like us, Google doesn’t have access to firmware from companies that make hardware like Qualcomm or LG. If the flaw needs to be addressed at the hardware level there is a good chance the company that supplies some of the components used will need to make changes first. If this is the case, those changes are forwarded to Google so that it can see what needs to be done to accommodate them in Android’s code.

These changes take time, especially if a hardware vendor is involved. There is patching and testing and more patching and more testing for each and every flaw addressed in a patch. Once Google is confident that they have a valid fix for a security flaw, every company who makes Android phones is given early access (at least 30 days before the patch is made public by Google) so they can get to work.

Phase two

This is where most of the work is done. Google may write and maintain Android itself, but the bulk of devices that use it are not made by Google. The ones that are — Pixel phones — are also included here. Google hardware is a customer of Android the same way Samsung or Motorola is.

The Samsungs and LGs of the mobile industry, which make a lot of changes to Android, have a lot of work involved when it’s time to merge a patch.

All of these companies get to work on a couple of things as soon as they have new code from Google. The first — and possibly most important — part is determining what part of the patch is not needed. And there are plenty of things in every patch a single company can freely ignore.

For example, if NVIDIA had to make changes that are pushed back into Android, no Samsung phones will need that part of the patch. A more extreme example would be the changes that BlackBerry or Samsung made that already address the problem in a different way. Finding out what’s needed and what isn’t can be time-consuming, especially when a company makes large changes to certain portions of the operating system. Google investigated accusations that OEMs were sending security patches that did not address some things they should have, and this is what it found.

Not every part of a patch is needed on every phone.

Once that’s done, the rest of the patch needs to be merged into a vendor’s custom Android code, then built and tested. The “built and tested” part can become a big headache if the patch can’t just be applied because it touches files that custom code is using or depends on. We see that a lot, too. Whenever Bluetooth or Wi-Fi is patched, whether it be the hardware or the software behind them, it will touch code that has been altered by a large OEM that makes a fancier operating system than “stock” Android. There are a lot of parts of Android that an OEM can touch.

Once the engineers at Samsung or another vendor get an operating system that boots up and runs, it needs to be tested. And tested some more. The testing may include getting network engineers from various carriers involved, as well as having Google and/or the manufacturer of any component back into the mix. It has to be right. A patch sent out to thousands and thousands of phones could potentially cripple a carrier’s network, eat up every user’s data cap, or even cause the phone itself to stop working. Anything of the sort is unacceptable and has to be found before it leaves the building.

The rollout

The company that made your phone, Google, and maybe your carrier work together to get a mass over-the-air update ready. If you’ve ever seen the URL that is used to download a patch, you’ll notice it has “Google” in the web address. That’s because the engine inside your phone that can fetch and process an OTA update is looking in a very specific place for a patch. It needs to know that the patch is 100% correct and signed by the right digital signature. It will check this again once the patch is fully downloaded.

If you bought your phone from a carrier, it has plenty of input during the entire life of a patch.

Your carrier may have some rules about when and who can download a patch once it’s live if their name is on the phone. Companies like Samsung or LG make custom versions of their most popular models for each carrier, which has plenty of input into how things are done. It should since its name is on the box. This can be frustrating, but it makes sense. If everyone in Pittsburgh (for example) who has a Samsung Galaxy S8 phone tries to fetch an 800MB patch at the same time, the network is going to crumble in spots. Your carrier will do anything it needs to do in order to keep the network alive.

Google also places a sort of hold on OTA rollouts. A specific number of users will receive a patch, and after a set amount of time, Google determines if those users had a good experience or a bad one. If all goes well, a larger number of users will get the patch in a second wave. This repeats several times before the floodgates are opened. Users who do not wish to wait for this final testing can manually download a patch through their device settings.

When it’s your turn and you gave your phone the green light to grab that file, it’s downloaded and then your phone takes control.

In your hands

A patch is downloaded to your phone and verified as being the right stuff. Older versions of Android have a dedicated cache, which is a section of your storage that has been divided off for things like an update file to live; things that are only temporarily on the phone. Phones that use Android’s seamless update feature (which should be most phones running Android Nougat when sold) “slip” the downloaded files into what are called slots. In either case, you need to have enough space for the OTA file to be extracted and worked on.

The OTA updater software in your phone is a part of Android. A script in the downloaded file tells it how to go about finding the files that need altered and it copies those files either into your device cache or into the designated slot. It then compares the original files on your phone with the files that have been downloaded. Some may be a simple swap — take file X from the phone and delete it, then replace it with file X from the OTA download. Others aren’t the full file and only contain small specific changes. The updater and installer software in your phone know what to do here.

Many files in Android, especially the applications and software libraries, are really a lot of files compressed into a special archive. You can take an APK file and change it to a .zip file and open it with Windows. Sometimes these archives need to be opened and portions of them need to be swapped with new versions downloaded for the security patch. That’s why you need that working space in your cache partition — that’s where these files are extracted.

A lot of files on your phone are really archives containing many files — including other archives of files. It’s complicated.

Once every file in the OTA update has been processed and changes made to copies of system files, it’s time to run the system with them. This happens when the phone asks you to reboot after it processes the OTA you received because there are often files that need to be patched but are in use while the phone is running. You may see a screen showing that there is work going on during the reboot or you may just see the Android logo. In either case, files are being checked, moved into place, and checked again. The old files are kept in the cache just in case there is a problem and you can’t boot with the new files.

All that’s left is for you to make sure everything is still just how you like it, and you have a newer date for the Security Patch version in the settings of your phone. Now you’re ready for the next update!