Diese Seite wurde von der Cloud Translation API übersetzt.

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

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 nur Framework-Updates, bei denen die Systempartition auf die neueste Framework-Version aktualisiert werden kann, während die Herstellerpartition unverändert bleibt. Obwohl die Binärdateien in jeder Partition zu unterschiedlichen Zeitpunkten erstellt wurden, müssen sie miteinander zusammenarbeiten können.

Nur-Framework-Updates beinhalten die folgenden Herausforderungen:

Abhängigkeit zwischen Framework-Modulen und Anbietermodulen . Vor Android 8.0 konnten Module in der Hersteller- und Systempartition miteinander verknüpft werden. Allerdings führten Abhängigkeiten von Anbietermodulen zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
Erweiterungen für 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 einem Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .

Um diese Herausforderungen zu bewältigen, enthält Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL , Hwbinder, Device Tree Overlay und Sepolicy Overlay.

VNDK-spezifische Bedingungen

VNDK-bezogene Dokumente verwenden die folgende Terminologie:

Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder auf ausführbare Dateien. Module machen Abhängigkeiten zur Buildzeit.
Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien hervorgehen. Prozesse erzeugen 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 .
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 ausführbaren Framework-Dateien wie /system/bin/app_process hervorgehen.

Anbieterqualifizierte Begriffe beziehen sich auf vendor :

Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
Gemeinsam genutzte Bibliotheken des Anbieters beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
Anbietermodule beziehen sich sowohl auf ausführbare Dateien des Anbieters als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
Vendor-Prozesse sind Prozesse, die aus ausführbaren Vendor-Dateien hervorgegangen sind, 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 des Anbieters, alle Anbieterprozesse laden nur gemeinsam genutzte Bibliotheken des Anbieters (und einen Teil der gemeinsam genutzten Framework-Bibliotheken) und die Kommunikation zwischen Framework-Prozessen und Anbieterprozessen wird durch HIDL und Hardware gesteuert Bindemittel.

In einer solchen Welt besteht die Möglichkeit, dass stabile, öffentliche APIs aus gemeinsam genutzten Framework-Bibliotheken für Entwickler von Anbietermodulen möglicherweise nicht ausreichen (obwohl sich APIs zwischen Android-Versionen ändern können), was erfordert, dass einige Teile der gemeinsam genutzten Framework-Bibliotheken für Anbieterprozesse zugänglich sein müssen. Da zudem Leistungsanforderungen zu Kompromissen führen können, müssen einige reaktionszeitkritische HALs unterschiedlich behandelt werden.

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

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

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

Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Framework-Bibliotheken . Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet außerdem mehrere Probleme beim doppelten Laden. Allerdings sind die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
Kopieren Sie alte gemeinsam genutzte Framework-Bibliotheken . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, definiert als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzter Speicher, gemeinsam genutzte Dateien 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 zu Problemen führen. 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 unterschiedlich interpretieren.

Abhängig von den Eigenschaften der gemeinsam genutzten Bibliotheken werden unterschiedliche Ansätze verwendet. Daher werden gemeinsam genutzte Framework-Bibliotheken in drei Unterkategorien eingeteilt:

LL-NDK-Bibliotheken sind Framework-Shared-Bibliotheken , die als stabil gelten. Ihre Entwickler sind bestrebt, die Stabilität ihrer API/ABI 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 Anbietermodule 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 gibt keine spezielle Softwarelizenz, die rechtliche Überprüfungen erfordert.
- Der Codeeigentümer hat keine Einwände gegen die Verwendung durch Anbieter.
Nur-Framework-Bibliotheken (FWK-ONLY) sind gemeinsam genutzte Framework-Bibliotheken , die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
- Werden als interne Implementierungsdetails des Frameworks betrachtet.
- Der Zugriff durch Herstellermodule ist nicht gestattet.
- Sie verfügen über instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien.
- Werden nicht kopiert.

Gleichprozess-HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) ist ein Satz vorgegebener HALs, die als gemeinsam genutzte Vendor Libraries implementiert und in Framework Processes 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 berechtigter 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 auch vndk: {private:true} angegeben ist, heißen diese Bibliotheken VNDK-SP-Private und sind für SP-HALS unsichtbar.

Bei den folgenden handelt es sich um reine Framework-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS) :

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

VNDK-Versionierung

Die gemeinsam genutzten VNDK-Bibliotheken sind versioniert:

