Загрузчик dsu что это

DSU Loader — что это и зачем нужно в смартфоне?

Принцип работы функции DSU Loader в режиме разработчика на телефоне.

Режим разработчика на смартфоне необходим для более детальных настроек мобильного телефона, но не все его функции понятны простому пользователю. Расскажем, что такое «DSU Loader», за что эта функция отвечает и нужно ли ее активировать.

Что такое DSU Loader в смартфоне?

Один из пунктов меню для разработчиков, который часто вызывает вопросы у пользователей, называется DSU Loader. Эта функция полноценно была введена в версии Android 11 и расшифровывается как «Dynamic System Updates» или «динамическое обновление системы». Задача этой функции — установить на смартфон системный образ новой ОС (GSI), который включает как саму операционную систему, так и настройки, конфигурации и все программы, установленные на нее.

Простыми словами, DSU Loader позволяет временно протестировать новую версию Android без полной перепрошивки устройства. При этом текущая версия ОС, а также фирменная оболочка производителя остаются нетронутыми и не подвергаются никакому риску. После того, как пользователь ознакомится со всеми функциями новой версии Android, он сможет так же легко вернуться к своей старой ОС — для этого понадобится всего лишь перезагрузить смартфон.

DSU Loader максимально упрощает процесс тестирования новой версии Android как для разработчиков приложений, так и для простых пользователей, которые хотят ознакомиться со свежей ОС и ее функциями, чтобы решить, стоит ли она полноценной установки. И если раньше для подобного теста требовалось использование команд ADB или Fastboot, то с появлением функции DSU Loader для установки необходимо всего несколько нажатий.

Как активировать DSU Loader на смартфоне?

Возможность установить и протестировать новую версию ОС появится, только если соблюдены несколько факторов:

Системный образ ОС должен быть подписан Google или производителем смартфона.
Функция DSU Loader должна быть добавлена в настройки смартфона производителем мобильного устройства.

Функция доступна на большинстве современных телефонов, а найти ее можно в режиме для разработчиков. Для этого его необходимо активировать, нажав на номер сборки устройства 5-7 раз — этот пункт находится в разделе «О телефоне».

Далее в основном меню настроек нужно найти пункт «Для разработчиков» (он может находиться в разделе «Дополнительные» или «Расширенные» настройки) и среди настроек найти строку DSU Loader. Теперь остается выбрать один из предложенных образов в зависимости от архитектуры устройства и установить его, следуя инструкции. Чтобы вернуться к исходной ОС, достаточно перезагрузить смартфон.

Android 13 улучшит DSU — установка общей системы GSI в два раза быстрее

Динамическое обновление системы (DSU) — одна из малоизвестных функций Android. Эта функция позволяет пользователям устанавливать общий образ системы (GSI) без разблокировки загрузчика или установки системных обновлений. Это упрощает переключение между текущим образом системы и GSI. Впервые представленная в Android 10, эта функция является одним из самых простых способов для разработчиков протестировать последнюю версию Android 13. Согласно информации от технического эксперта Мишаала Рахмана, DSU получит улучшения в Android 13.

Android 13 1024x470

Новый коммит от AOSP Gerrit предполагает, что Google вносит заметные улучшения производительности в DSU. Установка GSI через DSU выполняется намного быстрее за счет увеличения общей памяти по умолчанию . Google отмечает, что небольшое увеличение объема памяти (с 8 КБ до 64 КБ) значительно ускорит динамическую установку системы как на физических, так и на виртуальных устройствах.

Тесты Google показывают, что время установки на физическом устройстве сокращается с 2 минут и 2 секунд до 45 секунд. Кроме того, время установки на виртуальное устройство сокращается с 45 до 30 секунд.

Кроме того, индикатор выполнения также получил некоторые новые улучшения. Во время установки GSI индикатор выполнения в центре уведомлений будет показывать устанавливаемый раздел . В текущей версии Android 13 отображается только «Установка». DSU также добавит поддержку образов system, system_ext и продуктов. Эти функции и улучшения пока недоступны в Android 13 Developer Preview.

