In all generations of Android devices—up to an including Marshmallow—operating system updates have essentially worked the same way: the update is downloaded, the phone reboots, and the update is applied. During this time, the phone is rendered useless, at least until the update has been fully installed. With Nougat’s new “Seamless Updates,” this model is a thing of the past.
How Updates Have Changed in Android 7.0 Nougat
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.
RELATED: How to Manually Upgrade Your Nexus Device with Google’s Factory Images
Not only does this make the entire update process immeasurably faster, but it also serves as a sort of backup system. Should something go awry with the update, the system can detect that there’s an error while booting, and simply flip back to the unaffected system partition. Upon reboot, it can then ping the download servers once more, re-apply the update, and reboot again to complete the process. Compared to how catastrophic update failures are handled in the current system—which requires a lot of user interaction, Android development tools, and familiarity with the command line—the dual-partition method is simply better.
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.