Die Systemeigenschaft ro.vndk.version wird automatisch zu /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 in /apex/com.android.vndk.v${ro.vndk.version} gemountet.

Der Wert von ro.vndk.version wird durch den 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 Eigenschaft. 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 Datensätze der VNDK-Bibliotheken zu laden.

Warum VNDK?

Nur-Framework-Updates beinhalten die folgenden Herausforderungen:

Abhängigkeit zwischen Framework-Modulen und Anbietermodulen . Vor Android 8.0 konnten Module in der Hersteller- und Systempartition miteinander verknüpft werden. Allerdings führten Abhängigkeiten von Anbietermodulen zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
Erweiterungen für 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 einem Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .

Um diese Herausforderungen zu bewältigen, enthält Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL , Hwbinder, Device Tree Overlay und Sepolicy Overlay.

VNDK-spezifische Bedingungen

VNDK-bezogene Dokumente verwenden die folgende Terminologie:

Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder auf ausführbare Dateien. Module machen Abhängigkeiten zur Buildzeit.
Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien hervorgehen. Prozesse erzeugen 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 .
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 ausführbaren Framework-Dateien wie /system/bin/app_process hervorgehen.

Anbieterqualifizierte Begriffe beziehen sich auf vendor :

Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
Gemeinsam genutzte Bibliotheken des Anbieters beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
Anbietermodule beziehen sich sowohl auf ausführbare Dateien des Anbieters als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
Vendor-Prozesse sind Prozesse, die aus ausführbaren Vendor-Dateien hervorgegangen sind, z. B. /vendor/bin/android.hardware.camera.provider@2.4-service .

VNDK-Konzepte

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

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Framework-Bibliotheken . Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet außerdem mehrere Probleme beim doppelten Laden. Allerdings sind die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
Kopieren Sie alte gemeinsam genutzte Framework-Bibliotheken . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, definiert als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzter Speicher, gemeinsam genutzte Dateien 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 zu Problemen führen. 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 unterschiedlich interpretieren.

LL-NDK-Bibliotheken sind Framework-Shared-Bibliotheken , die als stabil gelten. Ihre Entwickler sind bestrebt, die Stabilität ihrer API/ABI 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 Anbietermodule 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 gibt keine spezielle Softwarelizenz, die rechtliche Überprüfungen erfordert.
- Der Codeeigentümer hat keine Einwände gegen die Verwendung durch Anbieter.
Nur-Framework-Bibliotheken (FWK-ONLY) sind gemeinsam genutzte Framework-Bibliotheken , die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
- Werden als interne Implementierungsdetails des Frameworks betrachtet.
- Der Zugriff durch Herstellermodule ist nicht gestattet.
- Sie verfügen über instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien.
- Werden nicht kopiert.

Gleichprozess-HAL (SP-HAL)

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

Bei den folgenden handelt es sich um reine Framework-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS) :

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

VNDK-Versionierung

Die gemeinsam genutzten VNDK-Bibliotheken sind versioniert:

Die Systemeigenschaft ro.vndk.version wird automatisch zu /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 in /apex/com.android.vndk.v${ro.vndk.version} gemountet.

Der Wert von ro.vndk.version wird durch den 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)

Warum VNDK?

Nur-Framework-Updates beinhalten die folgenden Herausforderungen:

Abhängigkeit zwischen Framework-Modulen und Anbietermodulen . Vor Android 8.0 konnten Module in der Hersteller- und Systempartition miteinander verknüpft werden. Allerdings führten Abhängigkeiten von Anbietermodulen zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
Erweiterungen für 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 einem Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .

Um diese Herausforderungen zu bewältigen, enthält Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL , Hwbinder, Device Tree Overlay und Sepolicy Overlay.

VNDK-spezifische Bedingungen

VNDK-bezogene Dokumente verwenden die folgende Terminologie:

Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder auf ausführbare Dateien. Module machen Abhängigkeiten zur Buildzeit.
Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien hervorgehen. Prozesse erzeugen 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 .
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 ausführbaren Framework-Dateien wie /system/bin/app_process hervorgehen.

Anbieterqualifizierte Begriffe beziehen sich auf vendor :

Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
Gemeinsam genutzte Bibliotheken des Anbieters beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
Anbietermodule beziehen sich sowohl auf ausführbare Dateien des Anbieters als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
Vendor-Prozesse sind Prozesse, die aus ausführbaren Vendor-Dateien hervorgegangen sind, z. B. /vendor/bin/android.hardware.camera.provider@2.4-service .

