Обзор Vendor Native Development Kit (VNDK)

Vendor Native Development Kit (VNDK) — это набор библиотек, используемых другими библиотеками или двоичными файлами в разделе поставщика или продукта во время выполнения dlopen.

Почему ВНДК?

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

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

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

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

Специальные условия ВНДК

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

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

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

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

HAL одного и того же процесса ( SP-HAL ) — это набор заранее определенных HAL, реализованных как общие библиотеки поставщиков и загруженных в процессы платформы . 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. Если также указан vndk: {private:true} , то эти библиотеки называются VNDK-SP-Private и они невидимы для SP-HALS.

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

  • libft2.so (рендерскрипт)
  • libmediandk.so (рендерскрипт)

Управление версиями ВНДК

Общие библиотеки VNDK имеют версии:

  • Системное свойство ro.vndk.version автоматически добавляется в /vendor/default.prop .
  • Общие библиотеки VNDK и VNDK-SP устанавливаются как вершина VNDK com.android.vndk.v${ro.vndk.version} и монтируются в /apex/com.android.vndk.v${ro.vndk.version} .

Значение 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 ).

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

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