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.
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.
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.
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 BIOS 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?
from xda-developers http://ift.tt/1sG8JKA
via IFTTT
Aucun commentaire:
Enregistrer un commentaire