Producenci urządzeń z systemem Android zmieniają kod źródłowy bibliotek AOSP z różnych powodów. Niektórzy dostawcy ponownie wdrażają funkcje w bibliotekach AOSP, aby zwiększyć wydajność, podczas gdy inni dostawcy dodają nowe punkty zaczepienia, nowe interfejsy API lub nowe funkcje do bibliotek AOSP. Ta sekcja zawiera wskazówki dotyczące rozszerzania bibliotek AOSP w sposób, który nie łamie CTS / VTS.
Wymiana typu drop-in
Wszystkie zmodyfikowane biblioteki współdzielone muszą być binarnymi kompatybilnymi zamiennikami ich odpowiedników AOSP. Wszyscy istniejący użytkownicy AOSP muszą mieć możliwość korzystania ze zmodyfikowanej biblioteki współdzielonej bez ponownej kompilacji. Z tego wymogu wynika, co następuje:
- Nie wolno usuwać funkcji AOSP.
- Nie wolno zmieniać konstrukcji, jeśli takie konstrukcje są narażone na kontakt z ich użytkownikami.
- Nie należy wzmacniać warunku wstępnego funkcji.
- Funkcje muszą zapewniać równoważne funkcjonalności.
- Nie wolno osłabiać późniejszego stanu funkcji.
Rozszerzone klasyfikacje modułów
Klasyfikuj moduły według funkcjonalności, które definiują i wykorzystują .
Uwaga : Funkcjonalności są tutaj używane zamiast API / ABI, ponieważ można dodawać funkcje bez zmiany jakiegokolwiek API / ABI.
W zależności od funkcjonalności zdefiniowanych w module, moduły można podzielić na DA-Module i DX-Module :
- Definiowanie tylko modułów AOSP (Moduł DA) nie definiuje nowych funkcjonalności, których nie było w odpowiedniku AOSP.
- Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP jest modułem DA.
- Przykład 2. Jeśli sprzedawca przepisuje funkcje w
libcrypto.soz instrukcjami SIMD (bez dodawania nowych funkcji), to zmodyfikowanelibcrypto.sobędzie modułem DA.
- Definiowanie modułów rozszerzeń (moduł DX) albo definiuje nowe funkcje, albo nie ma odpowiednika AOSP.
- Przykład 1. Jeśli dostawca doda funkcję pomocniczą do
libjpeg.soaby uzyskać dostęp do niektórych danych wewnętrznych, wówczas zmodyfikowanylibjpeg.sobędzie DX-Lib, a nowo dodana funkcja będzie rozszerzoną częścią biblioteki. - Przykład 2. Jeśli sprzedawca zdefiniuje bibliotekę inną niż AOSP o nazwie
libfoo.so, wtedylibfoo.sobędzie DX-Lib.
- Przykład 1. Jeśli dostawca doda funkcję pomocniczą do
W zależności od funkcjonalności wykorzystywanych przez moduł, moduły można podzielić na UA-Module i UX-Module .
- Korzystanie tylko z modułów AOSP (moduł UA) wykorzystuje w swoich implementacjach tylko funkcje AOSP. Nie polegają na żadnych rozszerzeniach innych niż AOSP.
- Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP to moduł UA.
- Przykład 2. Jeśli zmodyfikowana biblioteka współdzielona
libjpeg.soopiera się tylko na innych interfejsach API AOSP, będzie to moduł UA.
- Korzystanie z modułów rozszerzeń (UX-Module) polega na niektórych funkcjach innych niż AOSP w swoich implementacjach.
- Przykład 1. Jeśli zmodyfikowany
libjpeg.soopiera się na innej bibliotece innej niż AOSP o nazwielibjpeg_turbo2.so, wówczas zmodyfikowanylibjpeg.sobędzie modułem UX. - Przykład 2. Jeśli sprzedawca doda nową funkcję do swojego zmodyfikowanego
libexif.soa jego zmodyfikowanylibjpeg.soużyje nowo dodanej funkcji zlibexif.so, wówczas jego zmodyfikowanylibjpeg.sobędzie modułem UX.
- Przykład 1. Jeśli zmodyfikowany
Definicje i zastosowania są od siebie niezależne:
| Używane funkcje | |||
|---|---|---|---|
| Tylko AOSP (UA) | Rozszerzony (UX) | ||
| Zdefiniowane funkcje | Tylko AOSP (DA) | DAUA | DAUX |
| Rozszerzony (DX) | DXUA | DXUX | |
Mechanizm rozszerzenia VNDK
Moduły dostawców, które opierają się na rozszerzonych funkcjach, nie będą działać, ponieważ biblioteka AOSP o tej samej nazwie nie ma rozszerzonej funkcjonalności. Jeśli moduły dostawców bezpośrednio lub pośrednio zależą od rozszerzonych funkcji, dostawcy powinni kopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych w partycji dostawcy). Jednak bibliotek LL-NDK nie wolno kopiować, więc moduły dostawców nie mogą polegać na rozszerzonych funkcjach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.
Biblioteki współużytkowane DAUA mogą pozostać na partycji systemowej, jeśli odpowiadająca im biblioteka AOSP może zapewniać tę samą funkcjonalność, a moduły dostawców będą nadal działać, gdy partycja systemowa zostanie nadpisana przez Generic System Image (GSI).
Zastępowanie typu drop-in jest ważne, ponieważ niezmodyfikowane biblioteki VNDK w GSI będą łączyć się ze zmodyfikowanymi bibliotekami współdzielonymi w przypadku kolizji nazw. Jeśli biblioteki AOSP zostaną zmodyfikowane w sposób niezgodny z API / ABI, biblioteki AOSP w GSI mogą nie połączyć się lub spowodować niezdefiniowane zachowania.