Общий образ системы Android

На этой странице представлены несколько механизмов, которые производители устройств Android могут использовать для создания собственного общего образа системы (SSI) во всех линейках продуктов. В нем также предлагается процедура создания SSI, принадлежащего OEM, на основе общего образа системы (GSI), созданного AOSP.

Фон

В Project Treble монолитный Android был разделен на две части: аппаратную часть (реализация поставщика) и общую часть ОС (фреймворк ОС Android). Программное обеспечение для каждого из них устанавливается в отдельный раздел: раздел поставщика для программного обеспечения для конкретного оборудования и системный раздел для общего программного обеспечения ОС. Версионный интерфейс, называемый интерфейсом поставщика ( VINTF ), определяется и применяется в двух разделах. Используя эту систему разделения, вы можете изменить системный раздел, не изменяя раздел поставщика, и наоборот.

Мотивация

Код платформы, выпущенный в AOSP, совместим с архитектурой Treble и поддерживает обратную совместимость с реализациями старых поставщиков. Например, общий образ системы, созданный на основе источников AOSP Android 10, может работать на любом совместимом с Treble устройстве, работающем под управлением Android 8 или более поздней версии. Версия Android, поставляемая на потребительские устройства, модифицируется поставщиками SoC и OEM-производителями. (См. «Жизнь выпуска Android» .) Эти изменения и расширения, внесенные в платформу, не были написаны для обеспечения обратной совместимости, что привело к увеличению сложности и увеличению стоимости обновления ОС. Изменения и модификации конкретных устройств увеличивают стоимость и сложность обновления версии ОС Android.

До Android 11 не было четкой архитектуры, которая позволяла бы партнерам создавать модульные расширения для платформы ОС Android. В этом документе описаны шаги, которые поставщики SoC и OEM-производители могут предпринять для создания SSI. Это означает, что один образ создается на основе исходных кодов платформы ОС Android для повторного использования на нескольких устройствах, для обеспечения обратной совместимости с реализациями поставщиков и для обеспечения значительного снижения сложности и стоимости обновлений ОС Android. Конкретные шаги, необходимые для создания 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. Например, библиотека платформы Java OEM, которая предоставляет специальные 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 только через этот интерфейс. Например, образ поставщика не может зависеть от частной части образа системы, и наоборот. Первоначально это определено в Project Treble, который разделяет образы на системные разделы и разделы поставщиков. Интерфейс описывается с помощью следующих механизмов:

  • HIDL (сквозной HAL доступен только для модулей system и system_ext )
  • Стабильный AIDL
  • Конфигурации
    • API свойств системы
    • API схемы файла конфигурации
  • ВНДК
  • API-интерфейсы Android SDK
  • Библиотека Java SDK

• Интерфейсы продукта : Интерфейс продукта — это интерфейс между 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 должны быть отделены от других разделов. Единственными разрешенными зависимостями модулей продукта являются некоторые библиотеки VNDK (включая LLNDK) из раздела /system . Библиотеки JNI, от которых зависят приложения продукта, должны быть библиотеками NDK.
• Интерфейсы Java . Модули Java (приложения) в разделе /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. Если в качестве образа system используется GSI, 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 (который в Android 11 назывался mainline_system.mk и был переименован в 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 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-производители могут использовать макрос make-файла под названием require-artifacts-in-path , чтобы предотвратить любое объявление системных модулей после вызова макроса. См. пример создания make-файла и включения проверки пути к артефакту .

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 и использовать его между несколькими устройствами, удалив любые различия и сделав раздел /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 вручную, а не полагайтесь на автоматическое создание. Подробную информацию см. в разделе Наложения ресурсов времени выполнения (RRO) . OEM-производители также могут определять условные RRO, которые зависят от свойств системы, используя атрибуты android:requiredSystemPropertyName и android:requiredSystemPropertyValue .

Часто задаваемые вопросы (FAQ)

Могу ли я определить несколько SSI?

Это зависит от общности и характеристик устройств (или группы устройств). OEM-производители могут попытаться сделать раздел system_ext общим, как описано в разделе «Создание общего раздела system_ext» . Если группа устройств имеет много различий, лучше определить несколько SSI.

Могу ли я изменить generic_system.mk ( mainline_system.mk ) для OEM GSI?

Нет. Но OEM-производители могут определить новый make-файл для OEM-GSI, который наследует файл generic_system.mk , и использовать вместо него новый make-файл. Пример см. в разделе «Обеспечение интерфейсов разделов продукта ».

Могу ли я удалить модули из generic_system.mk , которые конфликтуют с моей реализацией?

Нет. GSI имеет минимальный набор загрузочных и тестируемых модулей. Если вы считаете, что модуль не является необходимым, сообщите об ошибке, чтобы обновить файл generic_system.mk в AOSP.