Русский
Русский
English
Статистика
Реклама

Ota

Перевод Как обстоят дела с обновлениями софта по воздуху (ОТА)

16.12.2020 20:13:35 | Автор: admin
image


Важность ПО в автомобильной промышленности росла на протяжении 10 последних лет (и продолжает расти), а потому автопроизводителям приходиться полагаться на использование беспроводных обновлений (ОТА).

ПО, используемое в автомобилестроении, имеет множество уникальных особенностей как хороших, так и плохих.

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

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

В таблице, приведенной ниже, показаны основные преимущества ОТА-обновлений для автомобильной промышленности. Далее мы рассмотрим пользу ОТА-обновлений для разных компаний и потребителей.

Для поставщиков ПО OTA-обновления, очевидно, являются дополнительной возможностью для получения дохода. Доход разделяется на несколько частей: плата за адаптацию ПО к конкретным моделям автомобилей, роялти за каждый автомобиль с установленным ПО, плата за поддержку и ОТА-обновления, а также плата за кибербезопасность и аналитику. Поставщики ПО, обновляемого по воздуху, могут поставлять свои продукты через Tier-1 поставщиков (либо Tier-1 поставщики могут сами заниматься OTA-обновлениями).

image

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

Ценность для автовладельцев экономия средств и времени за счет того, что исчезнет необходимость ездить к дилерам для обновления ПО. Также более быстрые исправления ПО могут быть важны в тех случаях, когда речь идет о безопасности.

Наконец, ОТА-обновления будут полезны для общества в целом. В настоящее время обновления ПО, распространяемые через дилерские салоны устанавливаются на 70% автомобилей. Это значит, что по дорогам ездят миллионы потенциально опасных автомобилей, у которых не установлены требуемые обновления ПО. Ожидается, что у ОТА-обновлений цифры будут лучше вероятно, выше 95%.

OTA-обновления сейчас на пике роста (и будут продолжать расти следующие 5 лет). У IHS Markit есть база данных, по которой можно отследить поддержку ОТА-обновлений у разных OEM-производителей и среди их моделей. По данным IHS Markit видно, что 30% автомобилей, проданных в 2020 году, будут поддерживать OTA-обновления. К 2025 году поддержка вырастет до 79% среди всех продаваемых в мире автомобилей.

В следующей таблице представлен обзор всех ключевых игроков на рынке OTA-обновлений и краткие описания компаний их стратегий. Примечательно, что многие OTA-компании были куплены более крупными игроками. Вероятно, подобные сделки будут заключаться и в будущем.

image

Harman


Harman явный лидер. В 2015 Harman купила компанию Redbend, которая была лидером области OTA-обновлений для смартфонов и занимала прочные позиции в автомобильном сегменте. В 2015 году Harman приобрела и Symphony Teleca, компанию с мощной облачной инфраструктурой. Harman использует все эти ресурсы для обслуживания OTA-клиентов и облачных SaaS-платформ. Лидерство Harman в области OTA-обновлений настолько значительно, что другим участникам приходится искать альтернативные стратегии для того, чтобы иметь возможность конкурировать.

QNX-BlackBerry


QNX ведущий поставщик автомобильных ОС, и у компаний, которые пользуются QNX OS есть возможности для обновления программных платформ по воздуху. У BlackBerry же есть платформа для интернета вещей, в которой успешно развернута OTA-инфраструктура, и она успешно используются в автомобильной индустрии. QNX занимает лидирующие позиции на рынке автомобильных ОС, работающих в реальном времени. Рейтинги безопасности их продуктов позволяют использовать их во всех автомобильных блоках управления.

Wind River


Wind River вышла на OTA-рынок после приобретения Arynga (дочерней компании Intel). Arynga была стартапом с большим опытом работы с OTA в телекоммуникациях. Технология Arynga OTA поддерживает горячую замену ПО может обновляться без отключения ОС. OTA-платформа от Wind River называется Edge Sync.

Wind River поставщик различных ОС для автомобильной промышленности (таких как VxWorks, Wind River Linux, AUTOSAR Adaptive и платформы для визуализации под названием Helix).

Airbiquity


Компания Airbiquity специализируется на сетевых сервисах для автомобильной промышленности. В частности, можно отметить их платформу для обновления ПО и управления его жизненным циклом под названием OTAmatic. OTAmatic это OTA-решение с поддержкой нескольких блоков управления для управления данными, заточенное для использования в автомобильной промышленности. Платформа OTAmatic может использоваться на мощностях Microsoft Azure или AWS, либо она может быть установлена на сервера автопроизводителей.

Toyota и Denso инвестировали в Airbiquity 15 миллионов долларов в 2019 году, и компании будут сотрудничать в областях OTA и управления ПО. Wind River и Airbiquity объявили, что они будут сотрудничать для создания открытого и гибкого OTA-решения для автомобильной промышленности.

Excelfore


