Vendor Native Development Kit (VNDK) – Übersicht

Das Vendor Native Development Kit (VNDK) ist eine Reihe von Bibliotheken, die von anderen Bibliotheken oder Binärdateien in der Anbieter- oder Produktpartition zur Laufzeit für dlopen verwendet werden.

Einstellung

Das Vendor NDK wurde in Android 8.0 eingeführt, um APIs zwischen dem Framework und dem Anbietercode bereitzustellen. Das VNDK wird seit vielen Jahren erfolgreich eingesetzt, hat aber einige Nachteile:
  • Speicher
    • Ein einzelnes VNDK APEX enthält alle VNDK-Bibliotheken, unabhängig davon, ob sie vom Gerät verwendet werden oder nicht.
    • Das GSI enthält mehrere Versionen von VNDK APEXes, um mehrere Versionen von Anbieter-Images zu unterstützen.
  • Aktualisierbarkeit
    • Es ist schwierig, VNDK-APEXs getrennt vom Plattform-Update zu aktualisieren.
    • Hersteller-Images werden häufig OTA (Over-the-Air) aktualisiert, was die Vorteile des im System-Image enthaltenen VNDK verringert.
Aufgrund dieser Probleme haben wir beschlossen, VNDK ab Android 15 einzustellen.

Details zur Einstellung von VNDK

Alle VNDK-Bibliotheken werden im VNDK APEX verpackt und im System-Image (-ext) installiert. Mit der Einstellung von VNDK werden ehemalige VNDK-Bibliotheken im Anbieter- oder Produkt-Image installiert, genau wie andere vom Anbieter verfügbare Bibliotheken. Diese Funktionen werden zusammen mit der Einstellung von VNDK entfernt:
  • VNDK APEX für Android 15
  • Systemattribute, die die Version des Ziel-VNDK angeben, werden entfernt, wenn die Anbieter- oder Produktpartitionen für Android 15 erstellt werden:
    • ro.vndk.version
    • ro.product.vndk.version
  • VNDK-Optimierungen sind nicht verfügbar, da kein VNDK vorhanden ist:
    • TARGET_VNDK_USING_CORE_VARIANT für Android Go-Geräte
    • use_vndk_as_stable für Vendor-APEX-Module
  • Anbieter-Snapshot, der stark vom VNDK abhängt

Ausnahmen von der Einstellung

Diese Funktionen ändern sich durch die Einstellung des VNDK nicht:
  • VNDK-APEX-Dateien mit VNDK-Version 14 oder niedriger, die zur Unterstützung vorhandener Anbieter-Images erforderlich sind.
  • Das LL-NDK ist nicht Teil des VNDK.

Warum VNDK?

AOSP ermöglicht reine Framework-Updates, bei denen die Systempartition auf die neueste Framework-Version aktualisiert werden kann, während die Anbieterpartition unverändert bleibt. Obwohl sie zu unterschiedlichen Zeiten erstellt wurden, müssen Binärdateien in jeder Partition miteinander kompatibel sein.

Updates, die nur das Framework betreffen, haben folgende Nachteile:

  • Abhängigkeit zwischen Framework-Modulen und Anbietermodulen: Vor Android 8.0 konnten Module in der Anbieter- und Systempartition miteinander verknüpft werden. Abhängigkeiten von Anbietermodulen haben jedoch unerwünschte Einschränkungen für die Entwicklung von Framework-Modulen mit sich gebracht.
  • Erweiterungen für AOSP-Bibliotheken: Unter Android müssen alle Android-Geräte den CTS bestehen, wenn die Systempartition durch ein standardmäßiges generisches Systemimage (GSI) ersetzt wird. Wenn Anbieter jedoch AOSP-Bibliotheken erweitern, um die Leistung zu steigern oder ihren HIDL-Implementierungen zusätzliche Funktionen hinzuzufügen, kann das Flashen der Systempartition mit einem Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zum Vermeiden solcher Fehler finden Sie unter VNDK-Erweiterungen.

Um diesen Herausforderungen zu begegnen, bietet Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL, hwbinder, Device Tree Overlay und sepolicy-Overlay.

VNDK-spezifische Begriffe

