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 Anbieter-NDK wurde in Android 8.0 eingeführt, um APIs zwischen dem Framework und dem Anbietercode bereitzustellen. VNDK wird zwar seit vielen Jahren erfolgreich eingesetzt, hat aber einige Nachteile:
  • Speicher
    • Ein einzelnes VNDK-APEX-Paket enthält alle VNDK-Bibliotheken, unabhängig davon, ob sie auf dem Gerät verwendet werden oder nicht.
    • GSI enthält mehrere Versionen von VNDK-APEXes, um mehrere Versionen von Anbieter-Images zu unterstützen.
  • Aktualisierbarkeit
    • Es ist schwierig, VNDK APEXes unabhängig vom Plattformupdate zu aktualisieren.
    • Die Images von Anbietern werden häufig over-the-air (OTA) aktualisiert, was die Vorteile der Verpackung von VNDK im System-Image mindert.
Aufgrund dieser Probleme haben wir beschlossen, VNDK ab Android 15 einzustellen.

Details zur Einstellung von VNDK

Alle VNDK-Bibliotheken werden in der VNDK-APEX verpackt und im System-Image (-ext) installiert. Da VNDK eingestellt wird, werden ehemalige VNDK-Bibliotheken wie andere vom Anbieter verfügbare Bibliotheken im Anbieter- oder Produkt-Image installiert. Diese Funktionen werden zusammen mit der Einstellung von VNDK entfernt:
  • VNDK APEX für Android 15
  • Systemeigenschaften, 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 es kein VNDK gibt:
    • TARGET_VNDK_USING_CORE_VARIANT für Android Go-Geräte
    • use_vndk_as_stable für Anbieter-APEXes
  • Anbieter-Snapshot, der stark vom VNDK abhängt

Ausnahmen von der Einstellung

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

Warum VNDK?

AOSP ermöglicht Updates nur für das Framework, bei denen die Systempartition auf die neueste Frameworkversion umgestellt werden kann, während die Anbieterpartition unverändert bleibt. Obwohl sie zu unterschiedlichen Zeiten erstellt werden, müssen die Binärdateien in jeder Partition miteinander kompatibel sein.

Aktualisierungen, die sich nur auf das Framework beziehen, bergen folgende Herausforderungen:

  • 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 führten jedoch zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
  • Erweiterungen für AOSP-Bibliotheken Android erfordert, dass alle Android-Geräte den CTS bestehen, wenn die Systempartition durch ein standardmäßiges generisches System-Image (GSI) ersetzt wird. Da Anbieter jedoch AOSP-Bibliotheken erweitern, um die Leistung zu steigern oder zusätzliche Funktionen für ihre HIDL-Implementierungen hinzuzufügen, kann das Flashen der Systempartition mit einer Standard-GSI die HIDL-Implementierung eines Anbieters beeinträchtigen. Richtlinien zur Vermeidung solcher Fehler finden Sie unter VNDK-Erweiterungen.

Zur Bewältigung dieser Herausforderungen bietet Android mehrere Funktionen wie VNDK (wird in diesem Abschnitt beschrieben), HIDL, hwbinder, Gerätestruktur-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 ausführbare Dateien. Module führen zu Abhängigkeiten bei der Buildzeit.
  • Prozesse sind Betriebssystemaufgaben, die von ausführbaren Dateien gestartet werden. Prozesse verursachen Laufzeitabhängigkeiten.
  • Für Framework qualifizierte Begriffe, die sich auf die Partition system beziehen:
    • Framework-Ausführbare sind ausführbare Dateien in /system/bin oder /system/xbin.
    • Gemeinsam genutzte Frameworks-Bibliotheken sind gemeinsam genutzte Bibliotheken unter /system/lib[64].
    • Framework-Module beziehen sich sowohl auf freigegebene Framework-Bibliotheken als auch auf Framework-Ausführbare Dateien.
    • Framework-Prozesse sind Prozesse, die von Framework-Ausführprogrammen wie /system/bin/app_process gestartet werden.
  • Von Anbietern qualifizierte Begriffe, die sich auf vendor-Partitionen beziehen:
    • Ausführbare Dateien von Anbietern sind ausführbare Dateien in /vendor/bin
    • Gemeinsam genutzte Bibliotheken von Anbietern sind gemeinsam genutzte Bibliotheken unter /vendor/lib[64].
    • Anbietermodule beziehen sich sowohl auf ausführbare Dateien als auch auf freigegebene Bibliotheken von Anbietern.
    • Anbieterprozesse sind Prozesse, die von Anbieter-Ausführprogrammen wie /vendor/bin/android.hardware.camera.provider@2.4-service gestartet werden.

VNDK-Konzepte