Excelfore разработчик платформы для обновления ПО под названием eSync OTA Pipeline. Эта OTA-платформа используется для обновления разнообразных устройств, но в целом ориентирована на автомобильную промышленность. Пользователи платформы eSync могут работать с данными для диагностики или управления/анализа автопарка. eSync OTA Pipeline доступна через Microsoft Azure.

Excelfore объявила о сотрудничестве с eSync Alliance для реализации совместимости различных устройств с поддержкой OTA. В настоящее время eSync Alliance состоит из 11 компаний, включая Alps / Alpine, DSA, Excelfore, Faurecia, Hella, Mobica, Molex и ZF.

Многие автопроизводители и Tier-1 поставщики используют платформу eSync OTA. Поставщики информационно-развлекательных систем также используют продукты eSync для интеграции OTA-обновлений.

Aurora Labs


Aurora Labs это программный OTA-стартап, который был основан в 2016 году и в настоящее время получил инвестиции от венчурного фонда в размере 34 миллионов долларов. Aurora Labs является разработчиком нескольких инновационных технологий, и у компании есть целое портфолио с различными патентами. Aurora Labs позиционирует свой продукт как самовосстанавливающееся программное решение, которое может обеспечить будущее автомобилей с сетевым подключением.

Технология Line-of-Code Behavior от Aurora Lab закладывает основу для OTA-решений и позволяет управлять ПО. Технология основана на алгоритмах машинного обучения, которые охватывают все этапа создания ПО от непосредственной разработки до использования в автомобиле. Эта технология может использоваться не только посредством OTA, и она позволяет писать более надежный код с меньшим количеством ошибок.

По сути, функциональность продуктов от Aurora Lab интегрируется на этапе разработки. что значительно упрощает и делает более рентабельным управление OTA-обновлениями на протяжении всего 15-летнего этапа использования ПО. Эта стратегия заметно отличается от подходов других OTA-компаний, которые предоставляют послепродажные решения для обновления ПО их OTA-решения интегрируются уже после разработки программного продукта.

Недостаток Aurora Lab заключается в том, что развертывание их OTA-решения занимает много времени, поскольку их технология Line-of-Code Behavior должна использоваться во время разработки программных платформ Tier-1 или OEM производителями. Вероятно, преждем чем Aurora Lab начнет разворачивать свои продукты на дорогах, пройдет еще 3-5 лет. Долгосрочные же преимущества для работоспособности автомобильного ПО выглядят многообещающе.

Sibros


Sibros это OTA-стартап, который был основан в 2018 году и в настоящий момент получил инвестиции от венчурного фонда в размере 15 миллионов долларов. Основатели компании имеют опыт работы в Tesla и Uber. Платформа Deep Connectivity Platform позволяет полностью обновлять все автомобильное ПО и собирать с него данные.

В транспортные программные платформы входят такие продукты как Deep Updater, Deep Logger, Armor cybersecurity и собственный загрузчик. Эти продукты представляют собой строительные блоки, из которых можно собирать программные решения для подключенных автомобилей. Также в Deep Connectivity Platform входят облачные сервисы для взаимодействия с облачными сервисами Sibros и ее клиентов.

Платформа от Sibros многофункциональна, хотя основная ее функция OTA-обновления. В других приложениях также имеется функционал для удаленной диагностики, прогнозирования, управления автопарком и аналитики. Платформа также может предоставлять данные для страхования на основе использования (UBI), умных парковок и прочих приложений для сетевых автомобилей. У Sibros уже есть несколько клиентов в разных странах, компания поставляет свои продукты с июля 2019 года.

У Sibros есть инновационная стратегия, которая подразумевает работу с платформой для сетевых автомобилей, способной охватывать различные сегменты связи (и OTA только один из них).

Tier-1 поставщики


Некоторые Tier-1 поставщики предоставляют функциональность OTA-обновлений через телематические системы и/или платформы интернета вещей. Многие Tier-1 поставщики также используют OTA-решения от компаний, перечисленных выше.

Aptiv приобрела Movimento в 2017 году (тогда она была частью Delphi). У Movimento есть большой опыт в программировании ECU через Wi-Fi устройства, подключенные к OBDII. Технологии Movimento использовали многие OEM и Tier-1 производители. Сейчас их решения интегрированы в платформу Aptiv Connect.

OTA-обновления от Bosch работают через платформу IoT Suite. Также OTA-функционал включен в платформу Bosch IoT Rollouts. IoT Suite доступна через AWS.

Continental поставляет OTA-обновления через собственную телематические системы. У Continental есть соглашение с Inmarsat компанией, которая является лидером в области глобальной спутниковой связи и может предоставлять решения для распространения OTA-обновлений.

Компания Lear также использует собственные телематические системы для установки OTA-обновлений. Lear приобрела права на интеллектуальную собственность и наняла ключевых сотрудников из Autonet Mobile в 2015 году. Lear объявила о запуске собственных решения в своих продуктах ConneexUs в 2017 году.

HERE преимущественно использует OTA для обновления карт. Компания HERE приобрела Advanced Telematics Systems (ATS) в 2018 году. ATS специализируется на ПО с открытым исходным кодом для OTA-обновлений в автомобильной промышленности. Также ATS активно поддерживает open-source проекты для GENIVI, Auto Grade Linux и Uptane. Uptane это фреймворк для безопасной установки OTA-обновлений.

