На этой странице представлены несколько механизмов, которые производители 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. В этом документе описываются шаги, которые могут предпринять поставщики SoC и OEM-производители для создания SSI. Это означает единый образ, созданный из исходных кодов фреймворка ОС Android, для повторного использования на нескольких устройствах, для поддержания обратной совместимости с реализациями поставщиков и для значительного снижения сложности и стоимости обновлений ОС Android. Конкретные шаги, необходимые для создания SSI, см. в разделе «Рекомендуемые шаги для SSI на основе GSI» . Обратите внимание, что не обязательно использовать все четыре шага. Выбор того или иного шага (например, только шага 1) зависит от вашей реализации.
Обзор SSI
Благодаря SSI компоненты программного обеспечения, специфичные для продукта, и OEM-расширения размещаются в новом разделе /product . Компоненты в разделе /product используют четко определенный, стабильный интерфейс для взаимодействия с компонентами в разделе /system . OEM-производители могут либо создать один SSI, либо использовать небольшое количество SSI для использования в различных моделях устройств. При выпуске новой версии ОС Android OEM-производители инвестируют только один раз в обновление своих SSI до последней версии Android. Они могут повторно использовать SSI для обновления нескольких устройств без обновления раздела /product .
Обратите внимание, что OEM-производители и поставщики SoC создают SSI, включающие все необходимые OEM-производителям функции и модификации. Механизмы и рекомендации, представленные на этой странице, предназначены для OEM-производителей для достижения следующих ключевых целей:
- Повторно используйте SSI на нескольких моделях устройств.
- Обновите систему 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собрано из исходных кодов Android, модифицированных OEM-производителем.Раздел
/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 (приложения) в разделе
/productне могут использовать скрытые 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 (который в Android 11 назывался mainline_system.mk , а в AOSP был переименован в generic_system.mk ), образ системы (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-производители могут использовать макрос 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 и использовать его совместно с несколькими устройствами, устранив все различия и сделав раздел /system_ext общим.
В этом разделе даны рекомендации по созданию общего раздела /system_ext .
Раскрыть скрытые API в системном разделе
Многие приложения, специфичные для устройств, невозможно установить в раздел продукта, поскольку они используют скрытые API, которые запрещены в разделе продукта. Чтобы перенести приложения, специфичные для устройств, в раздел продукта, отключите использование скрытых API.
Предпочтительный способ удаления скрытых API из приложений — найти альтернативные общедоступные или системные API для их замены. Если API для замены скрытых API отсутствуют, OEM-производители могут внести свой вклад в AOSP, чтобы определить новые системные API для своих устройств.
В качестве альтернативы, OEM-производители могут определить собственные API, создав собственную библиотеку Java SDK в разделе /system_ext . Она может использовать скрытые API в системном разделе и предоставлять их приложениям в разделе продукта или поставщика. OEM-производители должны заморозить API, работающие с продуктом, для обеспечения обратной совместимости.
Включить надмножество всех APK и пропустить установку некоторых пакетов для каждого устройства
Некоторые пакеты, входящие в комплект системы, не являются общими для разных устройств. Разделение этих APK-модулей для их переноса в раздел продукта или поставщика может быть затруднительным. В качестве временного решения OEM-производители могут включить все модули в SSI, а затем отфильтровать нежелательные с помощью свойства SKU ( ro.boot.hardware.sku ). Для использования фильтра OEM-производители накладывают ресурсы фреймворка config_disableApkUnlessMatchedSku_skus_list и config_disableApksUnlessMatchedSku_apk_list .
Для более точной настройки объявите широковещательный приемник, который отключает ненужные пакеты. При получении сообщения ACTION_BOOT_COMPLETED широковещательный приемник вызывает setApplicationEnabledSetting для отключения пакета.
Определите 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 , и использовать его вместо него. Пример см. в разделе «Усиление интерфейсов разделов продукта» .
Могу ли я удалить модули из generic_system.mk, которые конфликтуют с моей реализацией?
Нет. GSI имеет минимальный набор загружаемых и тестируемых модулей. Если вы считаете, что модуль не является необходимым, сообщите об ошибке, чтобы обновить файл generic_system.mk в AOSP.