Как разделы A/B и Seamless Updates влияют на разработку прошивок?

Когда была выпущена Android Nougat, мы получили обновленный пользовательский интерфейс, а также долгожданные возможности multiwindow и поддержку API Vulkan Graphics. Android Nougat представила «Бесшовные обновления» на устройствах, поддерживающих разделы A/B. Подавляющее большинство существующих Android-устройств (за исключением нового Google Pixel и Google Pixel XL) в то время не имели разделов A/B и, следовательно, не могли использовать бесшовные обновления. Основная предпосылка этой функции заключается в том, что устройство имеет второй набор системных, загрузочных, вендоров и других важных разделов, а когда вы получаете обновление OTA, обновление происходит в фоновом режиме, а второй набор разделов исправляется, это означает что вы плавно переходите к обновленной версии программного обеспечения. Если обновление не удастся, вы будете отброшены в рабочую сборку, то есть у компаний будет меньше головных болей, и потребители будут лучше защищены.

Поддержка бесшовных обновлений не является обязательным требованием для любого нового устройства Android, в отличие от Project Treble. Таким образом, подавляющее большинство новых устройств Android не поддерживают эту функцию. Это позор, потому что разделы A/B приносят много преимуществ как для обычных пользователей, так и для опытных пользователей. Тем не менее, эта функция имеет немного плохую репутацию в сообществе энтузиастов, потому что она воспринимается как сложная разработка Android. На самом деле это не так, поэтому мы хотим демистифицировать бесшовные обновления и объяснить, как разделы A/B влияют на разработку кастомных прошивок.

Разделы на Android-устройстве

Раздел - это просто дискретный раздел на внутренней памяти телефона, где хранятся данные. Какие данные хранятся в каждом разделе, зависит от оборудования, операционной системы и многих других факторов. У загрузчика будет один, у системы (Android OS) будет второй, у пользовательских данных будет третий и т.д. Когда вы видите, что люди говорят о «/system» и «/cache», они ссылаются на данные имена для этих разделов. OnePlus 6, например, имеет 72 раздела. Это звучит много, но OnePlus 6 - одно из устройств, поддерживающих бесшовные обновления, это означает, что многие из этих разделов просто дублируют друг друга.

Частичный вывод разделов на OnePlus 6. Некоторые разделы A/B подчеркнуты для демонстрационных целей.

На устройстве есть много разделов, о которых вам не стоит беспокоиться. Многие из этих разделов никогда не изменяются при кастомизации пользовательских ROM, ядер или модификаций, таких как Magisk или Xposed. Многие из этих разделов будут либо неиспользованными для наших целей, либо слишком опасны для прикосновения, если вы не знаете, что вы делаете. Большинство пользователей Android в основном имеют дело с syste, boot, recovery, userdata и более поздними версиями vendor и vbmeta. Вот краткое описание цели каждого раздела:

system - содержит ОС Android, системные библиотеки, системные приложения и другие системные носители, такие как загрузочные файлы, стоковые обои, мелодии и т.д.

boot - содержит ядро, ramdisk и разделы A/B, а также восстановление

recovery - содержит восстановление, где TWRP чаще всего мелькает на устройствах A-only (устройства A / B не имеют выделенного раздела восстановления)

userdata - содержит все данные ваших приложений, системы и внутреннего хранилища

vendor - поддерживает платформу и специфичные для устройства HAL-файлы, файлы, необходимые для ОС Android для связи с базовым оборудованием

vbmeta - раздел для Android Verified Boot 2.0, который проверяет целостность процесса загрузки

OEM-производители устройств могут изменять свои схемы разделов для использования любого макета, который они хотят. Например, Huawei разбивает загрузочный раздел на ramdisk_recovery и ядро. Есть также множество дополнительных разделов, которые могут содержать другие системные приложения, такие как cust, product и oem, хотя они безопасны для изменения, обычно не рекомендуется их трогать.

Схема разделов A/B

Как обновления работают на устройствах с бесшовными обновлениями:

Самое простое изображение иллюстрирует, как обновление обрабатывается на устройстве с поддержкой раздела A/B. Воспроизведенный раздел представляет собой системный раздел, хотя другие разделы, такие как boot и vendor, также могут быть обновлены с любым предоставленным обновлением OTA от OEM-производителя. Этот процесс обновления происходит не только с крупными обновлениями для Android-версий, но и с обновлениями обновлений безопасности.

Мы начинаем с двух системных разделов system_a и system_b, как в той же версии Android.
Предполагая, что system_a активен, обновление OTA будет исправлять системный_b, неактивный раздел, в фоновом режиме.
system_a устанавливается в неактивное состояние, а system_b становится активным после перезагрузки пользователя.
Теперь неактивный раздел, system_a, будет обновлен, когда будет обновлено следующее обновление OTA.

Преимущества такого процесса обновления:

Если при обновлении произошёл сбой, устройство вернется к рабочей сборке в другом слоте.
Ваши данные сохраняются совершенно неповрежденными, даже если обновление оборвано, так как есть только один раздел (userdata), в котором хранятся ваши данные.
Обновление потоковой передачи: если ваш раздел данных заполнен, обновление можно загрузить и передать в неактивный слот. Это довольно аккуратная функция и означает, что вам не нужно тратить какое-либо временное хранилище на свои обновления. Вот почему на устройствах A/B нет кэша, поскольку он больше не нужен.

Какое влияние имеет схема разделения A/B на хранение данных?