Куда же движется отрасль обновлений по воздуху?


В области OTA можно выделить несколько тенденций. Самая важная из них новые правила использования и потребность в OTA-решениях со стороны ведущих автопроизводителей. Обновления всего ПО в автомобиле (включая ECU) также становится ключевой задачей.

Новые глобальные нормативы (UNECE WP.29) требуют, чтобы обновления ПО (состоящего из миллионов строк кода) для будущих автомобилей были отслеживаемыми и безопасными. Принятие этих правил потребует от автопроизводителей глубокого понимания поведения ПО для получения данных и свидетельств, которые позволят получить требуемые сертификаты. Регуляции могут значительно изменять рынок OTA в течение следующих 5-10 лет.

OTA-обновления становятся важной функциональностью, необходимой OEM-производителям для управления программно-ориентированными автомобилями. Таким образом, большинство OEM-производителей хотят большего контроля над своими OTA-решениями и соответствующими им программными платформами.

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

Думаю, что и у Aurora Labs, и у Sibros есть уникальные технологии, которые многие автопроизводители могли бы использовать в рамках своих OTA-стратегий. Ожидается, что на рынке появится больше решений особенно в связи с тем, что функциональность OTA-обновлений и кибербезопасность становятся все более важными для автомобилей с подключением к сети.

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

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




image

Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.

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

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



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.

Подробнее..

Эволюция системы обновления Android

17.12.2020 06:12:58 | Автор: admin
Индиана устанавливает новый активный раздел: меняет золотого идола на мешок с песком в легендарной сцене из фильма Индиана Джонс: В поисках утраченного ковчегаИндиана устанавливает новый активный раздел: меняет золотого идола на мешок с песком в легендарной сцене из фильма Индиана Джонс: В поисках утраченного ковчега

В этой статье мы рассмотрим все возможные варианты обновления прошивки на устройствах под управлением Fuchsia Android. Особое внимание уделим самому популярному способу обновлению по воздуху или OTA (over-the-air) и расскажем об этапах его развития.

Итак, как можно обновить Android на мобильных устройствах? Занимаясь разработкой ТВ-приставок под управлением этой ОС, мы определили для себя 4 способа, отбросив совсем уж экзотические варианты:

  1. перепрошивка flash-памяти через аппаратный интерфейс JTAG (если есть);

  2. перепрошивка flash-памяти с использованием загрузчика (bootloader);

  3. обновление через Recovery Mode;

  4. OTA (over-the-air).

Рассмотрим подробнее каждый из вариантов.

1. Обновление Android через JTAG-интерфейс

Вариант с JTAG позволяет обновлять устройство только локально и требует подключения девайса с Android к хосту, например, по USB-интерфейсу. Так как перепрошивается flash-память, новую версию Android можно поставить на прошивку с другими ключами безопасности, да и в целом не сильно стесняться в выборе версий самой Android, версии собранной прошивки или переконфигурации разделов flash-памяти.

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

2. Обновление Android через Recovery Mode

Обычно загрузчик является проприетарным, его разрабатывает производитель чипа. Именно bootloader инициализирует доверенную среду выполнения (TEE, trusted execution environment) и проверяет целостность разделов boot и recovery перед переносом выполнения в ядро Linux. Сам загрузчик часто является составным, часть его уровней может быть открытой (например, на базе U-boot), а часть проприетарной.

Bootloader Android позволяет перепрошивать flash-память устройства подготовленными образами разделов. Для этого используется протокол fastboot либо его аналог (в случае Amlogic это будет протокол WorldCup Device). Fastboot,как и его аналог WorldCup Device, это протокол взаимодействия с bootloader через USB-интерфейс или локальную сеть Ethernet.

Для перепрошивки необходимо подключить устройство через USB к хосту (есть вариант использовать LAN Ethernet), перевести загрузчик (bootloader) в специальный update-режим и в этом режиме перепрошить flash-память устройства.

Плюсы и минусы данного метода всё те же, что и для JTAG: так как обновление проходит без участия самой системы Android, при перепрошивке нет ограничений, связанных с версией системы/сборки или ключами безопасности.

Но, как всегда, есть одно НО. :-) Bootloader должен быть разблокирован, а это значит, что мы можем перепрошить сам загрузчик или разделы устройства. Блокировка/разблокировка производится командой fastboot flashing lock/unlock, но для выполнения этой команды может понадобится пароль, установленный тем, кто добрался до этого устройства раньше вас (обычно это производитель).

3. Обновление Android через Recovery Mode и OTA

Если первые два варианта обновления оставались неизменными на протяжении всего времени развития Android, то следующие два варианта обновление через Recovery Mode и OTA реализуются средствами самой Android и эволюционировали вместе со всей ОС.

Стоит упомянуть, что Recovery Mode и OTA это два различных варианта вызова движка обновления Android.

