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 neue Hooks, neue APIs oder neue Funktionalitäten zu AOSP-Bibliotheken hinzufügen. Dieser Abschnitt enthält Richtlinien zum Erweitern von AOSP-Bibliotheken auf eine Weise, die CTS/VTS nicht unterbricht.

Drop-In-Ersatz

Alle modifizierten gemeinsam genutzten Bibliotheken müssen binärkompatible Drop-in-Ersetzungen ihres AOSP-Gegenstücks sein. Alle vorhandenen AOSP-Benutzer müssen in der Lage sein, die geänderte gemeinsam genutzte Bibliothek ohne Neukompilierung zu verwenden. Diese Anforderung impliziert Folgendes:

• AOSP-Funktionen dürfen nicht entfernt werden.
• Strukturen dürfen nicht verändert werden, wenn solche Strukturen ihren Benutzern ausgesetzt sind.
• Voraussetzung von Funktionen muss nicht verstärkt werden.
• Funktionen müssen gleichwertige Funktionalitäten bereitstellen.
• Die Nachbedingung von Funktionen darf nicht abgeschwächt werden.

Erweiterte Modulklassifizierungen

Klassifizieren Sie Module nach den Funktionalitäten, die sie definieren und verwenden .

Hinweis : Funktionalitäten werden hier anstelle von API/ABI verwendet, da es möglich ist, Funktionalität hinzuzufügen, ohne API/ABI zu ändern.

Abhängig von den in einem Modul definierten Funktionalitäten können Module in DA-Module und DX-Module eingeteilt werden:

• Defining-only-AOSP-Module (DA-Module) definieren keine neuen Funktionalitäten, die nicht im AOSP-Gegenstück vorhanden waren.
  • Beispiel 1. Eine intakte unmodifizierte 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), dann wird die modifizierte libcrypto.so ein DA-Modul sein.
• Defining-Extension-Module (DX-Module) definieren entweder neue Funktionalitäten oder haben kein AOSP-Pendant.
  • Beispiel 1. Wenn ein Hersteller libjpeg.so eine Hilfsfunktion hinzufügt, um auf einige interne Daten zuzugreifen, dann wird die modifizierte libjpeg.so eine DX-Lib sein und die neu hinzugefügte Funktion wird der erweiterte Teil der Bibliothek sein.
  • Beispiel 2. Wenn ein Hersteller eine Nicht-AOSP-Bibliothek namens libfoo.so definiert, dann ist libfoo.so eine DX-Lib.

Abhängig von den von einem Modul verwendeten Funktionalitäten können Module in UA-Module und UX-Module eingeteilt werden.

• Using-only-AOSP-Module (UA-Module) verwenden nur AOSP-Funktionalitäten in ihren Implementierungen. Sie sind nicht auf Nicht-AOSP-Erweiterungen angewiesen.
  • Beispiel 1. Eine intakte unmodifizierte AOSP-Bibliothek ist ein UA-Modul.
  • Beispiel 2. Wenn eine modifizierte gemeinsam genutzte Bibliothek libjpeg.so nur auf andere AOSP-APIs angewiesen ist, dann ist es ein UA-Modul.
• Using-Extension Modules (UX-Module) verlassen sich in ihren Implementierungen auf einige Nicht-AOSP-Funktionalitäten.
  • Beispiel 1. Wenn eine modifizierte libjpeg.so auf einer anderen Nicht-AOSP-Bibliothek namens libjpeg_turbo2.so , dann ist die modifizierte libjpeg.so ein UX-Modul.
  • Beispiel 2. Wenn ein Anbieter eine neue Funktion zu seiner modifizierten libexif.so und seine modifizierte libjpeg.so die neu hinzugefügte Funktion von libexif.so verwendet, dann wird seine modifizierte libjpeg.so ein UX-Modul sein.

Definitionen und Verwendungen sind voneinander unabhängig:

VNDK-Erweiterungsmechanismus

Herstellermodule, die auf erweiterte Funktionalitäten angewiesen sind, funktionieren nicht, da die gleichnamige AOSP-Bibliothek nicht über die erweiterte Funktionalität verfügt. Wenn Anbietermodule direkt oder indirekt von erweiterten Funktionalitäten abhängen, sollten Anbieter gemeinsam genutzte DAUX-, DXUA- und DXUX-Bibliotheken in die Anbieterpartition kopieren (Anbieterprozesse suchen immer zuerst nach gemeinsam genutzten Bibliotheken in der Anbieterpartition). LL-NDK-Bibliotheken dürfen jedoch nicht kopiert werden, sodass Anbietermodule nicht auf die erweiterten Funktionalitäten angewiesen sein dürfen, die durch die modifizierten LL-NDK-Bibliotheken definiert werden.

Gemeinsam genutzte DAUA-Bibliotheken können auf der Systempartition verbleiben, wenn die entsprechende AOSP-Bibliothek dieselbe Funktionalität bereitstellen kann, und Herstellermodule funktionieren weiterhin, wenn die Systempartition durch ein generisches Systemabbild (GSI) überschrieben wird.

Drop-in-Ersetzung ist wichtig, da die unveränderten VNDK-Bibliotheken in der GSI bei einer Namenskollision mit den geänderten gemeinsam genutzten Bibliotheken verknüpft werden. Wenn die AOSP-Bibliotheken auf eine API/ABI-inkompatible Weise geändert werden, können die AOSP-Bibliotheken in der GSI möglicherweise nicht verknüpft werden oder führen zu undefiniertem Verhalten.