Hersteller von Android-Geräten ändern den Quellcode von AOSP-Bibliotheken für aus verschiedenen Gründen. Einige Anbieter implementieren Funktionen erneut in AOSP-Bibliotheken, um und die Leistung steigern, während andere Anbieter neue Hooks, neue APIs oder neue zu AOSP-Bibliotheken hinzufügen. Dieser Abschnitt enthält Richtlinien für Erweiterung von AOSP-Bibliotheken auf eine Weise, die CTS/VTS nicht beeinträchtigt.
Austausch von Ersatzgeräten
Alle geänderten gemeinsam genutzten Bibliotheken müssen binär kompatibel sein. Drop-In-Ersatz ihres AOSP-Gegenstücks. Alle vorhandenen AOSP-Nutzer müssen in der Lage sein, die geänderte gemeinsam genutzte Bibliothek ohne Neukompilierungen. Diese Anforderung impliziert Folgendes:
- AOSP-Funktionen dürfen nicht entfernt werden.
- Gebäude dürfen nicht verändert werden, wenn diese Gebäude gegenüber Nutzenden.
- Die Vorbedingung von Funktionen darf nicht verstärkt werden.
- Funktionen müssen gleichwertige Funktionen bereitstellen.
- Die Nachbedingung von Funktionen darf nicht abgeschwächt werden.
Klassifizierungen der erweiterten Module
Module nach den von ihnen definierten Funktionen und use an.
Hinweis: Hier werden Funktionen verwendet. statt mit API/ABI, da es möglich ist, Funktionen hinzuzufügen, ohne eine beliebige API/ein beliebiges ABI.
Je nach den in einem Modul definierten Funktionen können Module in DA-Modul und DX-Modul klassifiziert:
-
Define-only-AOSP Modules (DA-Module) definieren keine neuen
die nicht im AOSP-Gegenstück vorhanden sind.
- Beispiel 1: Eine intakte unveränderte AOSP-Bibliothek ist ein DA-Modul.
- Beispiel 2: Wenn ein Zulieferunternehmen die Funktionen
libcrypto.somit SIMD-Anleitung (ohne neue hinzuzufügen) -Funktionen), ist das geändertelibcrypto.soein DA-Modul.
-
Define-Extension Modules (DX-Module) definieren entweder neue
Funktionen haben oder kein AOSP-Gegenstück haben.
- Beispiel 1: Wenn ein Zulieferunternehmen
eine Hilfsfunktion hinzufügt,
libjpeg.so, um auf einige interne Daten zuzugreifen, dann die geändertelibjpeg.soist eine DX-Lib und die neu hinzugefügte Funktion ist den erweiterten Teil der Bibliothek aus. - Beispiel 2: Wenn ein Anbieter eine Nicht-AOSP-Bibliothek
libfoo.so, dann istlibfoo.soeine DX-Lib.
- Beispiel 1: Wenn ein Zulieferunternehmen
eine Hilfsfunktion hinzufügt,
Je nach den von einem Modul verwendeten Funktionen können Module klassifiziert werden. in UA-Modul und UX-Modul ein.
-
Using-only-AOSP Modules (UA-Module) verwenden nur AOSP-Funktionen.
in ihren Implementierungen. Sie benötigen keine Nicht-AOSP-Erweiterungen.
- Beispiel 1: Eine intakte unveränderte AOSP-Bibliothek ist ein UA-Modul.
- Beispiel 2: Wenn eine geänderte gemeinsam genutzte Bibliothek
libjpeg.sonur auf anderen AOSP APIs basiert, ist es ein UA-Modul.
-
Using-Extension Modules (UX-Module) basieren auf einigen Nicht-AOSPs.
Funktionen implementiert werden.
- Beispiel 1: Wenn eine geänderte
libjpeg.soauf eine andere Nicht-AOSP-Bibliothek namenslibjpeg_turbo2.so, dann geändertlibjpeg.soist ein UX-Modul. - Beispiel 2: Wenn ein Anbieter eine
neue Funktion zu seinem geänderten
libexif.sound die geändertelibjpeg.soverwenden die neu hinzugefügte Funktion auslibexif.so, dann deren geändertelibjpeg.soist ein UX-Modul.
- Beispiel 1: Wenn eine geänderte
Definitionen und Verwendungen sind voneinander unabhängig:
| Verwendete Funktionen | |||
|---|---|---|---|
| Nur AOSP (UA) | Erweitert (UX) | ||
| Definierte Funktionen | Nur AOSP (DA) | Logo: DAUA | DAUX |
| Erweitert (DX) | Logo: DXUA | Logo: DXUX | |
VNDK-Erweiterungsmechanismus
Anbietermodule, die auf erweiterten Funktionen basieren, funktionieren nicht, weil die Eine gleichnamige AOSP-Bibliothek verfügt nicht über die erweiterte Funktionalität. Wenn Anbietermodule direkt oder indirekt von erweiterten Funktionalitäten, Anbieter müssen gemeinsam genutzte DAUX-, DXUA- und DXUX-Bibliotheken an den Anbieter kopieren. Partition (Anbieterprozesse suchen immer nach gemeinsam genutzten Bibliotheken innerhalb des Anbieters) an die erste Partition an. LL-NDK-Bibliotheken dürfen jedoch nicht kopiert werden. Module dürfen nicht auf den erweiterten Funktionen basieren, die in den geänderten LL-NDK-Bibliotheken.
Gemeinsam genutzte DAUA-Bibliotheken können auf der Systempartition bleiben, wenn die kann die entsprechende AOSP-Bibliothek funktionieren, wenn die Systempartition durch einen generischen System-Image (GSI).
Der Drop-in-Ersatz ist wichtig, da die unveränderten VNDK-Bibliotheken in wird die GSI bei Namenskonflikten mit den geänderten gemeinsam genutzten Bibliotheken verknüpft. Wenn die AOSP-Bibliotheken in einer nicht mit API/ABI kompatiblen Weise modifiziert wurden, der AOSP. können Bibliotheken in der GSI-Datei möglicherweise nicht verknüpft werden oder zu nicht definiertem Verhalten führen.