VNDK-Erweiterungen

Hersteller von Android-Geräten ändern den Quellcode von AOSP-Bibliotheken aus verschiedenen Gründen. Einige Anbieter implementieren Funktionen in AOSP-Bibliotheken neu, um die Leistung zu steigern, während andere Anbieter AOSP-Bibliotheken neue Hooks, APIs oder Funktionen hinzufügen. Dieser Abschnitt enthält Richtlinien für die Erweiterung von AOSP-Bibliotheken, die CTS/VTS nicht verletzen.

Plug-and-play-Ersatz

Alle geänderten freigegebenen Bibliotheken müssen binärkompatibel und direkt einsetzbare Ersatzbibliotheken für das AOSP-Äquivalent sein. Alle bestehenden AOSP-Nutzer müssen die geänderte freigegebene Bibliothek ohne Neukompilierung verwenden können. Diese Anforderung impliziert Folgendes:

  • AOSP-Funktionen dürfen nicht entfernt werden.
  • Gebäude dürfen nicht verändert werden, wenn sie für die Nutzer sichtbar sind.
  • Die Voraussetzungen für Funktionen dürfen nicht verschärft werden.
  • Funktionen müssen dieselben Funktionen bieten.
  • Die Nachbedingung von Funktionen darf nicht abgeschwächt werden.

Erweiterte Modulklassifizierungen

Klassifizieren Sie Module nach den Funktionen, die sie definieren und verwenden.

Hinweis: Anstelle von API/ABI wird hier Funktionen verwendet, da Funktionen hinzugefügt werden können, ohne die API/ABI zu ändern.

Je nach den in einem Modul definierten Funktionen können Module in DA-Module und DX-Module unterteilt werden:

  • Defining-only-AOSP Modules (DA-Module) definieren keine neuen Funktionen, die im AOSP-Pendant nicht vorhanden waren.
    • Beispiel 1 Eine intakte, unveränderte AOSP-Bibliothek ist ein DA-Modul.
    • Beispiel 2 Wenn ein Anbieter die Funktionen in libcrypto.so mit SIMD-Anweisungen umschreibt (ohne neue Funktionen hinzuzufügen), ist das geänderte libcrypto.so ein DA-Modul.
  • Definition-Extension-Module (DX-Module) definieren entweder neue Funktionen oder haben kein AOSP-Äquivalent.
    • Beispiel 1 Wenn ein Anbieter libjpeg.so eine Hilfsfunktion hinzufügt, um auf interne Daten zuzugreifen, wird die geänderte libjpeg.so zu einer DX-Lib und die neu hinzugefügte Funktion zum erweiterten Teil der Bibliothek.
    • Beispiel 2 Wenn ein Anbieter eine nicht AOSP-Bibliothek namens libfoo.so definiert, ist libfoo.so eine DX-Lib.

Je nach den von einem Modul verwendeten Funktionen können Module in UA-Module und UX-Module unterteilt werden.

  • Nur-AOSP-Module (UA-Module) verwenden bei ihren Implementierungen nur AOSP-Funktionen. Sie nutzen keine nicht AOSP-Erweiterungen.
    • Beispiel 1 Eine intakte, unveränderte AOSP-Bibliothek ist ein UA-Modul.
    • Beispiel 2 Wenn eine geänderte freigegebene Bibliothek libjpeg.so nur auf anderen AOSP-APIs basiert, handelt es sich um ein UA-Modul.
  • UX-Module (Using-Extension Modules) nutzen bei ihrer Implementierung einige nicht AOSP-Funktionen.
    • Beispiel 1 Wenn eine geänderte libjpeg.so auf einer anderen nicht AOSP-Bibliothek namens libjpeg_turbo2.so basiert, ist die geänderte libjpeg.so ein UX-Modul.
    • Beispiel 2 Wenn ein Anbieter seiner geänderten libexif.so eine neue Funktion hinzufügt und seine geänderte libjpeg.so die neu hinzugefügte Funktion aus libexif.so verwendet, ist seine geänderte libjpeg.so ein UX-Modul.

Definitionen und Verwendungen sind unabhängig voneinander:

Verwendete Funktionen
Nur AOSP (UA) Erweitert (UX)
Definierte Funktionen Nur AOSP (DA) DAUA DAUX
Erweitert (DX) DXUA DXUX

VNDK-Erweiterungsmechanismus

Anbietermodule, die auf erweiterte Funktionen angewiesen sind, funktionieren nicht, da die AOSP-Bibliothek mit demselben Namen keine erweiterten Funktionen bietet. Wenn Anbietermodule direkt oder indirekt von erweiterten Funktionen abhängen, sollten Anbieter die freigegebenen DAUX-, DXUA- und DXUX-Bibliotheken in die Anbieterpartition kopieren. Anbieterprozesse suchen immer zuerst in der Anbieterpartition nach freigegebenen Bibliotheken. LL-NDK-Bibliotheken dürfen jedoch nicht kopiert werden. Anbietermodule dürfen sich also nicht auf die erweiterten Funktionen stützen, die von den geänderten LL-NDK-Bibliotheken definiert werden.

DAUA-Freigabebibliotheken können in der Systempartition verbleiben, wenn die entsprechende AOSP-Bibliothek dieselben Funktionen bietet und Anbietermodule weiterhin funktionieren, wenn die Systempartition durch ein generisches System-Image (GSI) überschrieben wird.

Das Drop-in-Ersetzen ist wichtig, da die nicht geänderten VNDK-Bibliotheken in der GSI bei Namenskollisionen mit den geänderten freigegebenen Bibliotheken verknüpft werden. Wenn die AOSP-Bibliotheken auf eine Weise geändert werden, die nicht mit der API/ABI kompatibel ist, können die AOSP-Bibliotheken in der GSI nicht verknüpft werden oder es kommt zu undefiniertem Verhalten.