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

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

Амортизация

Vendor NDK был представлен в Android 8.0 для обеспечения API-интерфейсов между фреймворком и кодом стороннего разработчика. Хотя VNDK успешно используется уже много лет, у него есть некоторые недостатки:

• Хранилище
• Один пакет VNDK APEX объединяет все библиотеки VNDK, независимо от того, используются ли они на устройстве или нет.
• GSI содержит несколько версий APEX-файлов VNDK для поддержки различных версий образов от разных производителей.
• Возможность обновления
• Обновить APEX-файлы VNDK отдельно от обновления платформы сложно.
• Образы от поставщиков часто обновляются по беспроводной сети (OTA), что снижает преимущества наличия VNDK, включенного в образ системы.

Исходя из этих проблем, мы решили отказаться от использования VNDK, начиная с Android 15.

Подробности об устаревании VNDK

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

• VNDK APEX для Android 15
• Если разделы поставщика или продукта созданы для Android 15, системные свойства, указывающие на версию целевого VNDK, удаляются:
  • 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.

Почему именно VNDK?

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

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

• Зависимость между модулями фреймворка и модулями поставщика . До Android 8.0 модули в разделах поставщика и системы могли взаимодействовать друг с другом. Однако зависимости от модулей поставщика накладывали нежелательные ограничения на разработку модулей фреймворка.
• Расширения библиотек AOSP . Android требует, чтобы все устройства Android проходили проверку CTS при замене системного раздела стандартным универсальным образом системы (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 обрабатывает разделяемые библиотеки фреймворков для поставщиков и высокоуровневые интерфейсы управления процессами (SP-HAL).

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

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

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

HAL, работающий по единому процессу (SP-HAL)

Same-Process 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

В файлах Android.bp для библиотек VNDK-SP указывается vndk: { support_system_process: true } . Если также указано 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 устанавливаются как apex 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.