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

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

Устаревание

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

Подробная информация об отмене VNDK

Все библиотеки VNDK упакованы в VNDK APEX и установлены в образ системы (-ext). С прекращением поддержки VNDK старые библиотеки 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 или ниже, которые требуются для поддержки существующих образов поставщиков.
  • LL-NDK не является частью VNDK.

Почему ВНДК?

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

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

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

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

Специфические термины VNDK

В документах, связанных с VNDK, используется следующая терминология:
  • Модули относятся либо к общим библиотекам, либо к исполняемым файлам. Модули создают зависимости во время сборки.
  • Процессы — это задачи операционной системы, создаваемые исполняемыми файлами. Процессы создают зависимости во время выполнения.
  • Термины, квалифицированные фреймворком , относятся к system разделу:
    • Исполняемые файлы фреймворка относятся к исполняемым файлам в /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).

Общие библиотеки фреймворка для поставщика

В этом разделе описываются критерии классификации общих библиотек, доступных процессам вендора. Существует два подхода к поддержке модулей вендора в разных версиях 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) — это общие библиотеки фреймворка , которые можно безопасно копировать дважды. Модули фреймворка и модули поставщика могут компоноваться со своими копиями. Общая библиотека фреймворка может стать допустимой библиотекой 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 (Renderscript)
  • libmediandk.so (Renderscript)

Версионирование VNDK

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

  • Системное свойство ro.vndk.version автоматически добавляется в /vendor/default.prop .
  • Общие библиотеки VNDK и VNDK-SP устанавливаются как VNDK apex 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.