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

Однопроцессный HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) — это набор предопределенных HAL, реализованных как Vendor Shared Libraries и загруженных в 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. Если также указано 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.