Android 13 будет изначально поддерживать открытие нескольких карт eSIM на одном чипе.

Традиционные мобильные телефоны используют физическую карту (SIM-карту) для подключения к сотовой сети. Тем не менее, цифровая карта eSIM не развивается быстро, отчасти потому, что она не полностью совместима с Android. Согласно новому отчету Esper, Google может внедрить eSIM в Android 13 , чтобы повысить популярность этой технологии. Эспер сообщает, что кодовая база Android 13 содержит патент, поданный Google в 2020 году, который позволяет использовать несколько профилей SIM-карт на одном встроенном чипе .

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

Интересные видео

Белоснежка в законе. Веселая сказка на пару минут

В городском королевстве проживала королева, известная своей красотой и жаждой подтверждения своего величия. Ее воле было подвластно волшебное зеркало, которое отвечало на ее вопросы. Но однажды зеркало объявило, что истинной красавицей королевства является не она, а приемная дочь Белоснежка.

DSU Loader для Android 11 позволяет разработчикам тестировать приложения на стоковой Android, как никогда ранее.

Хорошая экосистема приложений — одна из важнейших составляющих успеха операционной системы. И Google, и Apple осознают ценность наличия хороших приложений на своих платформах, поэтому обе компании пытаются сбалансировать потребности своих пользователей и разработчиков приложений. Пользователи продолжают настаивать на изменениях в ОС, и хотя большинство людей обычно ценят новые функции, эти изменения не всегда приносят удовольствие разработчикам приложений, поскольку они могут изменить многие основные функции и поведение. Для разработчиков, которые постоянно работают над поддержанием актуальности своих приложений, работа с этими изменениями дополняет их растущий рабочий список. Даже если эти изменения не влияют напрямую на их приложения, разработчикам все равно необходимо убедиться, что их приложения будут работать в новом обновлении ОС. За прошедшие годы Google внесла много изменений, чтобы упростить этот процесс для разработчиков приложений для Android, и теперь новая функция Android 11 под названием DSU Loader позволит разработчикам приложений еще проще тестировать свои приложения на новых версиях Android.

Она начинается с Проект высоких частот

Проект Treble, представленный в Android 8.0является основным реорганизация ОС Android, Цель Project Treble состояла в том, чтобы разделить ОС Android на две большие части: каркас и реализацию поставщика (здесь под «поставщиком» понимается производитель любого проприетарного аппаратного компонента, найденного в устройстве, обычно ссылающегося на кремний). Платформа Android OS — это сама операционная система, включая все системные приложения, пользовательский интерфейс и его компоненты, а также API-интерфейсы, которые являются общими для всех устройств Android. Реализация поставщика содержит HAL (уровни аппаратной абстракции) производителя, а также модули ядра Linux и ядра Linux.

Поскольку OEM-производители поставляют смартфоны с различными аппаратными компонентами от разных производителей, им приходится много работать, чтобы запустить оборудование в одной версии ОС Android. Затем с каждым новым обновлением ОС Android им приходится проделывать еще больше работы, чтобы убедиться, что их оборудование работает с новой версией. Но благодаря тому, что Project Treble стандартизирует ABI (двоичный интерфейс приложений) между платформой ОС Android и HAL для конкретной версии Android, OEM-производители Android могут начать тестирование обновлений на своих устройствах, не дожидаясь, пока производители кремния и другие производители компонентов обновят свои версии. код. Это изменение заметно ускорилось способ обработки обновлений Android.

В этом суть того, что Project Treble сделал для обновлений Android, но для разработчиков приложений здесь важнее то, что Treble позволил использовать общие системные образы (GSI) для тестирования совместимости.

Появление GSIs

