Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Комплект разработчика для поставщиков (VNDK)

Vendor Native Development Kit (VNDK) - это набор библиотек, предназначенных исключительно для поставщиков для реализации своих HAL. VNDK поставляется в system.img и динамически связан с кодом поставщика во время выполнения.

Почему ВНДК?

В Android 8.0 и более поздних версиях предусмотрены обновления только для платформы, в которых системный раздел может быть обновлен до последней версии, в то время как разделы поставщика остаются без изменений. Это подразумевает, что двоичные файлы, созданные в разное время, должны работать друг с другом; VNDK охватывает изменения API / ABI в версиях Android.

Обновления только для платформы включают в себя следующие проблемы:

  • Зависимость между модулями фреймворка и модулями вендора . До Android 8.0 модули с обеих сторон могли связываться с модулями с другой стороны. Однако зависимости от вендорных модулей накладывали нежелательные ограничения на разработку модулей инфраструктуры.
  • Расширения к библиотекам AOSP . Android 8.0 и выше требует, чтобы все устройства Android проходили CTS, когда системный раздел заменяется стандартным Generic System Image (GSI). Однако, поскольку поставщики расширяют библиотеки AOSP для повышения производительности или добавления дополнительных функций для своих реализаций HIDL, перепрошивка системного раздела со стандартным GSI может нарушить реализацию HIDL поставщика. ( Инструкции по предотвращению таких поломок см. В расширениях VNDK .)

Для решения этих проблем в Android 8.0 представлено несколько методов, таких как VNDK (описанный в этом разделе), HIDL , hwbinder, наложение дерева устройств и наложение sepolicy.

Ресурсы ВНДК

Этот раздел включает в себя следующие ресурсы VNDK:

  • Концепции VNDK (ниже) описывают совместно используемые библиотеки инфраструктуры, HAL с одинаковым процессом (SP-HAL) и терминологию VNDK.
  • Расширения VNDK классифицируют специфичные для поставщика изменения по категориям. Например, библиотеки с расширенными функциональными возможностями, на которые опираются модули вендора, должны быть скопированы в раздел вендора, но несовместимые с ABI изменения запрещены.
  • Поддержка системы сборки VNDK описывает конфигурации системы сборки и синтаксисы определения модулей, связанные с VNDK.
  • Инструмент определения VNDK помогает перенести дерево исходных текстов на Android 8.0 и выше.
  • Пространство имен компоновщика обеспечивает детальный контроль над связями с общей библиотекой.
  • Каталоги, правила и sepolicy определяют структуру каталогов для устройств под управлением Android 8.0 и выше, правила VNDK и связанную с ними политику.
  • Презентация VNDK Design иллюстрирует фундаментальные концепции VDNK, используемые в Android 8.0 и выше.

Концепции ВНДК

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

Такой мир включает в себя возможность того, что стабильных общедоступных API из общих библиотек инфраструктуры может быть недостаточно для разработчиков модулей вендора (хотя API могут меняться между выпусками Android), что требует, чтобы некоторая часть общих библиотек инфраструктуры была доступна процессам вендора. Кроме того, поскольку требования к производительности могут привести к компромиссам, некоторые критичные ко времени отклика HAL должны рассматриваться по-разному.

В следующих разделах подробно описывается, как VNDK обрабатывает общие библиотеки инфраструктуры для поставщиков и HAL от Same-Process (SP-HAL).

Рамочные разделяемые библиотеки для вендора