VNDK-Konzepte

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

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Framework-Bibliotheken . Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet außerdem mehrere Probleme beim doppelten Laden. Allerdings sind die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
Kopieren Sie alte gemeinsam genutzte Framework-Bibliotheken . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, definiert als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzter Speicher, gemeinsam genutzte Dateien 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 zu Problemen führen. 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.

LL-NDK-Bibliotheken sind Framework-Shared-Bibliotheken , die als stabil gelten. Ihre Entwickler sind bestrebt, die Stabilität ihrer API/ABI 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 Anbietermodule 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 gibt keine spezielle Softwarelizenz, die rechtliche Überprüfungen erfordert.
- Der Codeeigentümer hat keine Einwände gegen die Verwendung durch Anbieter.
Nur-Framework-Bibliotheken (FWK-ONLY) sind gemeinsam genutzte Framework-Bibliotheken , die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
- Werden als interne Implementierungsdetails des Frameworks betrachtet.
- Der Zugriff durch Herstellermodule ist nicht gestattet.
- Sie verfügen über instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien.
- Werden nicht kopiert.

Gleichprozess-HAL (SP-HAL)

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

Bei den folgenden handelt es sich um reine Framework-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS) :

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

VNDK-Versionierung

Die gemeinsam genutzten VNDK-Bibliotheken sind versioniert:

Die Systemeigenschaft ro.vndk.version wird automatisch zu /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 in /apex/com.android.vndk.v${ro.vndk.version} gemountet.

Der Wert von ro.vndk.version wird durch den 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)

Warum VNDK?

Nur-Framework-Updates beinhalten die folgenden Herausforderungen:

Abhängigkeit zwischen Framework-Modulen und Anbietermodulen . Vor Android 8.0 konnten Module in der Hersteller- und Systempartition miteinander verknüpft werden. Allerdings führten Abhängigkeiten von Anbietermodulen zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
Erweiterungen für 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 einem Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .

Um diese Herausforderungen zu bewältigen, enthält Android mehrere Funktionen wie VNDK (in diesem Abschnitt beschrieben), HIDL , Hwbinder, Device Tree Overlay und Sepolicy Overlay.

VNDK-spezifische Bedingungen

VNDK-bezogene Dokumente verwenden die folgende Terminologie:

Module beziehen sich entweder auf gemeinsam genutzte Bibliotheken oder auf ausführbare Dateien. Module machen Abhängigkeiten zur Buildzeit.
Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien hervorgehen. Prozesse erzeugen 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 .
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 ausführbaren Framework-Dateien wie /system/bin/app_process hervorgehen.

Anbieterqualifizierte Begriffe beziehen sich auf vendor :

Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
Gemeinsam genutzte Bibliotheken des Anbieters beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
Anbietermodule beziehen sich sowohl auf ausführbare Dateien des Anbieters als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
Vendor-Prozesse sind Prozesse, die aus ausführbaren Vendor-Dateien hervorgegangen sind, z. B. /vendor/bin/android.hardware.camera.provider@2.4-service .

VNDK-Konzepte

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

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Framework-Bibliotheken . Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet außerdem mehrere Probleme beim doppelten Laden. Allerdings sind die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
Kopieren Sie alte gemeinsam genutzte Framework-Bibliotheken . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, definiert als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzter Speicher, gemeinsam genutzte Dateien 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 zu Problemen führen. 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 unterschiedlich interpretieren.

LL-NDK-Bibliotheken sind Framework-Shared-Bibliotheken , die als stabil gelten. Ihre Entwickler sind bestrebt, die Stabilität ihrer API/ABI 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 Anbietermodule können mit ihren eigenen Kopien verknüpft werden. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
- It does not send/receive IPCs to/from the framework.
- It is not related to ART virtual machine.
- It does not read/write files/partitions with unstable file formats.
- It does not have special software license which requires legal reviews.
- Its code owner does not have objections to vendor usages.
Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
- Are considered framework internal implementation details.
- Must not be accessed by vendor modules.
- Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
- Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved 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 libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

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

VNDK versioning

VNDK shared libraries are versioned:

The ro.vndk.version system property is automatically added to /vendor/default.prop .
VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
If BOARD_VNDK_VERSION is equal to current :

If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.