When you get that “out of space” error message during an update, you’re only “out of space” on the user storage partition,which is just being used as a temporary download spot before the update is applied to the system partition.Starting with Android 8.0, the A/B system partition setup is being upgraded with a”streaming updates” feature. Update data will arrive from the Internetdirectlyto the offline system partition, written block by block, in a ready-to-boot state. Instead of needing ~1GB of free space, Google will be bypassing user storage almost entirely, needing only ~100KB worth of free space for some metadata.
I promise not to make some snide remark about Android’s update mess.
In other news I download files to the free space on my hard drive.
In a way, I could see that. But, it sounds more like they’re just marking a portion of your free space as reserved, so in reality, it’s not free to user apps or the system for storing data, cache, etc.
So this is basically piping curl into dd of=/dev/mmcblk0pN without stopping to hash check the arriving binary? Fantastic, now we’re one MITM away from giving network attackers full root. Intelligence agencies everywhere are nutting in their pants.
Wait, did I miss something in the article (if I did, please point me to it, not being facetious, I’d really like to know)? Where did it say they weren’t doing any kind of validation on the incoming binary?
With all the kernel hardening and efforts they’ve gone to, I’d be surprised if they did NOT check the incoming update for that. But, if there’s an indication they really did miss that, I’d like to know!
There’s no way for them to do it ahead of time or while the transfer is running within the constraints imposed by the “100K of disk space” claim. At most they can do a hash check after the fact, and an attacker could force a reboot between the write and the hash check.
Some ideas:
* 100kb is for metadata (eg. checksums I guess)
* it downloads to the “other” boot partition directly
* it could very well hash every chunk (think bittorrent, say every 4Mb)
* a reboot would not change to “other” boot until the update process validates and marks the switch
It sounds rather well.
Edited 2017-08-08 23:01 UTC
> it downloads to the “other” boot partition directly
Nope, that’s not what it does.
The article says: “Update data will arrive from the Internet directly to the offline system partition”
What did I misunderstood exactly?
Do you have more info? Links?
Feel free to actually explain your “nope”
The “offline” system partition refers specifically to the partition not currently in use by the running OS.
And now you are disagreeing with yourself. Nice job.
Yes, but it has two system partitions. This is how I think it works.
1) System partition A is active. If there is a reboot or power failure it will boot to A.
2) The updater downloads the update and writes to system partition B.
3) After finishing the update B is validated. If the validation fails it’s marked as invalid (an the update is attempted again/postponed/it gives an error/A is copied in B/whatever). If it’s ok it’s marked as valid.
4) It reboots and B is marked as active so it boots to B.
5) The usual Android update (optimizing apps, etc).
6) The system boots up.
7) B is copied in A. A is validated the same as B. If it’s a success both partitions are marked as valid.
8) Now the update is finished.
Edited 2017-08-10 20:13 UTC
I agree Android’s updating mechanism has been a mess (more for non-Google branded phones than anything else). And as an Android dev, I’d love to drop support for KitKat (almost there, just not quite yet), as so many things become easier once you do. But, I’m looking with eager anticipation to see what Project Treble does. If they did their job well, in 2 years from now (once everyone can upgrade phones), we might well see users upgrading about as fast as iOS users do. That’s a day I’d love to see. So, I’d rather give Google the benefit of the doubt here, and have some optimism…
https://arstechnica.com/gadgets/2017/05/google-hopes-to-fix-android-…
Dude you know how many NEW devices are still being sold with KitKat? Go look on amazon and have your hopes crushed like a bug at getting rid of KitKat anytime soon.
BTW I hope you really like supporting Lollipop as that looks like the next Android version they are gonna pump out for years, going to several phone stores with my wife I noticed that many of them had frankly insane amounts of new phones running 5.1.
IDK if its device drivers, ease of support, or what but it seems like the OEMs lock onto one version of Android and then just skip 2-3 releases before moving up to the next release and repeating the process.
I want to like this, but if something happens DURING a streamed update, there better be some kind of backup.
Well duh… That’s what a second partition is for.
So many people seem to think this is a simple file download and instantly find problems with it.
What makes you think Google didn’t already think of those problems?
The phone isn’t going to boot from the updated partition until it has verified the new downloaded image is correct.
Why would anyone think that it would?
Mainly, because people are dumb, but think they are very smart (so smart they outsmarted Google’s engineers in few minutes).