Собственный комплект разработки поставщика (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, когда системный раздел заменяется стандартным универсальным образом системы (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 и выше.
  • Linker Namespace обеспечивает детальный контроль над связями общих библиотек.
  • Каталоги, правила и политика безопасности определяют структуру каталогов для устройств под управлением Android 8.0 и более поздних версий, правила VNDK и соответствующую политику безопасности.
  • Презентация VNDK Design иллюстрирует основные концепции VDNK, используемые в Android 8.0 и выше.

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

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

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

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

Общие библиотеки Framework для поставщика

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

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

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

  • Библиотеки LL-NDK — это общие библиотеки Framework , которые, как известно, стабильны. Их разработчики стремятся поддерживать стабильность 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 , которые можно безопасно копировать дважды. Модули Framework и Vendor Modules могут связываться со своими собственными копиями. Общая библиотека платформы может стать подходящей библиотекой VNDK, только если она удовлетворяет следующим критериям:
    • Он не отправляет/не получает IPC в/из фреймворка.
    • Это не связано с виртуальной машиной ART.
    • Он не читает/записывает файлы/разделы с нестабильными форматами файлов.
    • У него нет специальной лицензии на программное обеспечение, которая требует юридических проверок.
    • Владелец кода не возражает против использования поставщиком.
  • Библиотеки только для платформы (ТОЛЬКО для FWK) — это общие библиотеки платформы , которые не относятся к упомянутым выше категориям. Эти библиотеки:
    • Рассматриваются детали внутренней реализации фреймворка.
    • Не должен быть доступен модулям поставщика.
    • Имеют нестабильные ABI/API и не гарантируют совместимость API/ABI.
    • Не копируются.

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

Same-Process HAL ( SP-HAL ) — это набор предопределенных HAL, реализованных в виде общих библиотек поставщиков и загруженных в Framework Processes . 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 (рендерскрипт)
  • libmediandk.so (рендерскрипт)

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

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

Например:

  • Исполняемые файлы Framework относятся к исполняемым файлам в /system/bin или /system/xbin .
  • Общие библиотеки Framework относятся к общим библиотекам в каталоге /system/lib[64] .
  • Модули Framework относятся как к общим библиотекам Framework, так и к исполняемым файлам Framework .
  • Процессы Framework — это процессы, порожденные исполняемыми файлами Framework (например /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 автоматически добавляется в /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 , оно может добавить 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 .

Набор тестов поставщика (VTS)

Набор тестов поставщиков Android 9 (VTS) требует непустого свойства 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.
  • Добавьте раздел ВТС.
  • Некоторые категории 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 из библиотек LL-NDK. Вместо этого используйте libc++.so . Некоторые версии автономных цепочек инструментов могут добавлять -lstdc++ к флагам компоновщика по умолчанию. Чтобы отключить значения по умолчанию, добавьте -nodefaultlibs -lc -lm -ldl в LDFLAGS .
  • Переместите libz.so из библиотек LL-NDK в библиотеки VNDK-SP. В некоторых конфигурациях libz.so может оставаться LL-NDK. Однако заметных различий быть не должно.