Чтобы OEM-производители могли проверить, правильно ли они внедрили Project Treble, Google обязывает OEM-производителя загрузить на устройство чистую сборку Android из AOSP. Эта чистая сборка Android называется Generic System Image, или GSI. Если GSI загружается и большинство основных аппаратных средств функционируют должным образом, OEM-производитель знает, что его устройство соответствует требованиям Project Treble. Первоначальная цель GSI была, таким образом, для тестирования совместимости с Treble, но, как мы видели в сообществе разработчиков здесь, в XDA-Developers, они могут использоваться для других целей. Мы видели, как GSIs может по существу позволить устройствам с тяжелыми UX для Android пользоваться последней версией Android с работающими функциями в течение нескольких дней после выхода новой версии. Но Google предвидит еще одну цель, стоящую за GSI: дать разработчикам приложений возможность тестировать свои приложения на новой версии Android на физическом устройстве, которым они уже владеют.

С Android 10 Google выпустила собственные сборки GSI для разработчиков. Google поддержал идею о том, что разработчики приложений должны использовать GSI для загрузки чистой сборки Android на собственном оборудовании, чтобы упростить тестирование поведения их приложений со стандартным Android. Таким образом, этот метод добавляется к существующим вариантам тестирования совместимости приложений на стандартном Android без изменения поведения OEM, другие используют смартфон Pixel, официальный эмулятор Android в Android Studio или развертывают сборки приложений на экземпляре устройства в облаке.

Несмотря на все удобства, которые принесли GSI, их установка все еще была громоздкой. Разработчикам приложений может быть неудобно вручную мигать системный образ на устройстве Android, поскольку обычно это знакомы только любителям или разработчикам ОС Android. Установка GSI требовала перепрошивки образа системы поверх быстрая загрузка, что требует отключения Android Verified Boot и разблокировки загрузчика. Разблокировка загрузчика, в свою очередь, требует полной очистки данных пользователя. И, как мы все знаем, не существует единого процесса или руководства для разблокировки загрузчика каждого Android-устройства, поэтому нет последовательности, которую можно было бы найти. Например, устройства Samsung не имеют быстрой загрузки, в то время как устройства Xiaomi заставляют вас прыгать через несколько обручей, чтобы разблокировать загрузчик. Это удобный беспорядок, который может быть распутан во что-то более простое.

Это где динамические обновления системы входят.

Динамические обновления системы просто установка GSI

Google осознал, что текущий метод установки GSI не был идеальным решением, поэтому они начали работать над лучшим решением. В Android 10 Google начал тестировать динамические обновления системыили DSU. DSU — это новый способ временной установки GSI без необходимости использовать команды fastboot для прошивки образа системы, перезаписывая исходную установку. С помощью DSU вы можете загрузиться в GSI, протестировать свое приложение, а затем удобно перезагрузиться в исходную установку, которая осталась нетронутой.

Причина, по которой DSU может установить GSI, не затрагивая исходную установку, заключается в том, что он создает новые образы системы и разделов данных, которые временно сохраняются в / Данных / GSI, Эти образы затем монтируются во время загрузки, а не в исходную систему и разделы данных. Поскольку телефону требуется дополнительное место для хранения этих новых временных изображений, на вашем телефоне должны быть «логические разделы», которые представляют собой разделы с динамическим изменением размера. Логические разделы — это новая система разбиения пользовательских пространств для Android, которая является обязательной для устройств, запускаемых с Android 10. Если ваше устройство запущено с Android 10, то оно должно поддерживать установку GSI через DSU.

В Android 10 все, что вам нужно сделать, чтобы установить GSI через DSU изменить системное свойство, а затем запустить ДинамикСистемупдатесИнсталлатионСервис отправив намерение с путем к GSI в качестве дополнительного намерения.

Android 11 временно установлен на Pixel 3 XL без очистки Android 10 установить благодаря Dynamic System Updates (DSU). К сожалению, для загрузки требуется разблокированный загрузчик. pic.twitter.com/6TfUFD3ut9

