Google has taken a page from their own Chrome OS for the new update method. Chromebooks have effectively always worked like this: the update downloads in the background, then prompts the user that a reboot is needed to finish the installation process. One quick reboot later, and the update is complete—no waiting for the update to install, no “optimizing,” or any of that other stuff that seems to take ages. It’s quick, easy, and most of all, doesn’t have an unreasonable amount of downtime.
Starting with Android 7.0, this is the direction Android updates are going. It’s worth mentioning here that this will not apply to devices updated to Nougat, only those that ship with the software. The reason for this is perfectly logical: this new update method will require two system partitions in order to work, and pretty much all current Android phones only have one. Re-partitioning the device on the fly could be potentially catastrophic (and likely would be in many scenarios), so Google’s decision to leave it alone on current generation phones is respectable, albeit a bummer.
It works a little something like this: there’s an active system partition and a dormant partition, which are mirror images of each other. When an OTA update becomes available, the active partition downloads it, and then updates the dormant partition. One reboot later, the dormant partition becomes active, and the formerly-active partition becomes dormant, this applying the updated software.
Table of Contents
We Haven’t Seen This In Action Yet, So There Are Still a Lot of Questions
Of course, it comes with its own set of questions and concerns. While we understand how this system works in theory, we have yet to see how it actually performs in practice, since Nougat hasn’t had an update yet, and no devices have shipped with 7.0. Anything is speculation, but I’d imagine that when an update is being applied, for example, there will likely be a pretty hard hit to system performance.
In addition, if you’re anything like me, you read the above section and thought: “how much space will having two system partitions take?” One might automatically assume that it will take twice the amount of space, which isn’t completely incorrect, but you also have to remember that these are system partitions, which doesn’t mean it will require two copies of every app installed. Still, that means current systems that take one gigabyte—a not uncommon size for an Android OS—could essentially now require two gigabytes (or more).
That said, Google has moved to a new file system called SquashFS, which is a highly-compressed, read-only file system originally designed for embedded systems in low-memory situations. This should definitely help offset some of the space issues that will inevitably go along with having a two-system-partition setup. Still, we may start seeing devices ship with a minimum of 32GB moving forward. Time will tell.
It’s also unclear what happens to the new dormant partition after the update. There’s a possibility that it could then get updated in the background and then wait for another new OTA to arrive, but there’s no technical documentation to support this theory—just me thinking out loud. Still, it seems to make sense to me, because otherwise this new system would apparently seem like a once-and-done sort of update scenario, which is exactly the opposite direction that Google is trying to go here.
Unfortunately, since there isn’t yet a device that supports the new Seamless Update system, some of these questions will just have to go unanswered. Once the new generations of phones start to roll out, we’ll have a much better understanding of how all this will work in the real world. But for now: It sounds like a very good thing.