Комментарии 25
А что такое slot a и slot b в twrp?
Так работает новый механизм обновления системы. Одномернно хранятся две версии каждого системного раздела (boot_a, boot_b, system_a, system_b, vendor_a, vendor_b — а вот к разделу data это, конечно, не относится). Один из них этих слотов считается активным, и именно с него загружается система (то есть, если, например, активен слот a, то bootloader загружает ядро и initramfs из boot_a, /system монтируется из system_a и т.д.). В другом слоте остаётся прошлая версия системы — или, наоборот, только что загруженная новая версия, в которую устройство загрузится при следующей перезагрузке. Подробнее можно почитать здесь, здесь и здесь.
Если вы о свободном месте, которое остаётся после добавления вторых копий каждого из системных разделов, то всё совсем не так плохо, как звучит.
Во-первых, большинство функций recovery по обновлению системы в схеме с A/B-обновлениями выполняет сама система, так что recovery можно сильно упростить (а значит, она будет занимать меньше места). Во-вторых, не нужен раздел cache, на который раньше скачивались обновления перед установкой. В-третьих, вместо того, чтобы хранить odex-файлы предустановленных приложений в разделе system (а они, вроде бы, занимают половину её объёма), можно исходно сохранить их на system_b (вместо образа системы), откуда при первом запуске скопировать в data; а после этого уже использовать system_b по назначению.
Google говорят, что у них на Pixel в результате этих оптимизаций для A/B-схемы потратилось только 320 дополнительных мегабайт по сравнению со старой схемой. Подробнее здесь и ещё вот здесь.
Спасибо!
Именно поэтому первый раз после включения устройства пользователя встречает требование ввести полный пароль или графический ключ, а не просто пройти аутентификацию, приложив палец к сканеру отпечатков.
Получается, графический ключ имеет в системе более высокий статус, чем отпечаток? Можете об этом подробнее рассказать?
Смотрите, разница здесь вот какая. Графический ключ, пин-коды, пароль и т.п. — это чистый, статический кусок информации. Его можно сравнивать (совпадает пароль или не совпадает?), его можно хранить, от него можно взять хэш, на его основе можно создавать ключ шифрования данных и так далее.
А система распознавания отпечатка пальца, лица, радужки глаза… — это именно система распознавания. Она может решить, владелец устройства приложил палец или кто-то другой. В каком-то виде она, конечно, хранит характеристики этого пальца, чтобы его узнавать; но, во-первых, это какая-то нечётная модель, во-вторых, такие характеристики пальца из себя ничего секретного не представляют и создавать на их основе ключ было бы небезопасно.
Повторю другими словами: в одном случае у нас есть явный и устойчивый кусок информации, который нужно сравнивать с другим куском информации (а ещё можно использовать для генерации ключа). В другом случае у нас есть некоторая функция, чёрный ящик, которая возвращает boolean — правильный ли палец прикладывают. Это здорово для аутентификации (не нужно запоминать пароль!), но секретный ключ на основе этого не сгенерировать.
Невероятно интересная и полезная информация. Узнал много нового про устройство этой ОС. Присоединяюсь к просьбам продолжить этот цикл статей. Лично меня также крайне интересует вопрос, почему даже на топовых смартфонах Android начинает тормозить через полгода-год при самом обычном использовании (установлено пара десятков приложений, никаких твиков, рутования и пр.). Решается только полным сбросом, но потом все начинается по новой.
- Большое количество сервисов создаваемых установленными приложениями. Android сильно ограничивает фоновую активность приложений, но при этом позволяет безлимитно создавать приложениям сервисы для работы в фоновом режиме. Чем разработчики от неграмотности или в корыстных целях злоупотребляют.
- Распухание GMS (Generic System Image) с каждой новой версией. Даже если у вас ни разу не обновленный андроид 4.1(но с гулосервисами в комплекте), то стоит там появится интернету, как GMS обновится до последней версии и начнёт потреблять сотни мегабайт ОЗУ.
Android сильно ограничивает фоновую активность приложений, но при этом позволяет безлимитно создавать приложениям сервисы для работы в фоновом режиме. Чем разработчики от неграмотности или в корыстных целях злоупотребляют.
Совсем не безлимитно; в новых версиях (Oreo, Pie) на сервисы наложили серьёзные ограничения, уже нельзя просто так завести сервис и тратить ресурсы. Про это я немного подробнее рассказал в прошлой статье.
Другая особенность предустановленных приложений — они могут получать специальные «системные» разрешения. Например, сторонним приложениям не получить разрешения DELETE_PACKAGES, которое позволяет удалять другие приложения
На самом деле начиная с вроде с версии 5.1, их таки можно получить, если сделать приложение device owner на устройстве.
После установки предпочитаемых сборок recovery и системы bootloader стоит заблокировать обратно
Очень плохой совет. В худшем случае, на некоторых устройствах, можно получить полный кирпич.
Или его надо переформулировать. Залочивать обратно можно только после прошивки стоковых(не модифицированных) boot, recovery, system той-же версии, что и bootloader.
А ещё есть вендор-специфичные костыли реализации anti rollback-а, которые в сочетании с возможностями SoC о Qualcomm вполне себе кирпичат телефоны. А так как xiaomi приволочь-приволокла, но дополнительно навесила авторизацию на флешер для edl — ищи долго и упорно не просто их сервис-центры, а те которые имеют авторизованный на такое аккаунт (или по интернету ищи человека с живым аккаунтом, и договаривайся о деньгах с ним)
С Project Treble пока все далеко до идеала. Более-менее на свежих квалкомах. Но и то все GSI (Generic System Image) прошивки имеют специфичные проблемы на разных устройствах. Не говоря уж, что GSI для квалкома вообще не заработает на МТК.
Ну а вендоры вовсю продолжают патчить framework, делать Samsung Knok, Asus Zen и т.п. (не говоря уж про miui) и городить тонны костылей на всех уровнях.
Про магиск — звучит конечно хорошо, /system не тронута, можно ставить модификации, xposed, обновления.
На деле же все грустнее:
- Народ не понимает зачем оно systemless и все равно жаждет ковырять /system по живому.
- Про инкриментальные ОТА — зачастую все равно можно забыть так как модифицирован рамдиск и если вендор не накостылил проверок — обновление придет, но почти гарантировано не установятся (исключение если в составе инкрементальной ОТА контейнер boot будет целиком, хоть кто нибудь так делает?), Full OTA должны работать, установку магиска после них ожидаемо повторять.
- Модификации (иногда) могут спровоцировать провал проверки системы на модификации (а если речь об xposed — так его вообще спрятать невозможно, все равно будет способ увидеть его наличие).
А суперсу же вроде бы давно не развивается?
С затиранием данных при разблокировке загрузочная тоже ещё недавно было все не совсем здорово. Где то она происходила только при первой разблокировке (xiaomi, sony), где то можно было убедить что разблокировка не первая (sony), а где то можно было провернуть финт ушами залив после разблокировки кастомный рекавери/ядро до загрузки и не потерять данные.
Шифрование, разве пароль создается на основе ключа пользователя? Мне почему то казалось что ключ шифрования устройство генерирует независимо. А уже его шифрует в том числе и на основе данных пользователя. При чем /data зашифрована после первого запуска устройства, а ключ который используется вместо пользовательского по умолчанию "default_password", если при сборке вендор его не изменил. Когда пользователь устанавливает свой пароль в зависимости от прошивки ключ которым зашифрована /data автоматом перешифровывается (ну или в зависимости от прошивки пользователю для этого нужно будет нажать ещё одну кнопку в настройках). Это позволяет избежать перешифровки огромного количества данных хранящихся в /data и происходит быстро. С появлением file-based стало все ещё лучше (ну собственно о его преимуществах тут и говорили). Правда гугл не обязывает вендоров волочь новые фичи для устройств которые обновились до определенной версии ОС, поэтому даже имея 8й андроид на устройстве может быть полнодисковое шифрование вместо пофайлового (которое появилось в 7 андроиде)
К сожалению пока писал — забыл ещё один пункт который хотел упомянуть в начале.
Рутом я баловался давно и вот с рутом было удобно именно то, что можно все ненужное предустановленное снести…
По факту я рута именно для сноса хлама использовал и больше он мне не нужен был ни разу. Так что по мне рут (временно) нужен именно сразу после покупки/обновления — дальше бы его залочить обратно и забыть.
Как работает Android, часть 4