In einer idealen Welt mit Android 8.0 und höher werden von Framework-Prozessen keine gemeinsam genutzten Bibliotheken von Anbietern geladen. Alle Anbieterprozesse laden nur gemeinsam genutzte Bibliotheken von Anbietern (und einen Teil der gemeinsam genutzten Framework-Bibliotheken). Die Kommunikation zwischen Framework-Prozessen und Anbieterprozessen wird von HIDL und Hardware-Bindern gesteuert.

In einer solchen Welt besteht die Möglichkeit, dass stabile, öffentliche APIs aus gemeinsam genutzten Framework-Bibliotheken für Entwickler von Anbietermodulen nicht ausreichen (obwohl sich APIs zwischen Android-Releases ä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 HALs mit kritischer Reaktionszeit anders behandelt werden.

In den folgenden Abschnitten wird beschrieben, wie VNDK mit gemeinsam genutzten Framework-Bibliotheken für Anbieter und HALs mit demselben Prozess (Same-Process HALs, SP-HALs) umgeht.

Gemeinsam genutzte Framework-Bibliotheken für den Anbieter

In diesem Abschnitt werden die Kriterien für die Klassifizierung von freigegebenen Bibliotheken beschrieben, auf die Anbieterprozesse zugreifen können. Es gibt zwei Ansätze, Anbietermodule für mehrere Android-Releases zu unterstützen:

  1. Stabilisieren Sie die ABIs/APIs der freigegebenen Bibliotheken des Frameworks. Neue Framework-Module und alte Anbietermodule können dieselbe freigegebene Bibliothek verwenden, um den Arbeitsspeicherbedarf und die Speichergröße zu reduzieren. Außerdem werden durch eine eindeutige freigegebene Bibliothek mehrere Probleme mit doppeltem Laden vermieden. Die Entwicklungskosten für stabile ABIs/APIs sind jedoch hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
  2. Kopiere die alten gemeinsam genutzten Bibliotheken des Frameworks. Es gibt strenge Einschränkungen für Sidechannels, die als alle Mechanismen zur Kommunikation zwischen Framework- und Anbietermodulen definiert sind, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzter Arbeitsspeicher, freigegebene Datei und Systemeigenschaften. Es darf keine Kommunikation geben, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil (z.B. HIDL über hwbinder). Auch das doppelte Laden gemeinsam genutzter Bibliotheken kann zu Problemen führen. 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 Eigenschaften der freigegebenen Bibliotheken werden unterschiedliche Ansätze verwendet. Daher werden gemeinsam genutzte Framework-Bibliotheken in drei Unterkategorien unterteilt:

  • LL-NDK-Bibliotheken sind gemeinsam genutzte Frameworks-Bibliotheken, die als stabil gelten. Die Entwickler verpflichten sich, die Stabilität der API/ABI beizubehalten.
    • 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,
  • Zulässige VNDK-Bibliotheken (VNDK) sind gemeinsam genutzte Framework-Bibliotheken, die 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 zu einer zulässigen VNDK-Bibliothek werden, wenn sie die folgenden Kriterien erfüllt:
    • Es sendet und empfängt keine IPCs an/von dem Framework.
    • Er hat nichts mit der ART-virtuellen Maschine zu tun.
    • Dateien/Partitionen mit instabilen Dateiformaten werden nicht gelesen/geschrieben.
    • Es gibt keine spezielle Softwarelizenz, die rechtliche Prüfungen erfordert.
    • Der Codeinhaber hat keine Einwände gegen die Nutzung durch Anbieter.
  • Nur-Framework-Bibliotheken (FWK-ONLY) sind gemeinsam genutzte Framework-Bibliotheken, die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
    • Sie gelten als interne Implementierungsdetails des Frameworks.
    • Darf nicht von Anbietermodulen aufgerufen werden.
    • Sie haben instabile ABIs/APIs und keine API-/ABI-Kompatibilitätsgarantien.
    • werden nicht kopiert.

HAL mit demselben Prozess (SP-HAL)

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

VNDK-SP ist eine vordefinierte Teilmenge zulässiger 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 auch vndk: {private:true} angegeben ist, werden diese Bibliotheken VNDK-SP-Private genannt und sind für SP-HALS nicht sichtbar.

Die folgenden nur Framework-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS) sind verfügbar:

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

VNDK-Versionierung

VNDK-gemeinsam genutzte Bibliotheken sind versioniert:

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

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).
    • Andernfalls verwenden Sie PLATFORM_VERSION_CODENAME (z.B. P).

Vendor Test Suite (VTS)

Die Android Vendor Test Suite (VTS) erfordert eine nicht leere ro.vndk.version-Property. Sowohl für neu eingeführte Geräte als auch für Geräte, die ein Upgrade erhalten, muss ro.vndk.version definiert sein. Bei einigen VNDK-Tests (z.B. VtsVndkFilesTest und VtsVndkDependencyTest) wird die Property ro.vndk.version verwendet, um die entsprechenden Datensätze der VNDK-Bibliotheken zu laden.