В этом разделе описываются критерии классификации разделяемых библиотек, доступных для процессов поставщика. Существует два подхода к поддержке модулей вендоров в нескольких выпусках Android:

  1. Стабилизировать ABI / API общих библиотек инфраструктуры . Новые модули инфраструктуры и модули старых поставщиков могут использовать одну и ту же общую библиотеку, чтобы уменьшить объем памяти и объем хранилища. Уникальная общая библиотека также позволяет избежать нескольких проблем с двойной загрузкой. Однако стоимость разработки для поддержания стабильных ABI / API высока, и нереально стабилизировать все ABI / API, экспортируемые каждой общей библиотекой инфраструктуры.
  2. Скопируйте старые рамки общих библиотек . Поставляется с жестким ограничением на побочные каналы, определяемым как все механизмы для взаимодействия между модулями платформы и модулями вендора, включая (но не ограничиваясь) связыватель, сокет, канал, разделяемую память, общий файл и системные свойства. Не должно быть связи, если протокол связи не заморожен и не стабилен (например, HIDL через hwbinder). Двойная загрузка разделяемых библиотек также может вызвать проблемы; например, если объект, созданный новой библиотекой, передается в функции из старой библиотеки, может произойти ошибка, поскольку эти библиотеки могут интерпретировать объект по-разному.

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

  • Библиотеки LL-NDK - это общие библиотеки, которые, как известно, стабильны. Их разработчики стремятся поддерживать стабильность API / ABI.
    • LL-NDK включает в себя следующие библиотеки: libEGL.so , libGLESv1_CM.so , libGLESv2.so , libGLESv3.so , libandroid_net.so , libc.so , libdl.so , liblog.so , libm.so , libnativewindow.so , libneuralnetworks.so , libsync.so , libvndksupport.so и libvulkan.so ,
  • Приемлемые библиотеки VNDK (VNDK) являются общими библиотеками Framework, которые можно безопасно копировать дважды. Каркасные модули и модули поставщиков могут связываться со своими собственными копиями. Общая библиотека инфраструктуры может стать допустимой библиотекой VNDK, только если она удовлетворяет следующим критериям:
    • Он не отправляет / не получает IPC в / из фреймворка.
    • Это не относится к виртуальной машине ART.
    • Он не читает / не записывает файлы / разделы с нестабильными форматами файлов.
    • У него нет специальной лицензии на программное обеспечение, которая требует юридических проверок.
    • Его владелец кода не имеет возражений против использования поставщика.
  • Библиотеки только для платформы (FWK-ONLY) - это общие библиотеки, которые не относятся к категориям, упомянутым выше. Эти библиотеки:
    • Рассматриваются рамки внутренней реализации деталей.
    • Не должны быть доступны для модулей поставщиков.
    • Имеют нестабильные ABI / API и не гарантируют совместимость API / ABI.
    • Не копируются.

Тот же процесс HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) - это набор предопределенных HAL, реализованных в виде общих библиотек поставщика и загруженных в процессы Framework . SP-HAL изолированы пространством имен компоновщика (управляет библиотеками и символами, которые видны общим библиотекам). SP-HAL должны зависеть только от LL-NDK и VNDK-SP .

VNDK-SP является предопределенным подмножеством подходящих библиотек VNDK. Библиотеки VNDK-SP тщательно проверяются, чтобы гарантировать, что двойная загрузка библиотек VNDK-SP в процессы инфраструктуры не вызывает проблем. И SP-HAL, и VNDK-SP определяются Google.

Следующие библиотеки являются утвержденными SP-HAL:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

Библиотеки VNDK-SP указывают vndk: { support_system_process: true } в своих файлах Android.bp. Если также указано vendor_available: false , эти библиотеки называются VNDK-SP-Private и невидимы для SP-HALS .

