Rozszerzenia VNDK

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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 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 wpuszczana

Wszystkie zmodyfikowane biblioteki współdzielone muszą być kompatybilne z plikami binarnymi i zastępować ich odpowiedniki AOSP. Wszyscy obecni 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.
  • Konstrukcji nie wolno modyfikować, jeśli są one wystawione na ich użytkowników.
  • Warunek wstępny funkcji nie może być wzmacniany.
  • Funkcje muszą zapewniać równoważne funkcje.
  • Post-warunek funkcji nie może być osłabiony.

Rozszerzone klasyfikacje modułów

Klasyfikuj moduły według funkcjonalności, które definiują i używają .

Uwaga : Funkcjonalności są tutaj używane zamiast API/ABI, ponieważ możliwe jest dodawanie funkcjonalności bez zmiany API/ABI.

W zależności od funkcjonalności zdefiniowanych w module, moduły można podzielić na moduł DA i moduł DX :

  • Moduły Defining-only-AOSP (DA-Module) 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 przepisuje funkcje w libcrypto.so za pomocą instrukcji SIMD (bez dodawania nowych funkcji), to zmodyfikowany libcrypto.so będzie modułem DA.
  • Moduły definiujące-rozszerzające (DX-Module) albo definiują nowe funkcjonalności, albo nie mają odpowiednika AOSP.
    • Przykład 1. Jeśli sprzedawca doda funkcję pomocniczą do libjpeg.so , aby uzyskać dostęp do niektórych danych wewnętrznych, to zmodyfikowana libjpeg.so będzie DX-Lib, a nowo dodana funkcja będzie rozszerzoną częścią biblioteki.
    • Przykład 2. Jeśli sprzedawca definiuje bibliotekę inną niż AOSP o nazwie libfoo.so , wtedy libfoo.so będzie biblioteką DX-Lib.

W zależności od funkcjonalności wykorzystywanych przez moduł, moduły można podzielić na UA-Module i UX-Module .

  • Moduły using-only-AOSP (UA-Module) wykorzystują tylko funkcje AOSP w swoich implementacjach. Nie polegają 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 (UX-Module) opierają się w swoich implementacjach na niektórych funkcjach innych niż AOSP.
    • Przykład 1. Jeśli zmodyfikowana libjpeg.so opiera się na innej bibliotece innej niż AOSP o nazwie libjpeg_turbo2.so , to zmodyfikowany libjpeg.so będzie modułem UX.
    • Przykład 2. Jeśli sprzedawca doda nową funkcję do zmodyfikowanego libexif.so , a jego zmodyfikowany libjpeg.so użyje nowo dodanej funkcji z libexif.so , to jego zmodyfikowany libjpeg.so będzie modułem UX.

Definicje i zastosowania są od siebie niezależne:

Używane funkcjonalności
Tylko AOSP (UA) Rozszerzony (UX)
Zdefiniowane funkcjonalności Tylko AOSP (DA) DAUA DAUX
Rozszerzony (DX) DXUA DXUX

Mechanizm rozszerzenia VNDK

Moduły dostawcy, 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 dostawcy bezpośrednio lub pośrednio zależą od rozszerzonych funkcji, dostawcy powinni skopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych w partycji dostawcy). Jednak biblioteki LL-NDK nie mogą być kopiowane, więc moduły dostawcy nie mogą polegać na rozszerzonych funkcjach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.

Biblioteki współdzielone DAUA mogą pozostać na partycji systemowej, jeśli odpowiadająca im biblioteka AOSP może zapewnić taką samą funkcjonalność, a moduły dostawcy będą nadal działać, gdy partycja systemowa zostanie nadpisana przez ogólny obraz systemu (GSI).

Zastąpienie 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.