Project treble что это
Что такое Project Treble? Поддерживает ли мой смартфон Android данную технологию?
Одна из самых частых жалоб на Android заключается в очень сильной «фрагментации» платформы. На данный момент существует восемь различных версий мобильной операционной системы Android, которые до сих пор используются на устройствах с различным аппаратным оснащением.
Стандарты в индустрии устанавливает компания Apple. Если самой популярной системой Android остается выпущенная два года назад Android 7.x Nougat, то более 75% iOS уже работают на самой свежей iOS 11.
Давайте детально взглянем на статистику устройств Android от Google. 23,5% устройств работает на Android 6.x (Marshmallow), а 30,8% управляются Android 7.x (Nougat). Это означает, что более половины устройств Android работают на системах возрастом около 2 лет. Лишь на 12,1% устройств установлена последняя версия Android 8.x (Oreo). Если говорить откровенно, то более 85% устройств Android имеют устаревшее программное обеспечение и более 13% находятся под управлением пятилетней (или более старой) операционной системой.
Можно выделить две основные причины данной плачевной ситуации: политика производителей и цикл обновления Android.
Project Treble приходит на помощь
Производителям нужно проводить работу по оптимизации обновления операционной системы под конкретное оборудование. Данный процесс требует много времени и часто бывает просто нерентабелен.
Обычно срабатывал следующий сценарий: операционная система и низкоуровневое программное обеспечения были частью одного и того же кода. Поэтому, когда ОС получала обновление, низкоуровневый программный модуль тоже должен был обновиться с помощью собственной реализации производителя. Для этого требуется много ресурсов.
Начиная с Android 8.x (Oreo), Google решила разделить два этих процесса. Теперь операционная система Android сможет получать обновления без реализации производителя. Собственные модули производителя также могут обновляться при необходимости.
Таким образом, в Android 7.x и более ранних версиях Android обновлять нужно было не только операционную систему, но и низкоуровневый код для аппаратных модулей, обновления для последнего поступали от производителя чипов. Например, если компания Samsung хотела выпустить обновление для одного из своих смартфонов, она должна была подождать обновление от Qualcomm, которое бы заставило установленный чип работать с обновленным кодом Samsung. Данные зависимости усложняли и затягивали процесс обновления.
В Android 8.x и выше данная ситуация больше не повторится. Так как низкоуровневый код отделен от кода операционной системы, производители устройства могут обновить программное обеспечение, не дожидаясь обновления низкоуровневого кода от партнеров, поставляющих микросхемы.
Данное изменение должно существенно ускорить процесс обновления. Производитель устройства получает независимый контроль над обновлениями. Таким образом, Project Treble позволит существенно увеличить скорость разработки и развертывания обновления.
Поддерживает ли мое устройство Project Treble
Project Treble получат не все устройства. Предусмотрено несколько ограничений:
Вывод: поддержка Project Treble зависит от производителей, но новые устройства Oreo должны будут поддерживать данную технологию.
На сайте Android Police доступен список устройств, которые получат поддержку Project Treble, а также которые будут обновлены до Oreo без поддержки Treble.
Как проверить поддержку Project Treble на устройстве Android 8.0+
Примечание: для данного способа не требуются права root.
Заключение
Обновления Android становились предметом жалоб на протяжении многих лет. Приятно видеть, что Google решает данную проблему. Данное улучшение приведет к тому, что все устройства Android будут ближе к паритету с Apple с точки зрения обновлений устройств.
Что такое Project Treble и с чем его едят
В 2017 году, компания Google, вместе с выпуском операционной системы Android 8.0 Oreo показала новую технологию Project Treble, которая поможет производителям ускорить выпуск обновлений на свои устройства. Но, кроме этого, она также упростила энтузиастам процесс создания кастомных прошивок. О том, как работает данная технология и почему этого не было раньше я расскажу вам далее в материале.
В Android-смартфонах для меня всегда была лишь одна проблема — это долгие обновления
В Android-смартфонах для меня всегда была лишь одна проблема — это долгие обновления
Сначала немного о личном. Я пользуюсь Android-смартфонами начиная с 2011 года — у меня было множество бюджетных и среднебюджетных моделей. И все они имели общую проблему с обновлениями. Производители либо вовсе забивали на поддержку своих устройств, либо выпускали обновления с большой задержкой. Переход на флагманский Samsung Galaxy S8 эту проблему также не решил.
Компания Samsung, выпустила последнее обновление Android 9 Pie вместе с оболочкой One UI спустя практически полгода, с момента презентации операционной системы самой Google. Однако в «Корпорации Добра» эту проблему признают и предлагают методы борьбы с ней. Эти методы, кстати, по стандарту встроены во все версии операционной системы Android начиная с 8.0 Oreo. То есть, если вы приобрели девайс, и он из коробки работает на одной из последних версий операционной системы Android, могу вас лишь поздравить, проблема с программной поддержкой коснётся вас в меньшей степени, и вот почему.
Как работает Project Treble
Визуальное объяснение того, как теперь устроен Android «внутри»
Раньше, каждая версия операционной системы имела разный набор команд и фреймворков, из-за чего производителям смартфонов, а также мобильных чипсетов было необходимо переписывать весь свой софт практически с нуля. Google подошли к решению этой проблемы следующим образом: отныне Android, по своей сути, состоит из двух программных уровней, которые никак не зависят друг от друга. То есть, обновлением самого Android на устройствах с поддержкой Project Treble будет заниматься сама Google, а задача по обновлению фирменных программных надстроек ложиться на плечи производителя. В дальнейшей перспективе это может вовсе искоренить проблему задержки при выпуске обновлений Android для всех устройств.
Как я уже сказал выше, реализация Project Treble в системе упростила написание прошивок не только для производителей, но и энтузиастов, которые занимаются созданием модифицированных сборок Android. Таким образом, к примеру, для смартфонов бюджетного и среднебюджетного сегмента уже сейчас существуют полноценные сборки свежеиспеченного Android Q. Я, к примеру, установил такую на свой Ulefon Armor 6, использующийся мной для тестов, и могу сказать, что прошивка работает вполне стабильно. Примечательно, что это не специальная сборка под мой аппарат, она доступна всем владельцам смартфонов с поддержкой технологии Project Treble. К слову, ранее мы уже писали про то, как отразился ввод Project Treble в Android на скорости выхода обновлений.
Как узнать, поддерживает ли мой смартфон Project Treble?
Мой смартфон имеет поддержку Project Treble с типом обновления «А»
Узнать, поддерживает ли её ваш смартфон крайне просто. Для этого есть бесплатное приложение Treble Check, доступное в Google Play. Софт не только даст вам информацию о том, поддерживает ли ваш девайс технологию, о которой мы говорим, но и какой тип обновления системы предусмотрен производителем. Это важный момент, так как если ваш смартфон имеет схему обновления «A», то в таком случае вам не подойдут прошивки от схемы «A/B» и наоборот. На профильных форумах этой теме и подборкам прошивок посвящены целые разделы.
Разница между прошивками «A» и «A/B» кроется в типе обновления. В случае с «А» прошивка вносит изменения только на уровне операционной системы Android, все остальное — графическая оболочка и прочие программные надстройки от производителя остаются нетронутыми. А прошивки с методом обновления «A/B» вносят изменения на обоих уровнях. Примечательно, что есть смартфоны, которые поддерживают исключительно первый, либо второй вариант. Изменить данное свойство, к сожалению, не представляется возможным.
У вас также мог возникнуть резонный вопрос, насчет того, почему я пишу этот материал в 2019 году, ведь технологии уже целых два года. Согласно последней официальной статистике, опубликованной Google в мае 2019 года процент устройств, работающих на версиях Android 8 Oreo и Android 9 Pie, в которых и реализована поддержка пресловутой технологии Project Treble, достиг 37%.
И на данный момент она становится все более и более массовой, а значит материал может быть полезен для довольно большого числа людей, интересующихся прошивками и дальнейшей судьбой своих устройств. Будем вместе надеяться на то, что Google будет держать планку и со временем делать свою операционную систему все лучше и лучше, вводя действительно полезные нововведения.
Обсудить будущее операционной системы Android и не только вы можете вместе с участниками нашего лампового чата в Telegram.
Project treble что это
Начнем с общих вопросов:
Q: Ну и кто все это придумал? Проклятые производители простым гикам жизнь усложняют?
A: Новая структура «A/B разделов» разработана непосредственно Google-ом как часть глобальных изменений в архитектуре Android. Она успешно используется в смартфонах Google Pixel, Essential Phone и различных других устройствах. В дальнейшем все больше устройств от сторонних производителей будут ее использовать. Ничего плохого и страшного в этом нет, наоборот, открывается много новых возможностей.
Таблица разделов на примере Google Pixel:
Дабы наглядно отобразить, изложенную выше, теорию и увидеть отличия по сравнению с другими устройствами — познакомимся с таблицей разделов Google Pixel.
Если вы вообще не знакомы со структурой разделов в Linux-подобных системах, и Android в частности, — советую поискать информацию об этом в Google, благо ее полно.
Нас интересуют конкретные разделы, существующие в двух копиях для наглядности и демонстрации.
Итак (раскрываем код полностью):
/dev/block/bootdevice/by-name/aboot_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/apdp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/bootlocker_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib32_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/cmnlib64_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/devcfg_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hosd_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/hyp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/keymaster_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/msadp_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/pmic_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/rpm_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/tz_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/xbl_a # Разделы первого загрузчика (Слот «a»)
/dev/block/bootdevice/by-name/aboot_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/apdp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/bootlocker_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib32_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/cmnlib64_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/devcfg_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hosd_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/hyp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/keymaster_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/msadp_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/pmic_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/rpm_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/tz_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/xbl_b # Разделы второго загрузчика (Слот «b»)
/dev/block/bootdevice/by-name/modem_a # Раздел первого модема/радиомодуля (Слот «a»)
/dev/block/bootdevice/by-name/modem_b # Раздел второго модема/радиомодуля (Слот «b»)
/dev/block/bootdevice/by-name/boot_a # Раздел первого ядра (Слот «a»)
/dev/block/bootdevice/by-name/boot_b # Раздел второго ядра (Слот «b»)
/dev/block/bootdevice/by-name/vendor_a # Первый проприетарный раздел (Слот «a»)
/dev/block/bootdevice/by-name/vendor_b # Второй проприетарный раздел (Слот «b»)
/dev/block/bootdevice/by-name/system_a # Первый системный раздел (Слот «a»)
/dev/block/bootdevice/by-name/system_b # Второй системный раздел (Слот «b»)
Как видно из выдержки выше, — имеются два, независимых между собой, слота, а именно «группы разделов», которые содержат в себе основные, обновляемые компоненты прошивки.
Два представленных слота состоят из:
Bootloader (загрузчик) — 28 разделов (14 на каждый слот).
Radio/Modem (радиомодуль) — 2 раздела (по одному на слот).
Boot (ядро) — 2 раздела (по одному на слот).
Vendor (драйверы) — 2 раздела (по одному на слот).
System (система) — 2 раздела (по одному на слот).
Остальные разделы, не указанные в таблице, представлены в одном экземпляре за ненадобностью их деления.
Обратите внимание раздел пользовательского хранилища (userdata) всегда один! Именно поэтому вы не можете (без очистки хранилища) одновременно использовать две абсолютно разных прошивки, будет конфликт. Возможно одновременное использование одинаковых по типу прошивок (а в некоторых случаях и это невозможно без сброса данных).
Принципиальные отличия по сравнению с другими устройствами:
С дублированием разделов и, структурой в целом, разобрались. Однако, вы могли заметить (если просматривали полную таблицу разделов) отсутствие, привычных в любом устройстве, разделов «/recovery» и «/cache». Да, их действительно нет. Но могут и встречаться в отклонениях от нормы.
Q: Стоп. Но если раздела для Recovery нет, а сам Recovery есть (Он ведь есть, правда?), где же он находится?
A: Система восстановления (Recovery) включена в состав образа ядра (boot). А потому, наличие, отсутствие и тип установленного recovery напрямую зависят от ядра системы. Переключение в него (Recovery), как и раньше, осуществляется специальным флагом в «/misc» разделе.
Именно в этом и состоит загвоздка установки TWRP — его как-то нужно «засунуть» в ядро. Потому TWRP сначала временно загружают (устанавливать то его некуда), а затем уже из TWRP, специальным скриптом, на лету распаковывается ядро и вшивается в него TWRP. Такая же схема «перепаковки ядра на лету» применяется при получении «systemless» рут-прав через SuperSU и Magisk.
Q: Хорошо, а что же тогда случилось с «/cache» разделом?
A: В привычных устройствах он необходим лишь для хранения OTA обновлений и системных логов Recovery, в данном же случае, ввиду применения новой схемы этих самых обновлений (см. ниже), раздел стал попросту «не нужОн». Вот от него и избавились.
Ручное переключение слотов:
Естественно, помимо самих слотов, должен быть способ ручного взаимодействия с ними. И он есть. Для ручного переключения текущего активного слота необходимо воспользоваться утилитой fastboot. Команды:
Итоги и положения:
1. Между слотами как система, так и сам пользователь могут переключаться.
2. Изначально (с завода) слоты полностью идентичны между собой. Различия появляются после применения любого OTA обновления системы.
3. Слоты изолированы между собой. Состояние и целостность одного слота никак не влияет на другой. За исключением применения OTA обновлений (см. ниже).
«Seamless» система обновлений:
Итак, с разделами и слотами разобрались. Но что же там с обновлениями, наверняка их тоже коснулись изменения, ввиду описанного выше?
Да, OTA обновления на устройствах с A/B структурой кардинально отличаются от того, что мы можем видеть на других устройствах.
Android 8.0+ — трансляция обновлений:
Начиная с версии Android 8.0 возможна (но не обязательна) частичная реализация трансляции обновлений с одновременным их применением (прямая запись).
Это значит, что обновления не нуждаются в предварительной их загрузке, а применяются «на лету».
Долгая дорога к быстрым обновлениям Android
Поскольку это моя первая публикация на Хабр, давайте для начала представлюсь: меня зовут Федор, я из Нижнего Новгорода и работаю в компании Orion Innovation техническим менеджером/СТО. На практике это означает, что я отвечаю за направление Android Platform – написание прошивок для разных устройств под Android. Если вы, вдруг, меня знаете, то, скорее всего, по моим выступлениям на Mobius и других конференциях. А данная статья – это обобщение пары моих докладов, сдобренное разными деталями, ссылками и отступлениями от темы, на которые в рамках доклада обычно не хватает времени. С представлением закончили, дальше статья.
Для создания конфликта в каждом повествовании должен быть свой злодей. В моей истории злодей – Фрагментация Android. Как благородный рыцарь, Google сражается с нашим злодеем в ожесточенной схватке с самого начала существования операционной системы. В этой борьбе были победы и поражения, менялись тактики и приемы, но счастливый финал по-прежнему остается вне досягаемости.
Проблема фрагментации
Пожалуй, начать стоит со статистики, знакомой каждому Android-разработчику:
Из этой картинки видно, как много людей все еще используют телефоны со старыми версиями Android – почти все. Значит и разработчикам приходится ориентироваться на эти старые версии в своих приложениях. И порою это означает отказ от многих преимуществ последней версии Android.
Google, конечно же, в курсе данной проблемы. Разработчикам Google самим вряд ли нравится то, что большинство пользователей Android не могут оценить все новинки операционной системы. Но недовольство разработчиков – это лишь верхушка айсберга.
Что хуже, многие телефоны не получают последних обновлений безопасности из-за данной проблемы. А значит, они уязвимы, что позволяет единственному конкуренту Google на мобильном рынке напирать на безопасность личных данных пользователей в своих рекламных кампаниях. Да, у iOS нет проблемы фрагментации – большинство пользователей iPhone регулярно обновляются на последнюю версию. Для Google это, вероятно, обиднее всего.
Обновления операционной системы
Так почему у Apple все отлично, а Google бьется годами и не может победить фрагментацию? Ответ в том, как работают обновления. Все-таки большинство людей не меняют телефон на новый каждый год. И с обновлениями у iOS все намного лучше. Причина тому в самом фундаментальном отличии двух систем: Apple делает и софт, и железо, а Google – только софт. Давайте объясню, как оно работает.
Что нужно сделать Apple, чтобы обновить прошивку на iPhone? Создать обновление и прислать его на устройства. Пользователю лишь остается принять эти обновления и наслаждаться последним iOS на телефоне.
Обновления в iOS
Что если Google хочет обновить Android? Вот картинка от Google, описывающая данный процесс:
Обновления в Android
Разницу заметить не сложно: процесс обновления прошивки Android-устройства гораздо сложнее, так как в него вовлечено больше сторон. iOS – это закрытая система, которая полностью контролируется одной компанией и сфокусирована на поддержке одной аппаратной платформы – iPhone. С Android все иначе. Это проект с открытым кодом и поддержкой железа от многих производителей. В результате, производители чипов и телефонов так или иначе вовлечены и в процесс обновления прошивки.
Такая открытость – одна из сильных сторон Android. Она создает конкуренцию, способствует инновациям, позволяет Android эволюционировать намного быстрее. Но увы, за это разнообразие приходится платить, и усложнение процесса обновлений – часть этой цены.
Android Update Alliance
Первые попытки
Google понимал, что проблема обновлений в необходимости кооперации между разными компаниями. В первую очередь, они решили наладить эту кооперацию административным путем. Первая попытка случилась в 2011 году и называлась «Android Update Alliance». По сути, это было торжественное обещание основных производителей Android-смартфонов и сотовых операторов выпускать своевременные обновления.
Увы, оказалось, что производителям телефонов интереснее выпускать и продавать новые устройства, а не обновлять старые. В результате Android Update Alliance умер не прожив и года. Мораль данной истории: в большом бизнесе соображения выгоды всегда возобладают над торжественными обещаниями.
Новая идея заключалась в том, что проблема может быть решена не административным, а инженерным путем. Сделать процесс обновлений и кооперации гораздо проще технически. Первый шаг был сделан в 2017 году. Он назывался Project Treble.
Project Treble
Project Treble вышел вместе с восьмым Android. И, на мой взгляд, он вполне может бороться за звание самого масштабного рефакторинга в истории. Google сумел полностью переписать половину основных компонентов операционной системы и поменять архитектуру, сделав её более модульной. Самое удивительное – никто даже не заметил изменений. Все, что работало до этого, продолжило работать как раньше.
В рамках данной статьи мы не будем вдаваться в детали Project Treble. Эта тема заслуживает отдельной публикации или даже книги. Если вам интересно, на YouTube есть запись моего выступления на Mobius по данной теме.
Вкратце: цель Project Treble в том, чтобы убрать производителей чипов из процесса обновлений. И хотя это звучит не так страшно, усилия Google были огромными. В разных интервью сотрудники Google говорили о том, что 300 человек были вовлечены в проект в течение года, чтобы воплотить в жизнь необходимые перемены:
«Vendor» здесь – это производитель чипов (например, Qualcomm). И хотя иллюстрация выше излишне все упрощает, из нее можно понять основную идею: Project Treble поделил код Android на Framework (верхнеуровневые сервисы и приложения) и Vendor Part (нижний уровень драйверов и HALов). Производитель чипов в новой модели отвечал за нижнюю часть, в то время как Google и производители устройств могли сконцентрироваться на верхней.
Две части системы были разделены Vendor интерфейсом. Он был стандартизирован Google, имел четкую систему версий и был обратно совместим. Все это позволяло выпускать обновления для обеих частей почти независимо друг от друга, а значит делало процесс обновлений проще и быстрее.
С технической точки зрения проект внушал только уважение. Но решил ли он свою бизнес задачу? Стали ли обновления проще и быстрее? В качестве ответа на этот вопрос Google опубликовал график скорости обновлений через 2 года после выхода Project Treble:
Из него видно, что обновления на Android 9 шли вдвое быстрее обновлений на Android 8. Во многом это заслуга Treble. Также видно, что Treble начал работать только с 9-ки, хотя и вышел с Android 8. Дело в том, что Treble упростил процесс обновления с 8-ки, но процесс обновления на 8-ку проще не стал. Вот такая же статистика перехода на Android 10:
Как видите, с Android 10 все даже лучше: 400 миллионов пользователей на 10-й версии меньше чем за год. Так что же, проблема решена, злодей повержен? Увы, даже из этих графиков можно понять, что проблема далека от решения. Достаточно лишь посмотреть на них внимательнее:
1. Графики показывают глобальные объемы, но не показывают проценты. И они включают в себя как старые телефоны, получившие Android 10 через обновления, так и новые устройства, изначально выпущенные с Android 10. То есть бОльшие цифры могут отражать большое количество новых телефонов. И это на самом деле так – сегодня в мире 2,5 миллиарда активных пользователей Android. И это число увеличивается на 1,5 миллиона ежедневно.
2. Рост на всех графиках начинается где-то спустя 100 дней после релиза новой версии Android. И даже спустя год, рост не замедляется. Это означает, что большинство людей еще не получили обновление прошивки.
3. iOS на километр впереди: если построить подобный график для последней версии iOS, заменить общие объемы на проценты, то мы увидим, что скорость обновления iOS раз в 10 выше.
В целом, можно сказать, что Project Treble сделал обновления лучше, но не решил проблему полностью. Но это был явно шаг в верном направлении, и Google решил шагать дальше. В 2019 вышел Android 10, а вместе с ним – Project Mainline.
Project Mainline
Суть Project Treble была в разбивке монолитной системы на несколько частей. Это позволило разделить код Android на области ответственности между производителями чипов и производителями устройств. Project Mainline стал продолжением и углублением данного подхода – модульность 2.0. Если Treble делил систему на две части, Mainline выделил уже с десяток модулей. Новая архитектура выглядела примерно так:
Теперь в Android появилось новое понятие – «модульный системный компонент» или просто «модуль». Им может стать любой компонент системы: приложение, сервис, библиотека. Главная изюминка модулей в том, что Google может обновлять их напрямую через Google Play. Ни производители чипов, ни вендоры устройств не участвуют в этом процессе – Google присылает обновления пользователям напрямую.
Какие же компоненты системы Google решил обновлять таким образом? В Android 10 все модули поделили на 3 категории по той роли, которую они должны были играть. Вот еще одна картинка от Google, описывающая эти три корзины:
Security – самая понятная категория. Любую уязвимость, связанную с безопасностью, Google хочет закрыть ASAP. Поэтому они выбрали несколько мест в системе, наиболее тесно связанных с безопасностью, и превратили их в модули.
Privacy – категория, которая не так сильно отличается от Security по смыслу. Она должна помочь с защитой пользовательских данных и приватностью, а это в некотором роде часть Security. Возможно, свою роль тут сыграли уже соображения маркетинга и желание подчеркнуть слово Privacy в пресс-релизах. По сути, можно сказать, что Privacy модули это те же Security, но напрямую связанные с permissions.
Consistency – самая интересная категория, на мой взгляд. Во-первых, не сразу понятно, как именно «стабильность, совместимость и последовательность» связаны с модульными обновлениями. Это безусловно достойные цели, но скорость обновлений системы не всегда с этим связана. Во-вторых, большинство модулей попадают именно в эту, наименее очевидную категорию. Включая самый большой и интересный модуль – Android Runtime.
Android Runtime (ART)
Что такое Consistency
Android Runtime заслуживает отдельного упоминания. Для начала, в Android 11 он обновляется только вместе со всей системой (по слухам, в Android 12 Runtime может стать независимо обновляемым). То есть это как бы независимый модуль, но при этом он не получает независимых обновлений. Логичный вопрос: зачем же он тогда нужен? Однозначного ответа у меня нет, но я могу предложить несколько версий.
Первая версия: Google, возможно, хотел бы обновлять Runtime отдельно, но он несет в себе львиную долю самого «ядерного» функционала Android. Этот модуль включает ART – виртуальную машину, внутри которой существует любое Android-приложение. И это лишь один из примеров того, что внутри Runtime модуля много других вещей, сравнимых по важности. Можно сказать, что без Runtime модуля ничего в Android работать не будет. И, видимо, отделить Runtime от «немодульного» Android оказалось пока невозможно.
Вторая версия: перемещение некоторого функционала в модуль может быть полезным, даже если этот модуль невозможно обновлять отдельно. И польза эта как раз в Developer Consistency. Если производители устройств не могут менять код внутри модуля, это означает, что на всех устройствах он будет работать одинаково. Для разработчиков приложений это хорошая новость. Большинство новых модулей в Android 11 следуют этой логике, добавляя новые API через модули, чтобы они работали одинаково на всех устройствах и прошивках.
На данный вопрос можно посмотреть и под иным углом. Модули могут быть использованы Google как довольно сильный инструмент контроля производителей телефонов. Все-таки у новой модельной архитектуры можно выделить два ключевых последствия:
Google может обновлять модули напрямую, не спрашивая согласия вендоров;
вендоры не имеют права трогать код внутри модулей.
И если первое следствие наверняка является основной причиной появления Project Mainline, второе тоже не стоит сбрасывать со счетов. И Runtime, вполне вероятно, существует именно для достижения второй цели. Помещая «ядерный» функционал в отдельный модуль, Google гарантирует единообразие работы этого функционала на всех телефонах. На мой взгляд, именно так и стоит перевести «consistency» – единообразие.
Как косвенное подтверждение такого мотива Google, можно привести следующий факт: хотя Mainline и позволяет Google быстро обновлять модули, общие обновления системы быстрее от этого почти не стали, так как они все еще приходят от вендоров телефонов.
То есть Project Mainline не был задуман для того, чтобы сделать обновления системы быстрее. И он не поможет уменьшить фрагментацию. Его задача – снизить негативные эффекты фрагментации, вынеся часть системы «за скобки». И пусть обновления не станут при этом быстрее, но это будет уже не так критично.
В этом суть Project Mainline – это технический вариант решения текущей проблемы. Google наконец-то понял, что не сможет заставить производителей телефонов обновлять их чаще и поддерживать дольше. Вместо этого Google просто лишил их контроля над самыми важными и критичными кусками Android и теперь будет обновлять их напрямую. И есть у меня подозрение, что конечные пользователи от этого только выиграют.
Выводы
На этом моя статья подходит к концу, но борьба Google с фрагментацией, вероятно, продолжится. Уже сейчас можно сказать, что Android претерпел на этом пути кардинальные изменения, которые не ограничиваются одними лишь обновлениями. Google перекроил всю архитектуру системы, сделал ее модульной, установив границы и зоны ответственности. Да, в результате обновления стали быстрее, а фрагментация менее критичной, но в целом это выглядит как лишь один из эффектов лучшей архитектуры.
На сегодняшний день Android так и не удалось полностью справиться с проблемой фрагментации и сравняться со своим основным конкурентом. Это связно с тем, что Android, в отличие от iOS, – продукт совместной работы многих компаний, и за это придется платить. А значит борьба продолжится, и мы можем ждать дальнейших решений Google по оптимизации архитектуры своей ОС.
Несмотря на это, на решение проблемы было брошено много усилий, и можно ожидать, что проблема фрагментации будет становиться все менее критичной. Project Mainline должен с этим помочь. В конце концов, так ли важно будет пользователям, какая версия Android крутится на их телефонах, если их личные данные в безопасности и все приложения работают должным образом?