In VNDK-bezogenen Dokumenten wird die folgende Terminologie verwendet:
  • Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder auf ausführbare Dateien. Module stellen Build-Zeit-Abhängigkeiten dar.
  • Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien abgeleitet werden. Prozesse stellen Laufzeitabhängigkeiten her.
  • Framework-qualifizierte Begriffe beziehen sich auf die system-Partition:
    • Framework-Ausführbare Dateien beziehen sich auf ausführbare Dateien in /system/bin oder /system/xbin.
    • Gemeinsam genutzte Framework-Bibliotheken beziehen sich auf gemeinsam genutzte Bibliotheken unter /system/lib[64].
    • Framework-Module beziehen sich sowohl auf gemeinsam genutzte Framework-Bibliotheken als auch auf ausführbare Framework-Dateien.
    • Framework-Prozesse sind Prozesse, die aus Framework-Ausführungsdateien wie /system/bin/app_process abgeleitet werden.
  • Vom Anbieter qualifizierte Begriffe beziehen sich auf vendor-Partitionen:
    • Anbieterausführbare Dateien beziehen sich auf ausführbare Dateien in /vendor/bin.
    • Gemeinsam genutzte Bibliotheken von Anbietern beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64].
    • Anbietermodule beziehen sich sowohl auf ausführbare Dateien als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
    • Anbieterprozesse sind Prozesse, die von ausführbaren Anbieterdateien wie /vendor/bin/android.hardware.camera.provider@2.4-service abgeleitet werden.

VNDK-Konzepte

Im Idealfall unter Android 8.0 und höher werden in Framework-Prozessen keine gemeinsam genutzten Anbieterbibliotheken geladen, in allen Anbieterprozessen werden nur gemeinsam genutzte Anbieterbibliotheken (und ein Teil der gemeinsam genutzten Framework-Bibliotheken) geladen und die Kommunikation zwischen Framework-Prozessen und Anbieterprozessen wird durch HIDL und Hardware-Binder geregelt.

In einer solchen Welt ist es möglich, dass stabile, öffentliche APIs aus gemeinsam genutzten Framework-Bibliotheken für Entwickler von Anbietermodulen nicht ausreichen (obwohl sich APIs zwischen Android-Versionen ändern können). Daher muss ein Teil der gemeinsam genutzten Framework-Bibliotheken für Anbieterprozesse zugänglich sein. Da Leistungsanforderungen zu Kompromissen führen können, müssen einige zeitkritische HALs anders behandelt werden.

In den folgenden Abschnitten wird beschrieben, wie das VNDK Framework-Bibliotheken für Anbieter und SP-HALs (Same-Process HALs) verarbeitet.

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

In diesem Abschnitt werden die Kriterien für die Klassifizierung freigegebener Bibliotheken beschrieben, auf die Anbieterprozesse zugreifen können. Es gibt zwei Ansätze zur Unterstützung von Anbietermodulen in mehreren Android-Versionen:

  1. ABIs/APIs der Framework-Bibliotheken stabilisieren: Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine eindeutige gemeinsam genutzte Bibliothek vermeidet auch mehrere Probleme mit dem doppelten Laden. Die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs sind jedoch hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
  2. Alte gemeinsam genutzte Framework-Bibliotheken kopieren Es gibt eine strenge Einschränkung für Side-Channels, die als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen definiert sind, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, Shared Memory, Shared File und Systemeigenschaften. Es darf keine Kommunikation stattfinden, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil (z.B. HIDL über hwbinder). Das doppelte Laden von gemeinsam genutzten Bibliotheken kann ebenfalls Probleme verursachen. Wenn beispielsweise ein Objekt, das von der neuen Bibliothek erstellt wurde, an die Funktionen der alten Bibliothek übergeben wird, kann ein Fehler auftreten, da diese Bibliotheken das Objekt möglicherweise unterschiedlich interpretieren.

