Обновить необновляемое. Treble, A/B-разметка, динамические и модульные обновления Android

Содержание статьи

• Treble
• A/B-разметка
• Шпаргалка по управлению A/B-разделами с помощью fastboot
• Динамические обновления
• Виртуальная A/B-разметка
• Модульные обновления
• Трюк с сохранением пространства
• Выводы

Представь себе смартфон, который обновляется до новой версии ОС за секунды. Смартфон, который никогда не превратится в кирпич из-за неудачного обновления. Смартфон, который позволяет устанавливать вторую прошивку рядом с основной и поддерживает десятки кастомных прошивок сразу после выхода с конвейера. А ведь все это уже реальность, которую даже не надо ждать.

Эта статья рассказывает о ряде технологий, которые были интегрированы в Android в последние несколько лет и приблизили решение проблемы фрагментации, отсутствия обновлений и существенно упростили создание кастомных прошивок.

Treble

Вопреки расхожему мнению, основная проблема, с которой сталкиваются производители смартфонов при обновлении прошивок своих телефонов, — это вовсе не пофигизм и лень (хотя это тоже часто встречается), а необходимость ждать, пока производители чипсетов и других хардварных компонентов обновят драйверы до новой версии Android.

Дело в том, что Android, как и многие другие продукты Google, очень долгое время развивался в режиме вечной беты. Это значит, что Android менялся. Не только и не столько в плане интерфейса, сколько в плане внутренней архитектуры.

В Android никогда не было устоявшегося, обратно совместимого интерфейса между системой и драйверами. В большинстве случаев нельзя было просто взять новую версию Android и «посадить» ее на драйверы и ядро Linux от старой версии. Почти всегда что-нибудь да отваливалось.

Требовались обновленные драйверы, разработкой которых занимался производитель железа, а вовсе не производитель смартфона. Поэтому, если производитель чипсета, камеры или Wi-Fi адаптера по тем или иным причинам отказывался поддерживать старое железо (что происходит очень часто, а в случае с такими компаниями, как MediaTek, постоянно), полноценный порт новой версии Android становится почти невозможен.

Создатели кастомных прошивок искали обходные пути, чтобы заставить новую версию Android работать на старых драйверах. В дело шли любые приемы от простого «не работает, забейте» до различных программных прослоек, обеспечивающих работу на устаревших драйверах. Так, в кастомных прошивках для Xiaomi Redmi 1s есть прослойка, которая позволяет использовать камеру в Android 7.1.1, хотя драйверы для нее застряли еще на уровне версии 4.4.4.

Однако для компании — производителя смартфона такой подход зачастую неприемлем. Устройство с выполненным подобным образом портом может просто не пройти сертификацию Google. Кроме того, такие прослойки нередко приводят к сбоям в неожиданных местах и не обеспечивают новую функциональность, которая может требоваться Android для корректной работы (например, поддержка новых режимов камеры).

К счастью, в какой-то момент Google решила положить конец этой вакханалии и стандартизовать-таки программный интерфейс между драйверами и Android. Это и есть инициатива Treble, и она была воплощена в жизнь в Android 8.0.

Суть Treble проста и уже должна быть понятна: код Android разделяется на две независимые части, одна из которых содержит драйверы и весь зависимый от железа код, а вторая — саму операционную систему. Программный интерфейс между этими компонентами стандартизуется и остается стабильным между релизами Android. Как результат, для портирования новой версии Android достаточно портировать платформенно независимую часть системы, и она корректно заработает на имеющихся драйверах и версии ядра Linux, с которой смартфон был выпущен на рынок.

Это в теории. На практике же есть пара подводных камней.

1. Android будет продолжать развиваться, и новые функции могут потребовать изменений в Treble. Разработчики Android предусмотрели это и гарантируют, что существующие версии API Treble будут поддерживаться минимум три года (пока неточно). При этом часть функций, которые не могут быть реализованы с использованием старых версий Treble, будут либо эмулироваться, либо просто отключаться. По сути, Android будет включать официальные прослойки совместимости по типу тех, что раньше приходилось придумывать разработчикам кастомных прошивок.
2. Treble до сих пор находится в процессе развития и содержит несколько важных API (например, в совместимых с Treble прошивках может отвалиться сканер отпечатков пальцев). Также существует проблема, когда производитель смартфона намеренно или случайно ломает Treble API (привет, Huawei), так что без костылей Treble-совместимые прошивки на таком смартфоне не заработают.

