Многие современные девайсы используют трюк с двумя загрузочными дисками чтобы предотвратить окирпичивание. Т.е. мы загрузились с одного, во втором делаем апдейт, потом загрузчик пытается загрузиться с него, если получилось то он стал основным, если нет то вернулись на прошлую. Так сделано и на стимдеке, и апплом, и на андроидах.

Т.к. держать две копии системы дорого, то обычно там делают трюки. Например, аппл использует снапшоты в APFS, чтобы иметь две copy-on-write версии (и для загрузки они вообще монтируют снапшот ридонли). Андроид тоже использует copy-on-write трюки, но чутка по другому

Собственно, в свежем 17 андроиде есть два пути: когда новый образ не сильно отличается, то отработает copy-on-write, но на толстом образе сработает резервный механизм. Так вот, первый способ обновления оказался сломанным если мы закидываем апдейт через adb sideload, если наш образ слишком маленький (как, например, у господ из GrapheneOS). Но очень профессиональные разработчики из гугла даже не заметили этого, ибо чистая прошивка пикселя (а там еще не так чтобы много bloatware) не влезала в то место, и всегда срабатывал фолбек

Так что в итоге господа из GrapheneOS пошутили что "мы бы могли починить работу апдейтов докинув в архив прошивки гигабайтный файл с мусором, но мы же не настолько профессионалы, как товарищи из гугла, поэтому подождите нормальный фикс"

https://fxtwitter.com/GrapheneOS/status/2067626061274247451