— Мишааль Рахман (@MishaalRahman) 22 февраля 2020

Хотя этот процесс может показаться незнакомым, он гораздо проще и менее навязчив, по сравнению с использованием команд fastboot и работой со всеми проблемами, включая первоначальную установку. Вы требуете некоторых знаний Азиатский банк развития и намерен использовать DSU, но это не должно быть проблемой для большинства разработчиков приложений. Тем не менее, нет причин, по которым этот процесс нельзя было сделать еще проще. Кроме того, существует тот факт, что установка GSI через DSU все еще требует разблокировки загрузчика, стирая все пользовательские данные в процессе. С этой целью Google внес изменения, чтобы улучшить оба аспекта установки GSI. В Android 11 они избавили от необходимости использовать командную строку для установки GSI. Отдельно они также позволили установить GSI без разблокировки загрузчика.

DSU Loader в Android 11

DSU Loader — это новый инструмент в опциях разработчика Android 11, который позволяет загружать и установите последнюю версию GSI от Google без необходимости вводить какие-либо команды fastboot или ADB. Просто нажмите на опцию DSU Loader в настройках, и появится диалоговое окно со списком поддерживаемых GSI прямо из Google. Эти поддерживаемые GSI будут основаны на вашей текущей ОС и архитектуре, поэтому вы можете устанавливать только те GSI, которые новее, чем ваша версия ОС и которые соответствуют вашей архитектуре SoC. Просто выберите GSI, который вы хотите установить, и он будет загружен с серверов Google и автоматически установлен в фоновом режиме.

DSU Loader на Android 11

Благодаря DSU Loader разработчикам не нужно прикасаться к командной строке, чтобы установить GSI. По крайней мере, это мечта, потому что остается решить еще одну проблему.

Путь вперед

В настоящее время для установки GSI через DSU Loader необходим разблокированный загрузчик. Хотя это может нанести ущерб цели всего испытания, это не должно быть так, и нам говорят, что это будет исправлено. Google запланировал, что пользователи смогут загружать GSI, подписанные Google, через DSU без необходимости разблокировать загрузчик. На самом деле, Google обязывает это все устройства запуска Android 10 включают открытые ключи Android Verified Boot подписанных Google Android 10, Android 11 и Android 12 GSI. Включение открытых ключей AVB в виртуальный диск устройства гарантирует, что AVB не будет отклонять GSI, который вы пытаетесь загрузить. Вот почему текущий метод включает в себя разблокировку загрузчика — мигая пустым образом vbmeta в раздел vbmeta, вы отключаете AVB, чтобы он не отклонял GSI, который вы собираетесь прошить. Отключение AVB представляет собой серьезную угрозу безопасности, поскольку означает, что любой модифицированный раздел system / boot / product / vendor может быть загружен на устройство, поэтому Google хочет отменить это требование.

Требования к запуску Android 10 GSI

Итак, когда вы можете ожидать загрузки GSI через DSU без необходимости разблокировать загрузчик или использовать инструменты командной строки? Будем надеяться, что в скором времени Google упомянул нам, что у них есть несколько моментов, чтобы сгладить начальные превью для разработчиков Android 11, прежде чем они смогут заставить все это работать должным образом. В будущем можно ожидать установки будущих GSI Developer Preview через DSU без необходимости разблокировки загрузчика. Возможно, когда станут доступны предварительные версии для разработчиков Android 12, вы даже сможете полностью загрузить его, используя DSU Loader в опциях разработчика Android 11. Для разработчиков приложений это означает, что у вас будет еще один способ протестировать свои приложения на физическом оборудовании под управлением новой версии Android.

Динамические и модульные обновления Android

android

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

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 , который использовался для хранения файлов обновлений (теперь обновление скачивается напрямую в неактивный раздел).

Двойные разделы на смартфоне OnePlus 6

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