Ниже приведены библиотеки только для инфраструктуры с исключениями RS (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

ВНДК терминология

  • Модули относятся к общим библиотекам или исполняемым файлам .
  • Процессы - это задачи операционной системы, порожденные из исполняемых файлов .
  • Framework -qualified термины относятся к понятиям , связанным с системным разделом.
  • Термины, определяемые поставщиком, относятся к понятиям, связанным с разделами поставщика .

Например:

  • Исполняемые файлы платформы ссылаются на исполняемые файлы в /system/bin или /system/xbin .
  • Общие библиотеки Framework ссылаются на общие библиотеки в каталоге /system/lib[64] .
  • Модули фреймворка относятся как к совместно используемым библиотекам, так и к исполняемым файлам фреймворка .
  • Процессы платформы - это процессы, порожденные исполняемыми /system/bin/app_process платформы (например, /system/bin/app_process ).
  • Исполняемые файлы поставщика относятся к исполняемым файлам в /vendor/bin
  • Общие библиотеки поставщиков - это общие библиотеки в каталоге /vendor/lib[64] .
  • Модули поставщика относятся как к исполняемым файлам поставщика, так и к общим библиотекам поставщика .
  • Процессы поставщика - это процессы, порожденные из исполняемых файлов поставщика (например,
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

VNDK версиями

В Android 9 разделяемые библиотеки VNDK имеют версии:

  • ro.vndk.version свойство ro.vndk.version автоматически добавляется в /vendor/default.prop .
  • Общие библиотеки VNDK устанавливаются в /system/lib[64]/vndk-${ro.vndk.version} .
  • Общие библиотеки VNDK-SP устанавливаются в /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Файл конфигурации динамического компоновщика устанавливается в /system/etc/ld.config.${ro.vndk.version}.txt .

Значение ro.vndk.version выбирается по алгоритму ниже:

  • Если BOARD_VNDK_VERSION не равно current , используйте BOARD_VNDK_VERSION .
  • Если BOARD_VNDK_VERSION равно current :
    • Если PLATFORM_VERSION_CODENAME имеет значение REL , используйте PLATFORM_SDK_VERSION (например, 28 ).
    • В противном случае используйте PLATFORM_VERSION_CODENAME (например, P ).

Обновление устройств

Если устройство Android 8.x отключило принудительное применение VNDK во время BOARD_VNDK_VERSION без BOARD_VNDK_VERSION , оно может добавить PRODUCT_USE_VNDK_OVERRIDE := false в BoardConfig.mk при обновлении до Android 9.

Если PRODUCT_USE_VNDK_OVERRIDE имеет значение false , свойство ro.vndk.lite будет автоматически добавлено в /vendor/default.prop а его значение будет равно true . Следовательно, динамический компоновщик загрузит конфигурацию пространства имен компоновщика из /system/etc/ld.config.vndk_lite.txt , которая изолирует только SP-HAL и VNDK-SP.

Чтобы обновить устройство Android 7.0 или ниже до Android 9, добавьте PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false в BoardConfig.mk .

Vendor Test Suite (VTS)

Android 9 Vendor Test Suite (VTS) требует ro.vndk.version свойства ro.vndk.version . И недавно запущенные устройства, и устройства для обновления должны определять ro.vndk.version . Некоторые тестовые случаи VNDK (например, VtsVndkFilesTest и VtsVndkDependencyTest ) используют свойство ro.vndk.version для загрузки соответствующих подходящих наборов данных библиотек VNDK.

Если свойство ro.product.first_api_level больше 27, свойство ro.vndk.lite не должно определяться. VtsTreblePlatformVersionTest завершится ошибкой, если ro.vndk.lite определен на недавно выпущенном устройстве Android 9.

История документа

В этом разделе отслеживаются изменения в документации VNDK.

Android 9 изменений

  • Добавить раздел версий VNDK.
  • Добавьте раздел VTS.
  • Некоторые категории VNDK были переименованы:
    • LL-NDK-Indirect был переименован в LL-NDK-Private.
    • VNDK-Indirect был переименован в VNDK-Private.
    • VNDK-SP-Indirect-Private переименован в VNDK-SP-Private.
    • VNDK-SP-Indirect был удален.

Android 8.1 изменения

  • Библиотеки SP-NDK были объединены в библиотеки LL-NDK.
  • Замените libui.so на libft2.so в разделе пространства имен RS. Было ошибкой включить libui.so .
  • Добавьте libGLESv3.so и libandroid_net.so в библиотеки LL-NDK.
  • Добавьте libion.so в библиотеки VNDK-SP.
  • Удалите libstdc++.so So из библиотек LL-NDK. Используйте вместо этого libc++.so . Некоторые версии автономных -lstdc++ инструментов могут добавлять -lstdc++ к флагам компоновщика по умолчанию. Чтобы отключить настройки по умолчанию, добавьте -nodefaultlibs -lc -lm -ldl в LDFLAGS .
  • Переместите libz.so из LL-NDK в библиотеки VNDK-SP. В некоторых конфигурациях libz.so может оставаться LL-NDK. Однако не должно быть заметных различий.