Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Комплект для собственной разработки от поставщика (VNDK)

Комплект Vendor Native Development Kit (VNDK) - это набор библиотек, предназначенный исключительно для поставщиков для реализации своих HAL. VNDK поставляется в system.img и динамически связан с кодом поставщика во время выполнения.

Почему ВНДК?

Android 8.0 и выше позволяет обновлять только платформу, в которой системный раздел может быть обновлен до последней версии, а разделы поставщика остаются без изменений. Это означает, что двоичные файлы, созданные в разное время, должны уметь работать друг с другом; VNDK охватывает изменения API / ABI в выпусках Android.

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

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

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

Ресурсы VNDK

Этот раздел включает следующие ресурсы VNDK:

  • В концепциях VNDK (ниже) описаны общие библиотеки инфраструктуры, HAL одного процесса (SP-HAL) и терминология VNDK.
  • Расширения VNDK классифицируют изменения, относящиеся к конкретным поставщикам, по категориям. Например, библиотеки с расширенными функциями, от которых зависят модули поставщиков, должны быть скопированы в раздел поставщика, но изменения, несовместимые с ABI, запрещены.
  • VNDK Build System Support описывает конфигурации системы сборки и синтаксисы определения модулей, которые связаны с VNDK.
  • Инструмент VNDK Definition Tool помогает перенести дерево исходного кода на Android 8.0 и выше.
  • Linker Namespace обеспечивает детальный контроль над связями разделяемых библиотек.
  • Каталоги, правила и отдельная политика определяют структуру каталогов для устройств под управлением Android 8.0 и выше, правила VNDK и связанную с ними политику.
  • Презентация VNDK Design иллюстрирует основные концепции VDNK, используемые в Android 8.0 и выше.

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

В идеальном мире 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) - это общие библиотеки фреймворка , не принадлежащие к упомянутым выше категориям. Эти библиотеки:
    • Рассмотрены детали внутренней реализации фреймворка.
    • Модули поставщика не должны иметь к ним доступ.
    • Иметь нестабильные интерфейсы 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

Библиотеки VNDK-SP указывают vndk: { support_system_process: true } в своих файлах Android.bp. Если также указано vendor_available: false , то эти библиотеки называются VNDK-SP-Private и невидимы для SP-HALS .

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

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

Терминология ВНДК

  • Модули относятся либо к общим библиотекам, либо к исполняемым файлам .
  • Процессы - это задачи операционной системы, порожденные исполняемыми файлами .
  • Термины, определенные в рамках платформы, относятся к концепциям, связанным с системным разделом.
  • Термины, определяемые поставщиком, относятся к концепциям, связанным с разделами поставщика .

Например:

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

Управление версиями VNDK

В Android 9 разделяемые библиотеки VNDK имеют версии:

  • ro.vndk.version свойство ro.vndk.version автоматически добавляется в /vendor/default.prop .
  • Совместно используемые библиотеки VNDK устанавливаются в /system/lib[64]/vndk-${ro.vndk.version} .
  • Совместно используемые библиотеки VNDK-SP устанавливаются в /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Файл конфигурации динамического компоновщика устанавливается в /system/etc/ld.config.${ro.vndk.version}.txt .

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

Обновление устройств

Если устройство Android 8.x отключило принудительное использование VNDK во время выполнения, будучи созданным без BOARD_VNDK_VERSION , оно может добавить PRODUCT_USE_VNDK_OVERRIDE := false в BoardConfig.mk при обновлении до Android 9.

Если PRODUCT_USE_VNDK_OVERRIDE имеет значение false , свойство ro.vndk.lite будет автоматически добавлено в /vendor/default.prop и его значение будет true . Следовательно, динамический компоновщик загрузит конфигурацию пространства имен компоновщика из /system/etc/ld.config.vndk_lite.txt , который изолирует только SP-HAL и VNDK-SP.

Чтобы обновить устройство Android 7.0 или более BoardConfig.mk версии до Android 9, добавьте PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false в BoardConfig.mk .

Комплект для тестирования поставщиков (VTS)

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

Если свойство ro.product.first_api_level больше 27, свойство ro.vndk.lite определять нельзя. VtsTreblePlatformVersionTest завершится ошибкой, если ro.vndk.lite определен в недавно выпущенном устройстве Android 9.

История документа

В этом разделе отслеживаются изменения в документации VNDK.

Изменения в Android 9

  • Добавить раздел управления версиями VNDK.
  • Добавить раздел VTS.
  • Некоторые категории VNDK были переименованы:
    • LL-NDK-Indirect был переименован в LL-NDK-Private.
    • VNDK-Indirect был переименован в VNDK-Private.
    • VNDK-SP-Indirect-Private был переименован в VNDK-SP-Private.
    • VNDK-SP-Indirect был удален.

Изменения в Android 8.1

  • Библиотеки SP-NDK были объединены в библиотеки LL-NDK.
  • Замените libui.so на libft2.so в разделе пространства имен RS. При включении libui.so произошла ошибка.
  • Добавьте libGLESv3.so и libandroid_net.so в библиотеки LL-NDK.
  • Добавьте libion.so в библиотеки VNDK-SP.
  • Удалите libstdc++.so So из библиотек LL-NDK. Вместо этого используйте libc++.so So. Некоторые версии автономных -lstdc++ инструментов могут добавлять -lstdc++ к флагам компоновщика по умолчанию. Чтобы отключить значения по умолчанию, добавьте -nodefaultlibs -lc -lm -ldl в LDFLAGS .
  • Переместите libz.so из LL-NDK в библиотеки VNDK-SP. В некоторых конфигурациях libz.so может оставаться LL-NDK. Однако заметных различий быть не должно.