Раздел	Размер A/B	Размер A-only
Bootloader	50 Мбайт × 2	50 Мбайт
Boot	32 Мбайт × 2	32 Мбайт
Recovery	0	32 Мбайт
Cache	0	100 Мбайт
Radio	70 Мбайт × 2	70 Мбайт
Vendor	300 Мбайт × 2	300 Мбайт
System	2048 Мбайт × 2	4096 Мбайт
Всего	5000 Мбайт	4680 Мбайт

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

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

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

$ adb shell getprop ro . build . ab_update

Шпаргалка по управлению A/B-разделами с помощью fastboot

Узнать, какой слот (группа разделов) теперь активен:

$ fastboot getvar all | grep “ current — slot ”

Сделать неактивный в данный момент слот активным:

$ fastboot set_active other

Сделать активным указанный слот (a или b):

$ fastboot set_active СЛОТ

Прошить указанный раздел:

$ fastboot flash имя _ раздела _a partition . img
$ fastboot flash имя _ раздела _b partition . img

Динамические обновления

Project Treble открыл дорогу для еще одной весьма полезной функции — Dynamic System Updates (DSU). Этот механизм появился в Android 10 специально для пользователей и разработчиков, которые хотят протестировать новую (бета) версию Android, но не желают жертвовать для этого установленной системой и своими данными.

DSU базируется на технологии Dynamic Partitions, которая должна быть реализована во всех устройствах, выпущенных на рынок с Android 10. При использовании Dynamic Partitions в смартфоне, по сути, есть только один суперраздел, в котором система может создавать динамические разделы, удалять их и менять размеры (такое возможно благодаря модулю ядра Linux dm-linear).

Все системные разделы в таком смартфоне тоже динамические (кроме загрузочных разделов: boot, dtbo и vbmeta). Поэтому при необходимости система может сдвинуть их, чтобы освободить место для дополнительных разделов. Именно так делает функция DSU. Она уменьшает размер системных разделов, создает в освободившемся пространстве еще один набор системных разделов и устанавливает в него образ GSI. Далее смартфон перезагружается в эту свежеустановленную систему, а следующая перезагрузка выполняется вновь со стандартных разделов.

Чтобы установить образ GSI, используя DSU, для начала необходимо разблокировать загрузчик смартфона. Затем активировать DSU с помощью ADB:

$ adb shell setprop persist . sys . fflag . override . settings_dynamic_system true

Затем нужно скачать сам образ, распаковать и закинуть его на внутреннюю карту памяти смартфона:

$ gzip — c system_raw . img > system_raw . gz
$ adb push system_raw . gz / storage / emulated / 0 / Download /

Затем можно запустить установку:

$ adb shell am start — activity \
— n com . android . dynsystem / com . android . dynsystem . VerificationActivity \
— a android . os . image . action . START_INSTALL \
— d file : ///storage/emulated/0/Download/system_raw.gz \
— el KEY_SYSTEM_SIZE $ ( du — b system_raw . img | cut — f1 ) \
— el KEY_USERDATA_SIZE 8589934592

После окончания установки в шторке появится уведомление с предложением перезагрузиться.

Предложение перезагрузить смартфон после установки GSI

Сложно, не правда ли? Именно поэтому в Android 11 появилась функция под названием DSU Loader. Она позволяет автоматически загрузить и установить образ GSI в пару кликов.

В текущих сборках Android 11 DSU Loader требует разблокированный загрузчик. Однако к релизу стабильной версии Google планирует убрать это ограничение.

DSU Loader

Виртуальная A/B-разметка

Кроме возможности временной установки официальных сборок GSI, механизм DSU также позволил реализовать еще одну весьма интересную функцию — Virtual A/B.

Мы уже рассматривали преимущества новой A/B-разметки и то, какие проблемы она может решить. Однако ввиду потери пространства, которое может принести с собой A/B-разметка на устройствах с ограниченным объемом NAND-памяти, а также проблем с миграцией Google не спешит заставлять производителей смартфонов использовать новую разметку.

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

