На этой странице представлено несколько механизмов, которые OEM-производители устройств Android могут использовать для собственного общего образа системы (SSI) для всех линеек продуктов. На ней также предлагается процедура для создания SSI, принадлежащего OEM, на основе образа общей системы (GSI), созданного AOSP.
Фон
С проектом Treble монолитный Android был разделен на две части: аппаратно-зависимую часть (реализация поставщика) и общую часть ОС (фреймворк ОС Android). Программное обеспечение для каждой из них устанавливается в отдельный раздел: раздел поставщика для аппаратно-зависимого программного обеспечения и системный раздел для общего программного обеспечения ОС. Версионный интерфейс, называемый интерфейсом поставщика ( VINTF ), определяется и применяется в двух разделах. Используя эту систему разбиения на разделы, вы можете изменять системный раздел, не изменяя раздел поставщика, и наоборот.
Мотивация
Код фреймворка, выпущенный в AOSP, соответствует архитектуре Treble и поддерживает обратную совместимость с более старыми реализациями поставщиков. Например, общий образ системы, созданный из исходных кодов Android 10 AOSP, может работать на любом устройстве, совместимом с Treble, работающем на Android 8 или выше. Версия Android, поставляемая на потребительские устройства, изменяется поставщиками SoC и OEM-производителями. (См. Жизнь релиза Android .) Эти изменения и расширения, внесенные в фреймворк, не были написаны для поддержания обратной совместимости, что привело к увеличению сложности и более высокой стоимости обновления ОС. Изменения и модификации, специфичные для устройств, увеличивают стоимость и сложность обновления версии ОС Android.
До Android 11 не было четкой архитектуры, которая позволяла бы партнерам создавать модульные расширения для фреймворка Android OS. В этом документе описываются шаги, которые поставщики SoC и OEM-производители могут предпринять для создания SSI. Это означает один образ, созданный из исходных кодов фреймворка Android OS для повторного использования на нескольких устройствах, для поддержания обратной совместимости с реализациями поставщиков и для обеспечения значительного снижения сложности и стоимости обновлений Android OS. Конкретные шаги, необходимые для создания SSI, см. в разделе Рекомендуемые шаги для SSI на основе GSI , и обратите внимание, что вам не обязательно использовать все четыре шага. Выбор шагов (например, только шаг 1) зависит от вашей реализации.
Обзор SSI
С помощью SSI программные компоненты, специфичные для продукта, и расширения OEM размещаются в новом разделе /product . Компоненты в разделе /product используют четко определенный, стабильный интерфейс для взаимодействия с компонентами в разделе /system . OEM-производители могут либо создать один SSI, либо иметь небольшое количество SSI для использования в нескольких SKU устройств. Когда выпускается новая версия ОС Android, OEM-производители инвестируют только один раз в обновление своих SSI до последней версии Android. Они могут повторно использовать SSI для обновления нескольких устройств без обновления раздела /product .
Обратите внимание, что OEM-производители и поставщики SoC создают SSI, которые включают все пользовательские функции и модификации, необходимые OEM-производителю. Механизмы и передовые методы, представленные на этой странице, предназначены для OEM-производителей, чтобы они могли достичь следующих ключевых целей:
- Повторно используйте SSI в нескольких SKU устройств.
- Обновите систему Android с помощью модульных расширений, чтобы упростить обновление ОС.
Основная идея разделения компонентов, специфичных для продукта, в раздел продукта похожа на идею Treble о разделении компонентов, специфичных для SoC, в раздел поставщика. Интерфейс продукта (похожий на VINTF ) позволяет осуществлять связь между SSI и разделом продукта. Обратите внимание, что в отношении SSI термин «компоненты» описывает все ресурсы, двоичные файлы, тексты, библиотеки и т. д., которые устанавливаются в образы, которые по сути становятся разделами.
Разделы вокруг SSI
Рисунок 1 показывает разделы вокруг SSI и версионные интерфейсы по разделам и политики на интерфейсах. В этом разделе подробно описываются каждый из разделов и интерфейсов.
Рисунок 1. Разделы и интерфейсы вокруг SSI
Изображения и разделы
Информация в этом разделе различает термины «образ» и «раздел» .
- Изображение — это концептуальный фрагмент программного обеспечения, который можно обновлять независимо.
- Раздел — это физическое хранилище, которое можно обновлять независимо.
Разделы на рисунке 1 определены следующим образом:
SSI: SSI — это образ, который является общим для OEM и может существовать на нескольких устройствах. Он не имеет никаких компонентов, специфичных для оборудования или продукта. Все в данном SSI, по определению, является общим для всех устройств, использующих этот SSI. SSI состоит либо из одного образа
/system, либо из разделов/systemи/system_ext, как показано на рисунке 1.Раздел
/systemсодержит компоненты на основе AOSP, тогда как/system_ext, при реализации, содержит расширения OEM и SoC-поставщиков и компоненты, которые тесно связаны с компонентами AOSP. Например, библиотека фреймворка OEM Java, которая предоставляет пользовательские API для собственных приложений OEM, лучше помещается в раздел/system_extчем в раздел/system. Содержимое разделов/systemи/system_extсоздается из модифицированных OEM-поставщиками исходных кодов Android.Раздел
/system_extнеобязателен, но его полезно использовать для любых пользовательских функций и расширений, которые тесно связаны с компонентами на основе AOSP. Это различие помогает вам определить изменения, которые необходимо сделать, чтобы переместить такие компоненты из раздела/system_extв раздел/productв течение определенного периода времени.
Продукт: набор компонентов, специфичных для продукта или устройства, которые представляют OEM-настройки и расширения для ОС Android. Поместите специфичные для SoC компоненты в раздел
/vendor. Поставщики SoC также могут использовать раздел/productдля соответствующих компонентов, таких как независимые от SoC. Например, если поставщик SoC предоставляет своим OEM-клиентам независимый от SoC компонент (который необязательно поставлять с продуктом), поставщик SoC может поместить этот компонент в образ продукта. Расположение компонента не определяется его владельцем , оно диктуется его назначением .Поставщик: Набор компонентов, специфичных для SoC.
ODM: набор компонентов, специфичных для платы, которые не предоставляются SoC. Обычно поставщик SoC владеет образом поставщика, а производитель устройства владеет образом ODM. Если нет отдельного раздела
/odm, образы поставщика SoC и ODM объединяются в разделе/vendor.
Интерфейсы между изображениями
В SSI существует два основных интерфейса для изображений поставщиков и продуктов:
Интерфейс поставщика (VINTF) : VINTF — это интерфейс для компонентов, которые находятся в образах поставщика и ODM. Компоненты в образах продукта и системы могут взаимодействовать с образами поставщика и ODM только через этот интерфейс. Например, образ поставщика не может зависеть от частной части образа системы и наоборот. Это изначально определено в проекте Treble, который разделил образы на системные и разделы поставщика. Интерфейс описывается с использованием следующих механизмов:
- HIDL (сквозной HAL доступен только для модулей
systemиsystem_ext) - Стабильный AIDL
- Конфигурации
- API системных свойств
- API схемы файла конфигурации
- ВНДК
- API Android SDK
- Библиотека Java SDK
- HIDL (сквозной HAL доступен только для модулей
Интерфейсы продукта: Интерфейс продукта — это интерфейс между SSI и образом продукта. Определение стабильного интерфейса отделяет компоненты продукта от компонентов системы в SSI. Интерфейс продукта требует тех же стабильных интерфейсов, что и VINTF. Однако для устройств, запускаемых с Android 11 (и выше), применяются только API VNDK и Android SDK.
Включить SSI в Android 11
В этом разделе объясняется, как использовать новые функции для поддержки SSI в Android 11.
Раздел /system_ext
Раздел /system_ext был представлен в Android 11 как необязательный раздел. (Это место для не-AOSP-компонентов, которые имеют тесную связь с компонентами, определенными AOSP в разделе /system .) Предполагается, что раздел /system_ext является OEM-специфичным расширением для раздела /system без интерфейса, определенного между двумя разделами. Компоненты в разделе /system_ext могут выполнять частные вызовы API в раздел /system , а компоненты в разделе /system могут выполнять частные вызовы API в раздел /system_ext .
Поскольку два раздела тесно связаны, оба раздела обновляются вместе при выпуске новой версии Android. Раздел /system_ext , созданный для предыдущей версии Android, не обязательно должен быть совместим с разделом /system в следующей версии Android.
Чтобы установить модуль в раздел /system_ext , добавьте system_ext_specific: true в файл Android.bp . Для устройств, не имеющих раздела /system_ext , установите такие модули в подкаталог ./system_ext в разделе /system .
История
Вот немного истории о разделе /system_ext . Целью проектирования было поместить все компоненты, специфичные для OEM, независимо от того, являются ли они общими, в раздел /product . Однако перемещение их всех одновременно было нецелесообразным, особенно когда некоторые компоненты имели тесную связь с разделом /system . Чтобы переместить тесно связанный компонент в раздел /product , интерфейс продукта должен быть расширен. Это часто требовало обширного рефакторинга самого компонента, что отнимало много времени и усилий. Раздел /system_ext начинался как место для временного размещения тех компонентов, которые не готовы к перемещению в раздел /product . Целью SSI было в конечном итоге устранить раздел /system_ext .
Однако раздел /system_ext полезен для того, чтобы сохранить раздел /system как можно ближе к AOSP. При использовании SSI большая часть усилий по обновлению тратится на компоненты в разделах /system и /system_ext . Когда образ системы создается из источников, максимально похожих на те, что в AOSP, вы можете сосредоточить усилия по обновлению на образе system_ext .
Разделить компоненты из разделов /system и /system_ext на раздел /product.
В Android 9 появился раздел /product , связанный с разделом /system . Модули в разделе /product используют системные ресурсы без каких-либо ограничений, и наоборот. Чтобы сделать SSI возможным в Android 10, компоненты продукта разделены на разделы /system_ext и /product . Раздел /system_ext не должен соответствовать ограничениям на использование системных компонентов, которые раздел /product имел в Android 9. Начиная с Android 10, раздел /product должен быть отделен от раздела /system и должен использовать стабильные интерфейсы из разделов /system и /system_ext .
Основная цель раздела /system_ext — расширение системных функций, а не установка связанных модулей продукта, как описано в разделе /system_ext partition . Для этого разделите модули, специфичные для продукта, и переместите их в раздел /product . Разделение модулей, специфичных для продукта, делает /system_ext общим для устройств. (Более подробную информацию см. в разделе Создание общего раздела /system_ext .)
Чтобы отделить раздел /product от компонентов системы, раздел /product должен иметь ту же политику принудительного применения, что и раздел /vendor , который уже был отделен с помощью Project Treble.
Начиная с Android 11, собственные интерфейсы и интерфейсы Java для раздела /product применяются, как описано ниже. Для получения дополнительной информации см. Принудительное применение интерфейсов раздела Product .
- Собственные интерфейсы: Собственные модули в разделе
/productдолжны быть отделены от других разделов. Единственными допустимыми зависимостями от модулей продукта являются некоторые библиотеки VNDK (включая LLNDK) из раздела/system. Библиотеки JNI, от которых зависят приложения продукта, должны быть библиотеками NDK. - Интерфейсы Java: модули Java (app) в разделе
/productне могут использовать скрытые API, поскольку они нестабильны. Эти модули должны использовать только публичные API и системные API из раздела/system, а также библиотеки Java SDK в разделе/systemили/system_ext. Вы можете определить библиотеки Java SDK для пользовательских API.
Предлагаемые шаги для SSI на основе GSI
Рисунок 2. Предлагаемые разделы для SSI на основе GSI
Универсальный системный образ (GSI) — это системный образ, созданный непосредственно из AOSP. Он используется для тестов соответствия Treble (например, CTS-on-GSI) и в качестве референтной платформы, которую разработчики приложений могут использовать для проверки совместимости своих приложений, когда у них нет реального устройства, работающего под управлением требуемой версии Android.
OEM-производители также могут использовать GSI для создания своего SSI. Как объясняется в разделе Образы и разделы , SSI состоит из образа системы для компонентов, определенных AOSP, и образа system_ext для компонентов, определенных OEM-производителем. Когда GSI используется в качестве образа system , OEM-производитель может сосредоточиться на образе system_ext для обновления.
В этом разделе представлено руководство для OEM-производителей, которые хотят модулировать свои настройки в разделах /system_ext и /product , используя образ системы AOSP или близкий к AOSP. Если OEM-производители создают образ системы из источников AOSP, они могут заменить созданный ими образ системы на GSI, предоставленный AOSP. Однако OEM-производителям не нужно сразу достигать последнего шага (используя GSI как есть).
Шаг 1. Наследовать generic_system.mk для образа системы OEM (OEM GSI)
Наследуя generic_system.mk (который был назван mainline_system.mk в Android 11 и переименован в generic_system.mk в AOSP), образ системы (OEM GSI) включает все файлы, которые есть в AOSP GSI. Эти файлы могут быть изменены OEM-производителями, так что OEM GSI может содержать фирменные файлы OEM в дополнение к файлам AOSP GSI. Однако OEM-производителям не разрешается изменять сам файл generic_system.mk .
Рисунок 3. Наследование generic_system.mk для образа системы OEM
Шаг 2. Сделайте так, чтобы OEM GSI имел тот же список файлов, что и AOSP GSI
На этом этапе OEM GSI не может иметь дополнительных файлов. Собственные файлы OEM должны быть перемещены в разделы system_ext или product .
Рисунок 4. Перемещение добавленных файлов из OEM GSI
Шаг 3. Определите список разрешенных файлов для ограничения измененных файлов в OEM GSI
Для проверки измененных файлов OEM-производители могут использовать инструмент compare_images и сравнить AOSP GSI с OEM GSI. Получите AOSP GSI из AOSP lunch target generic_system_* .
Периодически запуская инструмент compare_images с параметром allowlist , вы можете отслеживать различия за пределами разрешенного списка. Это предотвращает необходимость дополнительных модификаций OEM GSI.
Рисунок 5. Определение списка разрешенных файлов для сокращения списка измененных файлов в OEM GSI
Шаг 4. Сделайте так, чтобы OEM GSI имел те же двоичные файлы, что и AOSP GSI.
Очистка списка разрешений позволяет OEM-производителям использовать AOSP GSI в качестве образа системы для своих собственных продуктов. Чтобы очистить список разрешений, OEM-производители могут либо отказаться от своих изменений в OEM GSI, либо перенести свои изменения в AOSP, чтобы AOSP GSI включил их изменения.
Рисунок 6. Создание OEM GSI с теми же двоичными файлами, что и AOSP GSI
Определить SSI для OEM-производителей
Защитите раздел /system во время сборки
Чтобы избежать любых изменений, связанных с продуктом, в разделе /system и определить OEM GSI, OEM-производители могут использовать макрос makefile, называемый require-artifacts-in-path , чтобы предотвратить любое объявление системных модулей после вызова макроса. См. пример создания makefile и включения проверки пути артефакта .
OEM-производители могут определить список, позволяющий временно устанавливать модули, специфичные для продукта, в раздел /system . Однако список должен быть пустым, чтобы сделать OEM GSI общим для всех продуктов OEM. Этот процесс предназначен для определения OEM GSI и может быть независимым от шагов для AOSP GSI .
Обеспечить соблюдение интерфейсов продукта
Чтобы гарантировать, что раздел /product не связан, OEM-производители могут гарантировать, что их устройства будут применять интерфейсы продукта, установив PRODUCT_PRODUCT_VNDK_VERSION:= current для собственных модулей и PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true для модулей Java. Эти переменные автоматически устанавливаются, если PRODUCT_SHIPPING_API_LEVEL устройства больше или равен 30 Подробную информацию см. в разделе Принудительное применение интерфейсов раздела продукта .
Сделать раздел /system_ext общим
Раздел /system_ext может отличаться между устройствами, поскольку он может иметь специфичные для устройства системные модули. Поскольку SSI состоит из разделов /system и /system_ext , различия в разделе /system_ext мешают OEM-производителям определять SSI. OEM-производители могут иметь свой собственный SSI и могут совместно использовать этот SSI между несколькими устройствами, удаляя любые различия и делая раздел /system_ext общим.
В этом разделе даны рекомендации по созданию общего раздела /system_ext .
Раскрыть скрытые API в системном разделе
Многие приложения, специфичные для продукта, не могут быть установлены в разделе продукта, поскольку они используют скрытые API, которые запрещены в разделе продукта. Чтобы переместить приложения, специфичные для устройства, в раздел продукта, удалите использование скрытых API.
Предпочтительный способ удаления скрытых API из приложений — найти альтернативные публичные или системные API для их замены. Если нет API для замены скрытых API, OEM-производители могут внести свой вклад в AOSP, чтобы определить новые системные API для своих устройств.
В качестве альтернативы OEM-производители могут определять пользовательские API, создавая собственную библиотеку Java SDK в разделе /system_ext . Он может использовать скрытые API в системном разделе и предоставлять API приложениям в разделе продукта или поставщика. OEM-производители должны заморозить API, ориентированные на продукт, для обратной совместимости.
Включить надмножество всех APK и пропустить установку некоторых пакетов для каждого устройства
Некоторые пакеты, которые связаны с системой, не являются общими для разных устройств. Разделение этих модулей APK для перемещения их в раздел продукта или поставщика может быть сложным. В качестве временного решения OEM-производители могут сделать так, чтобы SSI включал все модули, а затем отфильтровать нежелательные с помощью свойства SKU ( ro.boot.hardware.sku ). Чтобы использовать фильтр, OEM-производители накладывают ресурсы фреймворка config_disableApkUnlessMatchedSku_skus_list и config_disableApksUnlessMatchedSku_apk_list .
Для более точных настроек объявите широковещательный приемник, который отключает ненужные пакеты. Широковещательный приемник вызывает setApplicationEnabledSetting для отключения пакета, когда он получает сообщение ACTION_BOOT_COMPLETED .
Определите RRO вместо использования статического наложения ресурсов
Статическое наложение ресурсов управляет наложенными пакетами. Однако оно может помешать определению SSI, поэтому убедитесь, что свойства для RRO включены и установлены правильно. Установив свойства следующим образом, OEM-производители могут иметь все автоматически сгенерированные наложения как RRO.
PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty
Если требуется подробная конфигурация, определите RRO вручную, а не полагайтесь на автоматически сгенерированную. Подробную информацию см. в разделе Runtime Resource Overlays (RROs) . OEM-производители также могут определять условные RRO, которые зависят от свойств системы, используя атрибуты android:requiredSystemPropertyName и android:requiredSystemPropertyValue .
Часто задаваемые вопросы (FAQ)
Могу ли я определить несколько SSI?
Это зависит от общности и характеристик устройств (или группы устройств). OEM-производители могут попытаться сделать раздел system_ext общим, как описано в разделе Создание общего раздела system_ext . Если группа устройств имеет много различий, то лучше определить несколько SSI.
Могу ли я изменить generic_system.mk (mainline_system.mk) для OEM GSI?
Нет. Но OEM-производители могут определить новый makefile для OEM GSI, который наследует файл generic_system.mk , и использовать вместо него новый makefile. Пример см. в разделе Enforcing Product Partition Interfaces .
Могу ли я удалить модули из generic_system.mk, которые конфликтуют с моей реализацией?
Нет. GSI имеет минимальный набор загружаемых и тестируемых модулей. Если вы считаете, что модуль не является необходимым, пожалуйста, отправьте сообщение об ошибке для обновления файла generic_system.mk в AOSP.