Übersicht über das Vendor Native Development Kit (VNDK).

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Warum VNDK?

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

Nur-Framework-Updates umfassen die folgenden Herausforderungen:

  • Abhängigkeit zwischen Framework-Modulen und Herstellermodulen . Vor Android 8.0 konnten Module in der Hersteller- und Systempartition miteinander verknüpft werden. Abhängigkeiten von Herstellermodulen erlegten jedoch der Entwicklung von Framework-Modulen unerwünschte Beschränkungen auf.
  • Erweiterungen der AOSP-Bibliotheken . Android erfordert, dass alle Android-Geräte CTS bestehen, wenn die Systempartition durch ein standardmäßiges Generic 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 beschädigen. Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .

Um diesen Herausforderungen zu begegnen, enthält Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL , hwbinder, Device Tree Overlay und Sepolicy Overlay.

VNDK-spezifische Begriffe

VNDK-bezogene Dokumente verwenden die folgende Terminologie:
  • Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder ausführbare Dateien. Module machen Build-Time-Abhängigkeiten.
  • Prozesse sind Betriebssystemaufgaben, die von ausführbaren Dateien hervorgebracht werden. Prozesse machen Laufzeitabhängigkeiten.
  • Framework -qualifizierte Begriffe beziehen sich auf die system :
    • Ausführbare Framework-Dateien beziehen sich auf ausführbare Dateien in /system/bin oder /system/xbin .
    • Geteilte 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 von ausführbaren Framework-Dateien wie /system/bin/app_process .
  • Anbieterqualifizierte Begriffe beziehen sich auf vendor :
    • Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
    • Gemeinsam genutzte Bibliotheken von Anbietern beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
    • Herstellermodule beziehen sich sowohl auf ausführbare Dateien des Herstellers als auch auf gemeinsam genutzte Bibliotheken des Herstellers.
    • Anbieterprozesse sind Prozesse, die von ausführbaren Anbieterdateien hervorgebracht werden, z. B. /vendor/bin/android.hardware.camera.provider@2.4-service .

VNDK-Konzepte

In einer idealen Welt mit Android 8.0 und höher laden Framework-Prozesse keine gemeinsam genutzten Bibliotheken von Anbietern, alle Anbieterprozesse laden nur gemeinsam genutzte Bibliotheken von Anbietern (und einen Teil von gemeinsam genutzten Framework-Bibliotheken) und die Kommunikation zwischen Framework-Prozessen und Anbieterprozessen wird durch HIDL und Hardware geregelt Bindemittel.

Eine solche Welt beinhaltet die Möglichkeit, dass stabile, öffentliche APIs aus gemeinsam genutzten Framework-Bibliotheken für Anbietermodulentwickler möglicherweise nicht ausreichen (obwohl sich APIs zwischen Android-Releases ändern können), was erfordert, dass ein Teil der gemeinsam genutzten Framework-Bibliotheken für Anbieterprozesse zugänglich ist. Da außerdem Leistungsanforderungen zu Kompromissen führen können, müssen einige reaktionszeitkritische HALs anders behandelt werden.

In den folgenden Abschnitten wird detailliert beschrieben, wie VNDK gemeinsam genutzte Frameworkbibliotheken für Anbieter und Same-Process-HALs (SP-HALs) handhabt.

Framework gemeinsam genutzte Bibliotheken für Anbieter

Dieser Abschnitt beschreibt die Kriterien für die Klassifizierung gemeinsam genutzter Bibliotheken, auf die Anbieterprozesse zugreifen können. Es gibt zwei Ansätze, um Anbietermodule über mehrere Android-Versionen hinweg zu unterstützen:

  1. Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Bibliotheken des Frameworks . Neue Framework-Module und alte Herstellermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet auch mehrere doppelte Ladeprobleme. 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. Kopieren Sie die gemeinsam genutzten Bibliotheken des alten Frameworks . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, die als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Herstellermodulen definiert sind, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzten Speicher, gemeinsam genutzte Datei und Systemeigenschaften. Es darf keine Kommunikation stattfinden, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil (z. B. HIDL über hwbinder). Das doppelte Laden gemeinsam genutzter Bibliotheken kann ebenfalls Probleme verursachen; Wenn beispielsweise ein von der neuen Bibliothek erstelltes Objekt an die Funktionen der alten Bibliothek übergeben wird, kann ein Fehler auftreten, da diese Bibliotheken das Objekt möglicherweise anders interpretieren.

Abhängig von den Merkmalen der gemeinsam genutzten Bibliotheken werden unterschiedliche Ansätze verwendet. Daher werden Framework Shared Libraries in drei Unterkategorien eingeteilt:

  • LL-NDK-Bibliotheken sind gemeinsam genutzte Framework-Bibliotheken , die als stabil bekannt sind. Ihre Entwickler verpflichten sich, ihre API/ABI-Stabilitäten aufrechtzuerhalten.
    • LL-NDK enthält 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 ,
  • Berechtigte VNDK-Bibliotheken (VNDK) sind gemeinsam genutzte Framework-Bibliotheken , die sicher zweimal kopiert werden können. Framework-Module und Herstellermodule können mit ihren eigenen Kopien verknüpft werden. Eine gemeinsam genutzte Framework-Bibliothek kann nur dann eine berechtigte VNDK-Bibliothek werden, wenn sie die folgenden Kriterien erfüllt:
    • Es sendet/empfängt keine IPCs an/von dem Framework.
    • Es hat nichts mit der virtuellen ART-Maschine zu tun.
    • Es liest/schreibt keine Dateien/Partitionen mit instabilen Dateiformaten.
    • Es hat keine spezielle Softwarelizenz, die rechtliche Überprüfungen erfordert.
    • Der Eigentümer des Codes hat keine Einwände gegen die Nutzung durch den Anbieter.
  • Framework-Only Libraries (FWK-ONLY) sind Framework Shared Libraries , die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
    • Als Framework-interne Implementierungsdetails gelten.
    • Darf nicht von Herstellermodulen aufgerufen werden.
    • Instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien haben.
    • Werden nicht kopiert.

Gleicher Prozess-HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) ist ein Satz vorgegebener HALs, die als Vendor Shared Libraries implementiert und in Framework-Prozesse geladen werden. SP-HALs werden durch einen Linker-Namespace isoliert (steuert die Bibliotheken und Symbole, 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 geeigneter VNDK-Bibliotheken. VNDK-SP-Bibliotheken werden sorgfältig überprü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 unsichtbar.

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

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

VNDK-Versionierung

Gemeinsam genutzte VNDK-Bibliotheken sind versioniert:

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

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

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

Anbieter-Test-Suite (VTS)

Die Android Vendor Test Suite (VTS) schreibt eine nicht leere ro.vndk.version -Eigenschaft vor. Sowohl neu gestartete Geräte als auch Upgrade-Geräte müssen ro.vndk.version definieren. Einige VNDK-Testfälle (z. B. VtsVndkFilesTest und VtsVndkDependencyTest ) verlassen sich auf die Eigenschaft ro.vndk.version , um die passenden geeigneten VNDK-Bibliotheken-Datensätze zu laden.