Je nach den Merkmalen der freigegebenen Bibliotheken werden unterschiedliche Ansätze verwendet. Daher werden Framework-Bibliotheken in drei Unterkategorien eingeteilt:

  • LL-NDK-Bibliotheken sind gemeinsam genutzte Framework-Bibliotheken, die als stabil gelten. Die Entwickler des Unternehmens sind bestrebt, die API-/ABI-Stabilität aufrechtzuerhalten.
    • Das LL-NDK umfasst die folgenden Bibliotheken: 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 und libvulkan.so.
  • Geeignete VNDK-Bibliotheken (VNDK) sind gemeinsam genutzte Framework-Bibliotheken, die sicher zweimal kopiert werden können. Framework-Module und Anbietermodule können mit ihren eigenen Kopien verknüpft werden. Eine gemeinsam genutzte Framework-Bibliothek kann nur dann eine infrage kommende VNDK-Bibliothek werden, wenn sie die folgenden Kriterien erfüllt:
    • Es werden keine IPCs an das Framework gesendet oder von diesem empfangen.
    • Es hat nichts mit der ART-VM zu tun.
    • Es werden keine Dateien/Partitionen mit instabilen Dateiformaten gelesen/geschrieben.
    • Es ist keine spezielle Softwarelizenz erforderlich, die rechtliche Prüfungen erfordert.
    • Der Codeinhaber hat keine Einwände gegen die Verwendung durch Anbieter.
  • Framework-Only-Bibliotheken (FWK-ONLY) sind Framework Shared Libraries, die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
    • Sie gelten als interne Implementierungsdetails des Frameworks.
    • Darf nicht von Anbietermodulen aufgerufen werden.
    • Instabile ABIs/APIs und keine API-/ABI-Kompatibilitätsgarantien.
    • Sie werden nicht kopiert.

Same-Process-HAL (SP-HAL)

Ein Same-Process-HAL (SP-HAL) ist eine Reihe von vordefinierten HALs, die als Vendor Shared Libraries implementiert und in Framework Processes geladen werden. SP-HALs werden durch einen Linker-Namespace isoliert, der die Bibliotheken und Symbole steuert, die für die gemeinsam genutzten Bibliotheken sichtbar sind. SP-HALs dürfen nur von LL-NDK und VNDK-SP abhängen.

VNDK-SP ist eine vordefinierte Teilmenge der infrage kommenden VNDK-Bibliotheken. VNDK-SP-Bibliotheken werden sorgfältig geprüft, um sicherzustellen, dass das doppelte Laden von VNDK-SP-Bibliotheken in Framework-Prozesse keine Probleme verursacht. Sowohl SP-HALs als auch VNDK-SPs werden von Google definiert.

Die folgenden Bibliotheken sind zugelassene SP‑HALs:

  • 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-Bibliotheken geben vndk: { support_system_process: true } in ihren Android.bp-Dateien an. Wenn vndk: {private:true} ebenfalls angegeben ist, werden diese Bibliotheken als VNDK-SP-Private bezeichnet und sind für SP-HALS nicht sichtbar.

Die folgenden Bibliotheken sind Framework-only-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS):

  • libft2.so (RenderScript)
  • libmediandk.so (RenderScript)

VNDK-Versionsverwaltung

VNDK-Bibliotheken sind versioniert:

  • Die Systemeigenschaft ro.vndk.version wird automatisch zu /vendor/default.prop hinzugefügt.
  • VNDK- und VNDK-SP-Bibliotheken werden als VNDK-Apex com.android.vndk.v${ro.vndk.version} installiert und in /apex/com.android.vndk.v${ro.vndk.version} eingebunden.

Der Wert von ro.vndk.version wird vom folgenden Algorithmus ausgewählt:

  • Wenn BOARD_VNDK_VERSION nicht gleich current ist, verwenden Sie BOARD_VNDK_VERSION.
  • Wenn BOARD_VNDK_VERSION gleich current ist:
    • Wenn PLATFORM_VERSION_CODENAME REL ist, verwenden Sie PLATFORM_SDK_VERSION (z.B. 28).
    • Verwenden Sie andernfalls PLATFORM_VERSION_CODENAME (z.B. P).

Vendor Test Suite (VTS)

Die Android Vendor Test Suite (VTS) erfordert eine nicht leere ro.vndk.version-Eigenschaft. Sowohl neu eingeführte Geräte als auch Geräte, die aktualisiert werden, müssen ro.vndk.version definieren. Einige VNDK-Testläufe (z.B. VtsVndkFilesTest und VtsVndkDependencyTest) basieren auf der Property ro.vndk.version, um die entsprechenden infrage kommenden VNDK-Bibliotheksdatensätze zu laden.