Why You Won’t Get N’s Seamless Updates on Your Current Android Device

Why You Won’t Get N’s Seamless Updates on Your Current Android Device

If you read our recap of the events from Google I/O the other day, we detailed how the new seamless update feature was going to work in Android N. You can go back and read the piece for a longer explanation, but in essence Android N borrows the dual-partition setup from Chrome OS in order to facilitate updates.

The secondary system partition is kept dormant and can be updated as necessary and whenever it does receive an update, the secondary partition swaps with the primary partition to become active after a reboot. Now, anyone familiar with dual-booting computers should have immediately recognized that this would pose a problem for currently existing devices on the market. In order to set-up this dual partition system, you would need to resize the partitions currently existing on your device to make room for a new /system partition. As one author on Android Police confirmed with Google, the feature will not be making its way to any current Nexus device. But why? The simplest answer is because it’s too risky.

Android is an operating system just like any other. There are multiple partitions on your device, each formatted in a specific file system format. On my Google Nexus 6P, the partition table can be seen in the screenshot below. The two largest blocks on this device are the /system and the user /data partitions, both of which are formatted as EXT4.


My Partition Table

I run a dual-boot setup on all of my computers with Windows 10 and Chromium OS. Rather than wipe everything on my drive and start-over, I made a backup of my files (just in case!) and then booted into GParted in order to resize my Windows partition (formatted as NTFS). If you’ve dual-booted any Linux distribution before, you’re probably familiar with this process. If not, just know that this entire process can royally mess up and screw up all your data.

Resizing Partitions using GParted

Resizing Partitions using GParted

Most dual-booting guides out there recommend you boot into a tool such as GParted because it’s simply safer to mess with your partitions while they aren’t currently mounted. However, it is indeed possible to re-partition your device on the fly (see such a method on Windows and Linux). So why can’t, or won’t, we be doing this on Android to make room for a second system partition and thus enable seamless updates? Because unlike desktop computers, no such live re-partitioning tool exists for Android.

In order to actually resize the partitions on your device, you would have to hook up your phone to a computer and use something like a version of parted compiled for ARM devices to re-partition. This is certainly possible to do, as one user of an Oppo Find 5 has demonstrated in the past. Motorola Xoom users (remember that thing?) were able to breathe new life into their device thanks to a re-partitioning tool called BigPart. Users of Samsung devices would just need to modify the PIT (partition map) files on their device, which would then tell the ODIN tool what the partition table on the device should look like. Edit: As noted in the comments section, you CAN partition the device while in recovery, but as far as I am aware no advanced partitioning tools have been developed so far. TWRP can change the file system, for instance, but you can’t re-partition your drive.

Okay, so it does seem possible provided you can get a user to hook their device into a computer. Ignoring the fact that this one step basically means the issue is a complete non-starter since so many users will find it to be a pain in the rear to have to (gasp) plug their phone into a computer, there are some further complications we should consider. One major issue is that the bootloader partition on many Android phones is NOT write-protected so have fun with dealing with a brick when something in the re-partitioning method screws up. Some devices such as the ancient Samsung Galaxy S1 can be restored with a special JIG that gives you access to a low-level bootloader that is present on the SoC (in fact, many SoCs have such a bootloader, but it’s gaining access to it that’s the problem). In essence, there’s a chance this could royally mess up your phone and that’s not a chance the OEMs are willing to take.

Though I do wish that Google or OEMs would at least give us the option to enable this feature by affording us the ability to re-partition our devices using an official tool if we so choose. For instance, we could have our devices re-partitioned right before flashing a factory image, as doing this process involves wiping all of our user data anyways. It’s wishful thinking, but I doubt Google will want to maintain two separate branches of their factory images for each Nexus device.

But hey, at least the silver lining on the table is that we here at XDA will find a way. We always do, don’t we?

Correction: changed ‘BIOS’ to ‘bootloader’ as Android devices don’t have a BIOS, though the booting process is similar after the initialization of the bootloader. Android devices are not modular, so there is no need for a BIOS to scan for attached hardware and determine what components are present. At least, until modular phones such as Project ARA become a reality! See this article for an explanation of the full process of an Android boot.

About author

Mishaal Rahman
Mishaal Rahman

I am the Editor-in-chief of XDA. In addition to breaking news on the Android OS and mobile devices, I manage all editorial and reviews content on the Portal. Tips/media inquiries: [email protected]