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

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

Устаревание

Vendor NDK был представлен в Android 8.0 для обеспечения API между платформой и кодом поставщика. Хотя ВНДК успешно используется уже много лет, у него есть некоторые недостатки:
  • Хранилище
    • Один VNDK APEX упаковывает все библиотеки VNDK, независимо от того, используются они на устройстве или нет.
    • GSI содержит несколько версий VNDK APEX для поддержки нескольких версий образов поставщиков.
  • Обновляемость
    • Обновление VNDK APEX отдельно от обновления платформы затруднительно.
    • Образы поставщиков часто обновляются по беспроводной сети (OTA), что снижает преимущества упаковки VNDK в образ системы.
Из-за этих проблем мы решили прекратить поддержку VNDK, начиная с Android 15.

Подробности об прекращении поддержки VNDK

Все библиотеки VNDK упакованы в VNDK APEX и установлены в образ системы (-ext). После прекращения поддержки VNDK бывшие библиотеки VNDK устанавливаются в образ поставщика (или продукта) так же, как и другие библиотеки, доступные поставщику. Эти функции удалены вместе с прекращением поддержки VNDK:
  • ВНДК APEX для Android 15
  • Системные свойства, указывающие версию целевого VNDK, удаляются, если разделы поставщика или продукта созданы для Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Оптимизация VNDK не будет доступна, поскольку VNDK отсутствует:
    • TARGET_VNDK_USING_CORE_VARIANT для устройств Android Go
    • use_vndk_as_stable для APEX поставщиков
  • Снимок поставщика, который сильно зависит от VNDK

Исключения из прекращения поддержки

Эти функции не изменятся после прекращения поддержки VNDK:
  • VNDK APEX с VNDK версии 14 или ниже, необходимые для поддержки существующих образов поставщиков.
  • ЛЛ-НДК не входит в состав ВНДК.

Почему ВНДК?

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.