Теперь о самих Treble-совместимых прошивках. Сразу после выпуска Android 8.0 Google начала публиковать так называемые образы GSI (Generic System Image). Это официальная сборка «чистого» Android (AOSP) для Treble-совместимых устройств. В теории ее можно прошить на разблокированное устройство с помощью fastboot и получить официальный Android.

Чуть позже GSI-сборки начали подготавливать и разработчики кастомных прошивок. Например, ты можешь скачать GSI-сборку от phhusson с множеством фиксов для разных устройств. В теме, посвященной Treble, на 4PDA есть множество Treble-совместимых прошивок, включая LineageOS. Ну а проверить свое устройство на совместимость с Treble можно с помощью приложения Treble Check.

A/B-разметка

Еще одна проблема с обновлениями — отказ пользователей. Как показывает практика, многие владельцы смартфонов не хотят обновлять свои устройства, потому что: а) это отнимает время, в течение которого смартфон будет недоступен для использования; б) после обновления смартфон может работать некорректно или не включится вообще.

В свое время разработчики Chrome OS также столкнулись с этой проблемой и создали надежную и незаметную пользователю систему бесшовного обновления (Seamless updates). Суть ее состоит в том, что вместо одного системного раздела, поверх которого накладывались бы обновления системы, Chrome OS использует два идентичных системных раздела, каждый из которых содержит свою копию операционной системы.

Обновление в Chrome OS происходит следующим образом: когда ОС обнаруживает наличие обновления, она скачивает его в фоне, устанавливает на второй (неактивный) системный раздел и помечает этот раздел как активный. После перезагрузки (не обязательно сразу после обновления) ОС запускается уже с этого раздела.

Благодаря такой схеме пользователь даже не подозревает, что система обновилась, он просто попадает в обновленную ОС после перезагрузки или включения ноутбука. При этом Chrome OS способна гарантировать, что после обновления пользователь не получит кирпич: если во время загрузки с обновленного раздела произойдет сбой — система пометит текущий раздел флагом unbootable, сделает активным «старый» системный раздел и загрузит заведомо рабочую версию ОС.

Начиная с седьмой версии Android также поддерживает бесшовные обновления и так называемую A/B-разметку разделов. Однако, так как системных разделов в устройствах с Android намного больше, чем в хромбуках, сама раскладка разделов получается более запутанной. Вот только часть разделов, которые пришлось дублировать:

• boot — содержит ядро и RAM-диск, на устройствах с A/B-разметкой также консоль восстановления (recovery);
• system — содержит Android, системные библиотеки, системные приложения, стандартные рингтоны, обои и так далее;
• vendor — драйверы и все необходимые прослойки для работы с железом (Project Treble);
• userdata — настройки, приложения и данные пользователя;
• radio — прошивка радиомодуля (поддержка сотовых сетей);
• vbmeta — раздел Android Verified Boot 2.0 (механизм доверенной загрузки), содержащий контрольные суммы компонентов системы.

Всего дублированных разделов может быть несколько десятков. Например, на OnePlus 6 с A/B-разметкой общее количество разделов — 72 и несколько десятков из них используются только загрузчиком.

От других разделов, наоборот, стало возможным отказаться. Устройства с A/B-разметкой не включают в себя отдельный раздел recovery (консоль восстановления, нужна для установки обновления и сброса до заводских настроек) и раздел cache, который использовался для хранения файлов обновлений (теперь обновление скачивается напрямую в неактивный раздел).

A/B-разметка также позволила вдвое сократить размер раздела system, что вкупе с удалением разделов recovery и cache сделало переход на новую схему разметки менее болезненным. Например, на смартфонах Pixel потеря пространства составила всего несколько сотен мегабайт.

Еще одно достоинство A/B-разметки — отсутствие экрана «Android is upgrading…» после обновления. Система просто загружается как обычно. Также A/B-разметка упрощает тестирование кастомных прошивок: кастом можно поставить второй системой и откатиться на первую, если что-то пойдет не так.

В целом одни плюсы и никаких минусов. Проблема только в том, что A/B-разметка до сих пор остается опциональной, а перешли на нее далеко не все производители смартфонов. Даже Samsung — крупнейший производитель устройств на Android — до сих пор использует старую разметку. И связано это, скорее всего, с нежеланием тратить средства и время на перепрофилирование уже работающей и отлаженной системы обновления.

Проверить, поддерживает ли твой смартфон A/B-разметку, можно с помощью все того же приложения Treble Check из предыдущего раздела или прочитав переменную ro.build.ab_update с помощью ADB:

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Я уже участник «Xakep.ru»

Источник