Pull to refresh

Comments 25

Так работает новый механизм обновления системы. Одномернно хранятся две версии каждого системного раздела (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 дополнительных мегабайт по сравнению со старой схемой. Подробнее здесь и ещё вот здесь.

Я даже больше скажу, у некоторых вендоров уже есть специальный раздел для каких то своих целей (в эпоху до treble xiaomi хранила кастомизации под регион в разделе /cust, а это тоже хороший кусок памяти. Как сейчас у них не знаю) и после подобной переразметки потерь может и не быть вообще (тем более что подобные кастомизации теперь можно и в /vendor хранить, все равно оно в том числе и для вендорских костылей)
Именно поэтому первый раз после включения устройства пользователя встречает требование ввести полный пароль или графический ключ, а не просто пройти аутентификацию, приложив палец к сканеру отпечатков.


Получается, графический ключ имеет в системе более высокий статус, чем отпечаток? Можете об этом подробнее рассказать?

Смотрите, разница здесь вот какая. Графический ключ, пин-коды, пароль и т.п. — это чистый, статический кусок информации. Его можно сравнивать (совпадает пароль или не совпадает?), его можно хранить, от него можно взять хэш, на его основе можно создавать ключ шифрования данных и так далее.


А система распознавания отпечатка пальца, лица, радужки глаза… — это именно система распознавания. Она может решить, владелец устройства приложил палец или кто-то другой. В каком-то виде она, конечно, хранит характеристики этого пальца, чтобы его узнавать; но, во-первых, это какая-то нечётная модель, во-вторых, такие характеристики пальца из себя ничего секретного не представляют и создавать на их основе ключ было бы небезопасно.


Повторю другими словами: в одном случае у нас есть явный и устойчивый кусок информации, который нужно сравнивать с другим куском информации (а ещё можно использовать для генерации ключа). В другом случае у нас есть некоторая функция, чёрный ящик, которая возвращает boolean — правильный ли палец прикладывают. Это здорово для аутентификации (не нужно запоминать пароль!), но секретный ключ на основе этого не сгенерировать.

Невероятно интересная и полезная информация. Узнал много нового про устройство этой ОС. Присоединяюсь к просьбам продолжить этот цикл статей. Лично меня также крайне интересует вопрос, почему даже на топовых смартфонах Android начинает тормозить через полгода-год при самом обычном использовании (установлено пара десятков приложений, никаких твиков, рутования и пр.). Решается только полным сбросом, но потом все начинается по новой.

  1. Большое количество сервисов создаваемых установленными приложениями. Android сильно ограничивает фоновую активность приложений, но при этом позволяет безлимитно создавать приложениям сервисы для работы в фоновом режиме. Чем разработчики от неграмотности или в корыстных целях злоупотребляют.
  2. Распухание 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 — ищи долго и упорно не просто их сервис-центры, а те которые имеют авторизованный на такое аккаунт (или по интернету ищи человека с живым аккаунтом, и договаривайся о деньгах с ним)

Жестким antirollback'ам уже давно прославилась Motorola. Использование QFUSE делает телефоны полными кирпичами…

С 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 андроиде)
К сожалению пока писал — забыл ещё один пункт который хотел упомянуть в начале.

Что меня напрягает так это бешеное количество предустановленного софта и кастомных интерфейсов во всех мал-мальски брендовых мобилах.

Рутом я баловался давно и вот с рутом было удобно именно то, что можно все ненужное предустановленное снести…

По факту я рута именно для сноса хлама использовал и больше он мне не нужен был ни разу. Так что по мне рут (временно) нужен именно сразу после покупки/обновления — дальше бы его залочить обратно и забыть.
С момента выпуска прошлой статьи не прошло и года) Специально дату подгадали?
Будет… когда-нибудь, когда на него найдётся время.
Последняя статья очень интересная, потому что наконец становится понятен смысл всех этих магических телодвижений по прошивке аппарата кастомной прошивкой, и по-моему это вообще единственная статья на Хабре по внутрянке андроида. Ещё бы подобную статью на тему, как сделать свою прошивку — а-ля Linux From Scratch )
Ждем и надеемся. Действительно интересный цикл статей, спасибо.
Прочитал весь цикл статей на одном дыхании. Во времена SGS III, увлекался установками различных сборок и прошивок, вот теперь многое из того что делал, стало понятнее. Не читал ничего более понятного, интересного и «по делу» про устройство андроида. Спасибо большое, и ждем продолжения!
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2015
Location
Россия
Website
rt-solar.ru
Employees
201–500 employees
Registered

Habr blog