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 modifiziertelibcrypto.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 modifiziertelibjpeg.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 istlibfoo.so
eine DX-Lib.
- Beispiel 1. Wenn ein Hersteller
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 namenslibjpeg_turbo2.so
, dann ist die modifiziertelibjpeg.so
ein UX-Modul. - Beispiel 2. Wenn ein Anbieter eine neue Funktion zu seiner modifizierten
libexif.so
und seine modifiziertelibjpeg.so
die neu hinzugefügte Funktion vonlibexif.so
verwendet, dann wird seine modifiziertelibjpeg.so
ein UX-Modul sein.
- Beispiel 1. Wenn eine modifizierte
Definitionen und Verwendungen sind voneinander unabhängig:
Verwendete Funktionalitäten | |||
---|---|---|---|
Nur AOSP (UA) | Erweitert (UX) | ||
Definierte Funktionalitäten | Nur AOSP (DA) | DAUA | DAUX |
Erweitert (DX) | DXUA | DXUX |
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.