Recovery или non-A/B System Updates

Recovery и движок обновления updater (bootable/recovery/updater) это как раз то, с чего началась система обновления Android (располагается в bootable/recovery в дереве исходников AOSP).

Схема обновления Recovery (или non-A/B System Updates) задействует специальный раздел восстановления (Recovery), где содержится специальная ОС на основе ядра Linux. Эта ОС на базе Linux содержит программное обеспечение для распаковки загруженного образа обновления и его применения к другим разделам. Так и проходит обновление Android.

Пример разметки flash-памяти на устройстве с Android 6.0:

Карта разделов Android 6.0.1

[mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000

[mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000

[mmcblk0p03] cache offset 0x000006c00000, size 0x000020000000

[mmcblk0p04] env offset 0x000027400000, size 0x000000800000

[mmcblk0p05] logo offset 0x000028400000, size 0x000002000000

[mmcblk0p06] recovery offset 0x00002ac00000, size 0x000002000000

[mmcblk0p07] rsv offset 0x00002d400000, size 0x000000800000

[mmcblk0p08] tee offset 0x00002e400000, size 0x000000800000

[mmcblk0p09] crypt offset 0x00002f400000, size 0x000002000000

[mmcblk0p10] misc offset 0x000031c00000, size 0x000002000000

[mmcblk0p11] instaboot offset 0x000034400000, size 0x000020000000

[mmcblk0p12] boot offset 0x000054c00000, size 0x000002000000

[mmcblk0p13] system offset 0x000057400000, size 0x000060000000

[mmcblk0p14] data offset 0x0000b7c00000, size 0x0002ec200000

Сам процесс обновления происходит в два этапа:

  1. после загрузки с раздела Recovery происходит обновления всех остальных разделов Android;

  2. и уже после перезагрузки и запуска новой версии Android происходит обновление раздела Recovery.

При обновлении с использованием движка updater на первом этапе проверяется версия и цифровая подпись образа, поэтому откатить на старую версию ОС уже не получится.

Обновиться по схеме Recovery можно как локально, выбрав в bootloader режим Recovery Mode и запустив движок обновления updater через меню Recovery Mode, либо удаленно, через OTA, когда приложение, работающее в Android, вызывает тот же updater из Java. И как раз при таком удаленном запуске можно организовать массовое обновление целой серии устройств. Этот вариант используют операторы цифрового ТВ при обновлении своих абонентских ТВ-приставок.

Сам раздел Recovery при non-A/B-схеме обновления является физическим разделом во flash-памяти. С появлением A/B-схемы раздел Recovery переместился на RAM-диск в оперативной памяти устройства, но возможность сделать его отдельным физическим разделом так же осталась.

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

Одним из важных недостатков схемы Recovery или non-A/B System Updates является то, что при любом сбое во время обновления или битой прошивке мы получаем пусть и не кирпич (с раздела Recovery всё еще можно запустить устройство в Recovery Mode), но всё же не полнофункциональное и требующее восстановления устройство.

С этим, видимо, решено было что-то делать, потому что следующим этапом эволюции системы обновления стало бесшовное обновление (seamless updates) или A/B-схема обновления.

Бесшовное обновление или A/B-схема

Эта возможность появилась в Android 7.0, она реализована в новом движке update_engine, который располагается в system/update_engine в дереве исходников AOSP.

Главной особенностью A/B-схемы стало то, что в случае сбоев при обновлении можно загрузится с предыдущей рабочей версии системы Android. Flash-память устройства содержит дублирующиеся системные разделы или слоты (slot A и B), отсюда и название A/B system updates (вечная проблема с выбором названий). За выбор слота для загрузки (A или B) отвечает bootloader, анализируя состояние слотов.

Принцип бесшовного обновления Android по A/B-схеме (активный раздел отмечен птичкой)Принцип бесшовного обновления Android по A/B-схеме (активный раздел отмечен птичкой)

Итак, как же происходит обновление:

1) Загружая систему, например, со слотов A, мы скачиваем и прошиваем обновления на слоты B.

2) После перезагрузки со слотов B мы проверяем работоспособность системы, и, если все ОК, сообщаем bootloader, что обновление прошло успешно.

В случае проблем с обновлением bootloader вернется на старую версию прошивки после нескольких неудачных попыток загрузиться с новой системы.

На официальном сайте для разработчиков Android Source этот процесс расписан более детально в 9 шагах, также там объясняется, как все работает после перезагрузки.

Особенность бесшовной A/B-схемы обновление это съедение большего объема flash- памяти. Насколько большего? Это можно оценить по приведенным ниже схемам разделов для Android 9.0. Как уже упоминалось ранее, разработчик может выбирать, какую из схем A/B или non-A/B применять в конфигурации системы.

Карта разделов Android P (recovery)

[mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000

[mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000

[mmcblk0p03] cache offset 0x000006c00000, size 0x000046000000

[mmcblk0p04] env offset 0x00004d400000, size 0x000000800000

[mmcblk0p05] logo offset 0x00004e400000, size 0x000000800000

[mmcblk0p06] recovery offset 0x00004f400000, size 0x000001800000

[mmcblk0p07] misc offset 0x000051400000, size 0x000000800000

[mmcblk0p08] dtbo offset 0x000052400000, size 0x000000800000

[mmcblk0p09] cri_data offset 0x000053400000, size 0x000000800000

[mmcblk0p10] param offset 0x000054400000, size 0x000001000000

[mmcblk0p11] boot offset 0x000055c00000, size 0x000001000000

[mmcblk0p12] rsv offset 0x000057400000, size 0x000001000000

[mmcblk0p13] metadata offset 0x000058c00000, size 0x000001000000

[mmcblk0p14] vbmeta offset 0x00005a400000, size 0x000000200000

[mmcblk0p15] tee offset 0x00005ae00000, size 0x000002000000

[mmcblk0p16] vendor offset 0x00005d600000, size 0x000040000000

[mmcblk0p17] odm offset 0x00009de00000, size 0x000008000000

[mmcblk0p18] system offset 0x0000a6600000, size 0x000050000000

[mmcblk0p19] product offset 0x0000f6e00000, size 0x00000800000

Карта разделов Android P (A/B-схема)

[mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000

[mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000

[mmcblk0p03] cache offset 0x000006c00000, size 0x000000000000

[mmcblk0p04] env offset 0x000007400000, size 0x000000800000

[mmcblk0p05] logo offset 0x000008400000, size 0x000000800000

[mmcblk0p06] boot_a offset 0x000009400000, size 0x000001000000

[mmcblk0p07] misc offset 0x00000ac00000, size 0x000000800000

[mmcblk0p08] dtbo_a offset 0x00000bc00000, size 0x000000800000

[mmcblk0p09] dtbo_b offset 0x00000cc00000, size 0x000000800000

[mmcblk0p10] cri_data offset 0x00000dc00000, size 0x000000800000

[mmcblk0p11] param offset 0x00000ec00000, size 0x000001000000

[mmcblk0p12] boot_b offset 0x000010400000, size 0x000001000000

[mmcblk0p13] rsv offset 0x000011c00000, size 0x000001000000

[mmcblk0p14] metadata_a offset 0x000013400000, size 0x000001000000

[mmcblk0p15] metadata_b offset 0x000014c00000, size 0x000001000000

[mmcblk0p16] vbmeta_a offset 0x000016400000, size 0x000000200000

[mmcblk0p17] vbmeta_b offset 0x000016e00000, size 0x000000200000

[mmcblk0p18] tee offset 0x000017800000, size 0x000002000000

[mmcblk0p19] vendor_a offset 0x00001a000000, size 0x000040000000

[mmcblk0p20] vendor_b offset 0x00005a800000, size 0x000040000000

[mmcblk0p21] odm_a offset 0x00009b000000, size 0x000008000000

[mmcblk0p22] odm_b offset 0x0000a3800000, size 0x000008000000

[mmcblk0p23] system_a offset 0x0000ac000000, size 0x000050000000

[mmcblk0p24] system_b offset 0x0000fc800000, size 0x000050000000

[mmcblk0p25] product_a offset 0x00014d000000, size 0x000008000000

[mmcblk0p26] product_b offset 0x000155800000, size 0x000008000000

[mmcblk0p27] data offset 0x00015e000000, size 0x000245e00000

Если сравнить эти две конфигурации, то можно заметить, что раздел data при A/B-схеме меньше на 1,6 ГБ, и это цена дублирующихся системных разделов. Много это или мало каждый решает сам, ориентируясь на характеристики своего устройства/проекта.

Проект Treble

Следующие изменения в системе обновления произошли в Android 8.0. Начиная с Android O (8.0) и продолжая в Android P (9.0), Google реализует свой проект Treble. Идея проекта состоит в том, чтобы упростить технологический процесс создания обновления для андроид-устройства. Google предложил разделить с помощью неизменных интерфейсов части прошивки, созданием которых занимаются разные компании. Процесс разработки прошивки для конкретного девайса можно упрощенно разделить на следующие шаги:

  1. команда Android создает новую версию своей OC;

  2. разработчик чипа или системы на кристалле (Silicon Manufacturer) создает аппаратно-зависимые патчи для запуска этой версии Android на своих платах;

  3. и уже разработчики конечного устройства (Vendors) делают свою часть для реализации всех функций конкретного продукта для рынка электроники.

Проект Treble разделяет ОС Android с дополнениями от производителей чипов/СнК и код разработчика конечного устройства, так что теперь операционная система может получать обновления без реализации изменений от производителя устройства.

Разделение происходит как с помощью программного интерфейса (переход с Hardware Abstraction Layer 1.0 на HAL2.0), так и за счет выделения отдельных разделов на flash-памяти для Silicon Manufacturer и Vendor (выше в карте разделов Android 9.0 можно увидеть разделы odm, vendor, product).

Переход с HAL1.0 на HAL2.0 заключается в отказе от прямого связывания с системными библиотеками. Вместо этого, используя IPC Binder, можно подключаться к системным сервисам.

И еще одно небольшое, но полезное изменение: начиная с Android 8.0, в update_engine добавлена поддержка потоковых обновлений по A/B-схеме, в ходе которых идет прямая запись в слот B без необходимости промежуточного хранения данных в /data. Для таких потоковых обновлений практически не требуется временное хранилище, достаточно всего лишь 100 килобайт для сохранения метаданных.

При этом необходимо, чтобы http-сервер, используемый для скачивания обновления, поддерживал HTTP range requests или другими словами докачку.

Проект Mainline

Следующим серьезным этапом в развитии системы обновления Android стал проект Mainline. Реализация этого проекта началась с Android 10.0 и продолжилась в текущем Android 11.0.

Проект Mainline позволяет обновлять отдельные системные компоненты без обновления ОС целиком. Нужные данные загружаются через Google Play отдельно от OTA-обновления прошивки от производителя. Предполагается, что прямая доставка обновлений, не привязанных к оборудованию частей Android, позволит существенно сократить время получения обновлений, увеличить оперативность исправления уязвимостей и снизить зависимость от производителей устройств в поддержке безопасности ОС.

Для реализации проекта Mainline выбранные компонентов системы Android преобразуется в модули. Часть этих модулей имеет старый формат APK, а часть конвертируется в новый APEX-формат, который отличается от APK возможностью применения на раннем этапе загрузки системы. На случай возможных сбоев предусмотрен режим отката изменений.

С APEX-пакетами работает системный сервис APEX manager (apexd). Это нативный сервис, который после проверки распаковывает APEX-пакет в пользовательское пространство на диске и добавляет запись о нем в свою базу данных. При следующей загрузке системы APEX manager проверяет все пакеты из базы данных, создает loop-устройство для ext4-образа каждого APEX-пакета и монтирует его по пути /apex/name@ver.

Модули с обновлениями изначально будут поставляться с открытым кодом, они будут сразу доступны в репозиториях AOSP (Android Open Source Project) и смогут включать улучшения и исправления, подготовленные сторонними участниками.

В рамках проекта Mainline в Android 10 было добавлено 13 обновляемых модулей, а в Android 11 в дополнение к уже существующим прибавилось еще 11 модулей.

Схема Virtual A/B

Также в Android 11 к схемам non-A/B и A/B была добавлена схема Virtual A/B. Этот новый механизм обновления сочетает преимущества обоих предшественников, он обеспечивает устойчивое к сбоям обновление устройства, задействуя при этом минимальный объем flash-памяти. Это стало возможным благодаря созданию снимков файловой системы (snapshot) с использованием технологии Device-mapper (подсистема ядра Linux, позволяющая создавать виртуальные блочные устройства) и Dynamic Partitions.

Dynamic Partitions это система организации динамических разделов для Android. С ее помощью можно создавать, изменять размер или уничтожать разделы прямо в процессе обновления по воздуху (OTA). При использовании динамических разделов разработчикам больше не нужно беспокоиться о размере отдельных разделов, таких как system, vendor и product. Вместо них на устройстве выделяется суперраздел, внутри которого можно динамически изменять размер подразделов. Больше нет необходимости оставлять свободное пространство для будущих OTA-обновлений внутри отдельных образов разделов. Оставшееся свободное место в суперразделе теперь доступно для всех динамических подразделов.

И в заключении последние слухи конца 2020 года вишенка на торте. Google конвертирует Android Runtime в модуль Mainline. Android Runtime или ART это среда выполнения Android-приложений, включающая компиляцию байт-кода приложения в машинные инструкции. Так что есть вероятность, что уже в Android 12 можно будет обновить ART через GooglePlay, установив APEX-пакет.

Также, вероятно, система обновления Android мигрирует в Fuchsia, новую ОС Google, которая сейчас находится в процессе разработки. Они традиционно копируют удачные решения в своих программных продуктах. Так, например, update_engine для A/B-схемы, который применяется сейчас в Android, используется в еще одной ОC Google Chrome OS. Или еще один пример: в Fuchsia предлагается библиотека Machina, которая позволяет запускать Linux-программы в специальной изолированной виртуальной машине по аналогии с тем, как организован запуск Linux-приложений в той же Chrome OS.

Желаем всем успешных обновлений!

P.S. Как там было в Индиане Джонсе?
Как вы меня узнали?
У вас глаза вашего отца.
И уши моей матери. Но все остальное принадлежит вам.

Подробнее..

Бесшовные AB-обновления в Android как они устроены

29.09.2020 10:08:21 | Автор: admin
image

Всем привет.

В SberDevices наша команда занимается разработкой различных железок прошивок и для них на базе AOSP.

Начиная с Android 8 (у некоторых вендоров с 7.1) в системе появился новый механизм накатки OTA-обновлений, т. н. Seamless A/B OTA Updates бесшовные обновления. В этом посте я опишу общие принципы его работы, рассмотрю механизм с точки зрения разработчика, а также проведу сравнение со старым (будем его называть recovery-based) подходом применения обновлений. Всё нижесказанное будет справедливо только для чистого AOSP, т. к. конкретная реализация зависит от вендора.

Recovery-based OTA


Обновления для Android поставляются в виде zip-архива с образами обновляемых разделов (block-based updates). Во времена KitKat это был просто набор файлов, которые копировались на устройство прилагаемым скриптом. Я не стану подробно останавливаться на этом режиме, кратко опишу основные принципы его работы:

  • zip-архив скачивается системой на устройство;
  • система перезагружается в режим recovery;
  • проверяется совместимость обновления с устройством, его подпись;
  • если всё OK, выполняется updater-script из zip-архива;
  • в процессе обновления устройство может несколько раз перезагрузиться (например, для обновления device tree);
  • если всё прошло успешно, загружаемся в новую прошивку.

Какие минусы в данной схеме?

  • Необходимость резервировать достаточное количество встроенной памяти для OTA-архива. Для этого служит раздел /cache. Некоторые вендоры используют /data, но это редкость. В итоге пользователю остаётся меньше места (да, приложения всё ещё могут использовать место в разделе /cache, но с некоторыми ограничениями).
  • Перезагрузка и применение обновления занимает время, что может быть критично для некоторых видов устройств, например, для Smart TV.
  • Прерывание процесса обновления может привести к boot loop.
  • Нет возможности откатиться на старую версию прошивки.

Эти неудобства позволяет обойти способ бесшовного обновления. Давайте посмотрим, как он устроен.

Seamless A/B OTA


Ключевые компоненты и механизмы, необходимые для реализации бесшовных A/B-обновлений:

  • слотовая разметка флеш-памяти;
  • взаимодействие с загрузчиком, управлениесостоянием слотов;
  • системный демон update_engine;
  • генерация zip-архива с обновлением. В рамках данной статьи этот аспект рассматриваться не будет.

Слотирование


Основным принципом работы A/B OTA являетсяслотирование.Все разделы, которые необходимо обновлять (это могут быть любые разделы, а не только системные),должны находиться в двух копиях или, иначе, в слотах. В Android-реализации поддерживается 2 слота,которыеименуются соответственно A и B. Система загружается и работает изтекущего слота, второй используется только в момент обновления.К имени раздела добавляется суффикс с именем слота.

Ниже приведена таблица сравнения двух вариантов организации разделов на устройстве.
image

Все слотируемые разделыпомечаютсяопциеймонтированияslotselect, чтобы системамоглавыбратьправильный слот.В зависимости от того, где они описаны, это может быть fstab либо dts.

Изменения в таблице разделов


  • В /сache большенет необходимости.Теперьобновлениеможет сохраняться либов /data,либосразупрошиваться внеактивныйслот(обэтом ниже).
  • Раздел recovery также больше не используется.Однакорежимrecoveryвсё ещё существует, оннеобходим, например, для сброса устройства на заводские настройки (к этому может привестиrescueparty). Или для т. н. ручного обновления (sideload) через adb.Recovery ramdiskтеперьлежит внутриboot-раздела,ядро общее.
  • Для переключения режима загрузки (android/recovery) появилась новая опция в cmdline skip_initramfs.

На первый взгляд кажется, что такая схема не оптимальна, т. к. под систему необходимо выделить в два раза больше места. Но ведь мы избавились от/cache,а значит уже сэкономили большое количествопамяти. Таким образом,система будет заниматьнемногобольше, чем в варианте с recovery.

Главным достоинством A/B-обновлений является возможностьстриминга прошивки. Именно она обеспечивает бесшовность и прозрачность обновлений для пользователя: для обновления устройству достаточно перезагрузиться в новый слот. В этом режиме нет необходимости заранее скачивать zip-архив, занимая место в /data. Вместо этого система сразу пишет блоки данных из специально подготовленного файла (payload, см. ниже) в каждый разделнеактивногослота. С точки зрения реализации нет разницы, скачиваем ли мы предварительно обновление либо сразу стримим его в слот.

Слоты имеют следующие состояния:

  • active активный слот, из него будет загружена система при следующей перезагрузке;
  • bootable обновление успешно прошито в слот, прошло валидацию, совпали хеш-суммы и т. д.;
  • successful система смогла успешно загрузиться в новый слот;
  • unbootable слот поврежден. Система всегда помечает слот как unbootable перед началом процесса обновления.

Оба слота могут бытьbootableиsuccessful, но только один active.

Алгоритм работы загрузчика при выборе слота:
image
  • Загрузчик определяет, что имеется один или более слотов с флагомbootable.
  • Из них выбирается активный слот (либо слот с наибольшим приоритетом).
  • Если система загрузилась успешно, слот помечается какsuccessfulиactive.
  • Иначе слот помечается как unbootable и система перезагружается.


Изменение состояний слотов во время обновления:
image

Необходимые компоненты для работы с Seamless A/B.


boot_control


Для поддержки A/B-обновлений вендор должен реализовать специальный HAL-интерфейс boot_control. Он позволяет изменять состояния слотов и получать о них информацию. Для внешней работы (например, через adb shell) используется утилита bootctl. Интерфейс используется как средство взаимодействия между ОС и загрузчиком.

update_engine


Основной компонент всей A/B-схемы. Занимается загрузкой, стримингом обновлений, проверкой подписи и многим другим. Изменяет состояния слотов через boot_control. Позволяет контролировать процесс обновления устройства: приостанавливать, возобновлять, отменять.
Компонент пришёл в Android из ChromeOS, где уже используется некоторое время.AOSP поддерживает update_engine в виде статической sideload-сборки. Именно она используется в recovery, т.к данный режим не поддерживает динамическую линковку.

Процесс работы данного компонента можно разделить на следующие шаги:

  • загрузка обновления в слот. Загружать можно как из предварительно скачанного пакета с обновлением, так и напрямую по Сети через http/https. В процессе загрузки проверяется подпись, открытый ключ уже находится на устройстве (/system/etc/update_engine/update-payload-key.pub.pem);
  • верификация загруженного обновления и сравнение хеш-сумм;
  • выполнение post-install скриптов.

Структура пакета обновления:
2009-01-01 00:00:00 .....          360          360  META-INF/com/android/metadata2009-01-01 00:00:00 .....          107          107  care_map.txt2009-01-01 00:00:00 .....    384690699    384690699  payload.bin2009-01-01 00:00:00 .....          154          154  payload_properties.txt2009-01-01 00:00:00 .....         1675          943  META-INF/com/android/otacert

  • care_map.txt используется update_verifier-ом (см. ниже);
  • payload_properties.txt содержит хеши и размеры данных внутри payload;
  • payload.bin пакет обновления, содержит блоки всех разделов, метаданные, подпись.


update_engine_client


Клиент для управления демоном update_engine. Может напрямую вызываться вендором для применения обновления.

update_verifier


Утилита для проверки целостности системы при первом запуске (слот с флагомactive, но еще неsuccessful). Контроль целостности реализуется с помощью модуля ядра dm-verity. Если проверка закончилась успешно, утилита помечает текущий слот какsuccessful. Иначе система перезагружается в старый слот. Верифицируются только блоки, указанные в файле care_map.txt.

UpdateEngineApi


Для реализации vendor-сервисов обновлений существует Java API. Также имеется пример реализации такого сервиса.

Рассмотрим пример сборки A/B update в AOSP. Для этого отредактируем Makefile целевой платформы:
#Включим поддержку A/BAB_OTA_UPDATER := true#Укажем необходимые разделы для слотирования:AB_OTA_PARTITIONS := boot system vendor#Добавим необходимые пакетыPRODUCT_PACKAGES := update_engine update_engine_client update_verifier#Отключим раздел recoveryTARGET_NO_RECOVERY := true#Убедимся, что НЕ определяются переменные для раздела cache:#BOARD_CACHEIMAGE_PARTITION_SIZE := ...#BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ...

После вызова make otapackage получаем zip-архив с обновлением. В таком виде он уже подходит для sideload-режима. Можем выполнить перезагрузку в recovery и вызвать adb sideload ota.zip. Этот способ удобен для отладки.

Применение обновления изнутри рабочей системы обычно определяется вендором. Самый простой способ выложить payload.bin на http-сервер и напрямую вызвать update_engine_client.

Пример вызова:
update_engine_client \--payload=http://path/to/payload.bin\--update \--headers=" \FILE_HASH=ozGgyQEddkI5Zax+Wbjo6I/PCR8PEZka9gGd0nWa+oY= \FILE_SIZE=282344983\METADATA_HASH=GLIKfE6KRwylWMHsNadG/Q8iy5f786WTatvMdBlpOPg= \METADATA_SIZE=26723"

В параметр headers передается содержимое файла payload_properties.txt. В logcat можно наблюдать прогресс обновления. Если передать ключ --follow, прогресс будет дублироваться в stdout.

Заключение


Плюсы нового механизма обновлений очевидны:
  • обновление системы происходит в фоне, не прерывая работу пользователя. Да, всё так же потребуется перезагрузка (в новый слот), но пройдёт оназначительнобыстрее, чем перезагрузка в recovery для применения обновления;
  • минимизируется вероятность boot loop (от ошибок в реализации никто не застрахован). Процесс обновления можно прерывать, наактивныйслот это никак не повлияет;
  • появляется возможность отката на предыдущую версию прошивки. Даже если по каким-то причинам обновление прошло неуспешно, система простовернётся к старой версии;
  • благодаря стримингу устройство обновится быстрее;
  • в зависимости от реализации можно полностью исключить пользователя из процесса обновления.

Из минусов я бы выделил два момента:
  • A/B OTA становится зависимой от текущей разметки диска, т. к. обновление происходит во время работы системы. Т. е. становится невозможно накатить обновление с изменёнными разделами;
  • относительная сложность реализации.

И все же, на мой взгляд, плюсы перевешивают. Кстати, в нашем недавно анонсированном устройстве мы используем A/B OTA обновления.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru