Linked by Thom Holwerda on Mon 7th Aug 2017 20:16 UTC

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 Internet directly to 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.

Thread beginning with comment 647660
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by tidux
by cacheline on Tue 8th Aug 2017 01:17 UTC in reply to "Comment by tidux"
Member since:

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!

Reply Parent Score: 1

RE[2]: Comment by tidux
by tidux on Tue 8th Aug 2017 17:42 in reply to "RE: Comment by tidux"
tidux Member since:

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.

Reply Parent Score: 2

RE[3]: Comment by tidux
by Licaon_Kter on Tue 8th Aug 2017 23:00 in reply to "RE[2]: Comment by tidux"
Licaon_Kter Member since:

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

Reply Parent Score: 1

RE[3]: Comment by tidux
by jgfenix on Thu 10th Aug 2017 20:12 in reply to "RE[2]: Comment by tidux"
jgfenix Member since:

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

Reply Parent Score: 2