Виртуальная A/B-разметка будет обязательной для всех устройств, вышедших на рынок с Android 11.

Модульные обновления

Еще один шаг в решении проблемы с обновлениями — Project Mainline. Это внедренная в Android 10 подсистема, позволяющая обновлять куски Android в обход производителя устройства.

В центре новой подсистемы — пакетный менеджер APEX, очень похожий на тот, что используется в дистрибутивах Linux и новой операционке Google Fuchsia. Работает он примерно так: допустим, по очередному указу правительства в России вновь меняют часовые пояса. Команда разработчиков Android формирует новую версию пакета с часовыми поясами и выкладывает ее в Google Play. Пользователи получают обновление — все счастливы.

Содержимое пакета APEX

Таким же образом могут быть обновлены библиотеки и целые подсистемы. Уже сейчас в AOSP доступны пакеты с рантаймом ART («виртуальная машина», ответственная за запуск приложений), библиотека криптографических алгоритмов Conscrypt, набор мультимедийных кодеков, мультимедийный фреймворк, DNS-резолвер, интерфейс Documents UI, Permission Controller, ExtServices, данные часовых поясов, ANGLE (прослойка для трансляции вызовов OpenGL ES в OpenGL, Direct3D 9/11, Desktop GL и Vulkan) и Captive Portal Login. В теории в пакет APEX можно упаковать практически любой компонент системы, и пользователи смогут обновить его независимо от производителя смартфона.

Интересно, что APEX не производит обновление «на живую», когда старый компонент заменяется новым. Раздел / system в Android недоступен для записи, поэтому APEX использует трюк с монтированием. Все обновляемые файлы внутри пакета APEX находятся в образе файловой системы ext4. Когда пакет «устанавливается», система монтирует этот образ поверх раздела / system в режиме bind. В результате файлы пакета как бы заменяют оригинальные файлы Android, хотя в реальности все остается на своих местах.

Такой же трюк использует Magisk для установки модификаций Android без изменения раздела / system . И его автор уже сказал, что APEX станет проблемой для Magisk.

«Установка» пакета APEX

Трюк с сохранением пространства

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

В классическом варианте разметки системный раздел содержит в себе не только саму операционную систему, но и так называемые файлы odex. Они представляют собой оптимизированные (пропущенные через AOT-компилятор) версии dex-файлов, которые, в свою очередь, содержат код приложения.

Файлы odex позволяют сократить время старта приложения и повысить его производительность. Они могут быть созданы тремя путями:

преинсталлированы на устройство (в классическом варианте разметки — в раздел system);
сгенерированы динамически во время использования приложения или простоя устройства;
загружены из Google Play вместе с самим приложением.

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

Именно поэтому разработчики отказались от предустановки файлов odex в активный системный раздел, а вместо этого залили их в неактивный системный раздел вместо копии операционной системы. Так что жизненный цикл смартфона с A/B-разметкой выглядит так:

При выпуске с конвейера раздел system_a активный, содержит файлы операционной системы, раздел system_b неактивный, содержит файлы odex.
Во время первого запуска система копирует файлы odex в раздел userdata .
После получения первого OTA-обновления система записывает обновление в раздел system_b , далее запускает генерацию файлов odex (инструмент dex2oat) для новой версии ОС (они также записываются в userdata) и после ее завершения помечает раздел system_b (все разделы слота B) как активный.
После перезагрузки смартфон загружает операционную систему с раздела system_b , используя сгенерированные на третьем этапе файлы odex.

Выводы

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

APEX, с другой стороны, в теории может решить большинство проблем с обновлением смартфонов. Однако, в отличие от дистрибутивов Linux и ОС Fuchsia, пакеты APEX больше напоминают костыль, чем уместное инженерное решение. С другой стороны — лучше так, чем никак.