Неужели тот факт, что бесшовные обновления приводят к кучке дублированных разделов, означает, что вы теряете кучу пространства для хранения? Не за что. Google утверждает, что устройства с поддержкой бесшовного обновления должны быть сокращены всего на несколько сотен мегабайт благодаря удалению разделов /cache и /recovery. По словам Google, изображение системы A/B Pixel составляет половину размера изображения системы A-only. Большая часть использования дополнительного хранилища фактически связана с добавлением второго раздела поставщика. Это имеет смысл, так как в разделе поставщика размещаются все проприетарные двоичные файлы, используемые OEM-производителями (часть Project Treble), поэтому ожидается, что он займет довольно много места. Хотя Google не рекомендует использовать A / B-разделение на устройствах объемом 4 ГБ (так как это почти 10% от общего объема доступного хранилища), они рекомендуют его на устройствах с 8 ГБ и выше.

Ниже приведена разбивка пространства памяти, используемого в Google Pixel, с разделами A/B и без них.

Что случилось с разделом восстановления?

Основополагающее ядро Linux на устройствах Android - это то, что позволяет Android правильно распознавать и использовать оборудование на смартфоне. На Android-устройствах A-only у вас обычно есть две версии ядра: одно упаковано внутри раздела восстановления, а другое - в загрузочном разделе. На устройствах A/B, поддерживающих бесшовные обновления, восстановление теперь находится внутри образа загрузки вместе с ядром. Главной функцией восстановления было установить обновления, но так как это обрабатывается самой системой (update_engine), когда Android загружен, выделенный раздел восстановления больше не нужен.

Интересный факт - Android update_engine, который обрабатывает бесшовные обновления, в основном взят прямо из Chrome OS. Только недавно строки, содержащие «Chrome OS», удалены из журнала update_engine, чтобы избежать путаницы для тех, кто случайно проверяет logcat.

Поддерживает ли мой Android-смартфон A / B-разделы для бесшовных обновлений?

Как бесшовные обновления влияют на пользовательскую разработку?

Восприятие пользователями разделов A/B

Хотя они и считаются препятствием для разработки пользовательского программного обеспечения многими пользователями, бесшовные обновления на самом деле являются благом для разработчиков. Причина, по которой устройства A/B воспринимаются как имеющие низкую поддержку развития, сводится к цене на первые устройства A/B. В конце концов, устройства Google Pixel были одними из первых, кто поддерживал бесшовные обновления и по сравнению с смартфонами Nexus прошлых лет они были относительно дорогими. Кроме того, благодаря множеству улучшений, которые Google делает для ОС Android, которая сделала пользовательские ROM и модификации менее популярными на устройствах Google, смартфоны Google Pixel не снимались на XDA, как и смартфоны Nexus. Сочетание внешних факторов привело к уменьшению пользовательской разработки на смартфонах Google Pixel, хотя большинство пользователей предпочло обвинять поддержку раздела A/B. Сравните доступность пользовательской разработки на таких устройствах, как Google Pixel, с такими устройствами, как Xiaomi Mi A1 на XDA.

Кроме того, отсутствие понимания того, как разделы A/B изменили способ, которым пользователи должны устанавливать пользовательские ROM, ядра и модификации, приводило к непопулярности поддержки раздела A/B. С восстановлением, которое теперь живет внутри загрузочного образа, изменения в неправильном порядке, такие как Magisk или Xposed, могут вызвать конфликты и могут привести к бутлупу. В каком порядке вы запустите эти моды, может быть важным, хотя в случае с обычными ROM вам не нужно беспокоиться о том, в каком слоте вы устанавливаете прошивку. Вам в основном не нужно беспокоиться об этом, так как вам не нужно вручную менять слоты.

Как разработчики видят разделы A/B?

При создании ROM разработчики могут использовать оба раздела для тестирования отдельных сборок. Если что-то не работает, они могут просто вернуться к рабочему разделу и перестроить их ROM. Разработчики также могут тестировать регрессии, просто устанавливая обновление, переключая активный раздел и сравнивая их без необходимости стирать данные. Вот как команда LineageOS просматривает поддержку раздела A/B:

Many around the Android community have bashed A/B as being ‘hard to support’ and ‘not developer friendly’, when in fact, properly implemented it is easier to support and just as developer friendly. - jrizzoli, LineageOS Changelog 19

Многие вокруг Android сообщества трактовали A/B как “трудно поддерживаемый” и “не осуществимый  для разработчиков”, хотя на самом деле, он также легко поддерживаемый как и для разработчиков.

Первоначальная трудность с поддержкой A/B для разработчиков объясняется изменением существующих инструментов для поддержки этих устройств. Разработчик Magisk, topjohnwu, добавил официальную поддержку Google Pixel через год после его выпуска - не потому что это было сложно, а скорее потому что ему потребовался год, чтобы фактически получить устройство для работы. Поддержка TWRP довольно быстро появилась на устройствах A/B после того, как ведущий разработчик Dees_Troy взломал его. LineageOS 15.1 теперь поддерживает устройства A/B после того, как добровольцы нашли время, чтобы исправить их скрипт addon.d

Слово о Project Treble и бесшовных обновлениях

Распространенным заблуждением является то, что поддержка Project Treble и поддержка раздела A/B связаны друг с другом, но на самом деле это не так. Иметь одно не означает другого. Motorola Moto Z2 Force использует схему разделения A/B, но не поддерживает Treble. С другой стороны, Honor 9 Lite поддерживает Project Treble, но является устройством A-only.

Перевод осуществлён каналом @android_core. Источник статьи - XDA

Если возникли вопросы - пишите в группу ВК, обсудить можно в чате, а что бы не пропустить новости подпишитесь на канал.