Producenci urządzeń z Androidem zmieniają kod źródłowy bibliotek AOSP z różnych powodów. Niektórzy dostawcy ponownie implementują funkcje w bibliotekach AOSP, aby zwiększyć wydajność, podczas gdy inni dodają nowe hooki, nowe interfejsy API lub nowe funkcjonalności do bibliotek AOSP. Ta sekcja zawiera wskazówki dotyczące rozszerzania bibliotek AOSP w sposób, który nie psuje CTS/VTS.
Wymiana typu drop-in
Wszystkie zmodyfikowane biblioteki współdzielone muszą być kompatybilne binarnie i stanowić zamienniki ich odpowiedników AOSP. Wszyscy istniejący użytkownicy AOSP muszą mieć możliwość korzystania ze zmodyfikowanej biblioteki współdzielonej bez konieczności ponownej kompilacji. Wymóg ten oznacza, co następuje:
- Nie wolno usuwać funkcji AOSP.
- Konstrukcji nie wolno modyfikować w przypadku narażenia ich użytkowników na działanie.
- Nie należy wzmacniać warunku wstępnego funkcji.
- Funkcje muszą zapewniać równoważne funkcjonalności.
- Nie wolno osłabiać warunku końcowego funkcji.
Rozszerzone klasyfikacje modułów
Klasyfikuj moduły według funkcjonalności, które definiują i których używają .
Uwaga : zamiast API/ABI użyto tutaj funkcjonalności , ponieważ możliwe jest dodanie funkcjonalności bez zmiany jakiegokolwiek API/ABI.
W zależności od funkcjonalności zdefiniowanych w module, moduły można podzielić na moduły DA i moduły DX :
- Moduły definiujące tylko AOSP (Moduł DA) nie definiują 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 przepisze funkcje w
libcrypto.so
za pomocą instrukcji SIMD (bez dodawania nowych funkcji), wówczas zmodyfikowanalibcrypto.so
będzie modułem DA.
- Moduły definiujące-rozszerzenia (moduł DX) albo definiują nowe funkcjonalności, albo nie mają odpowiednika AOSP.
- Przykład 1. Jeśli sprzedawca doda funkcję pomocniczą do
libjpeg.so
w celu uzyskania dostępu do niektórych danych wewnętrznych, wówczas zmodyfikowanalibjpeg.so
będzie biblioteką DX, 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
, wówczaslibfoo.so
będzie biblioteką DX.
- Przykład 1. Jeśli sprzedawca doda funkcję pomocniczą do
W zależności od funkcjonalności wykorzystywanych przez moduł, moduły można podzielić na moduły UA i moduły UX .
- Moduły Using-only-AOSP (Moduł UA) wykorzystują w swoich implementacjach wyłącznie funkcjonalności AOSP. Nie opierają się na żadnych rozszerzeniach innych niż AOSP.
- Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP jest modułem UA.
- Przykład 2. Jeśli zmodyfikowana biblioteka współdzielona
libjpeg.so
opiera się tylko na innych API AOSP, będzie to moduł UA.
- Moduły using-Extension (moduł UX) w swoich implementacjach opierają się na niektórych funkcjonalnościach innych niż AOSP.
- Przykład 1. Jeśli zmodyfikowana
libjpeg.so
opiera się na innej bibliotece innej niż AOSP o nazwielibjpeg_turbo2.so
, wówczas zmodyfikowanalibjpeg.so
będzie modułem UX. - Przykład 2. Jeśli dostawca doda nową funkcję do zmodyfikowanego
libexif.so
, a zmodyfikowanylibjpeg.so
korzysta z nowo dodanej funkcji zlibexif.so
, wówczas zmodyfikowany pliklibjpeg.so
będzie modułem UX.
- Przykład 1. Jeśli zmodyfikowana
Definicje i zastosowania są od siebie niezależne:
Wykorzystane funkcjonalności | |||
---|---|---|---|
Tylko AOSP (UA) | Rozszerzone (UX) | ||
Zdefiniowane funkcjonalności | Tylko AOSP (DA) | DAUA | DAUX |
Rozszerzony (DX) | DXUA | DXUX |
Mechanizm przedłużający VNDK
Moduły dostawcy korzystające z rozszerzonych funkcjonalności nie będą działać, ponieważ biblioteka AOSP o tej samej nazwie nie ma rozszerzonych funkcjonalności. Jeśli moduły dostawcy są bezpośrednio lub pośrednio zależne od rozszerzonych funkcjonalności, dostawcy powinni skopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych na partycji dostawcy). Jednakże bibliotek LL-NDK nie wolno kopiować, zatem moduły dostawców nie mogą polegać na rozszerzonych funkcjonalnościach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.
Biblioteki współdzielone DAUA mogą pozostać na partycji systemowej, jeśli odpowiednia biblioteka AOSP może zapewnić tę samą funkcjonalność, a moduły dostawcy nadal działają, gdy partycja systemowa zostanie nadpisana przez ogólny obraz systemu (GSI).
Wymiana typu drop-in jest ważna, 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 zostać połączone lub skutkować niezdefiniowanym zachowaniem.