Omówienie pakietu VNDK (Vendor Native Development Kit)

Vendor Native Development Kit (VNDK) to zbiór bibliotek używanych przez inne biblioteki plików binarnych lub plików binarnych w partycji dostawcy lub produktu w czasie działania dla dlopen.

Dlaczego VNDK?

AOSP dopuszcza aktualizacje tylko na poziomie platformy, w ramach których partycję systemową można uaktualnić do najnowszej wersji platformy, a partycja dostawcy pozostaje bez zmian. Chociaż zbudowano je w innym miejscu pliki binarne w każdej partycji muszą ze sobą współpracować.

Aktualizacje dotyczące tylko platformy obejmują te wyzwania:

  • Zależność między modułami platformy a modułami dostawcy. Przed Androidem 8.0 moduły w partycji dostawcy i systemu można było łączyć i otwierać przed sobą nawzajem. Jednak nałożenie zależności od modułów dostawców było niepożądane ograniczeń w tworzeniu modułów platformy.
  • Rozszerzenia do bibliotek AOSP. Android, wymaga, aby wszystkie urządzenia z Androidem przechodziły CTS po zastąpieniu partycji systemowej ze standardowym ogólnym obrazem systemu (GSI). Dostawcy przedłużają jednak zakres AOSP w celu zwiększenia wydajności lub dodania dodatkowych funkcji do HIDL przez aktualizację partycji systemowej za pomocą standardowego interfejsu GSI. może uszkodzić implementację HIDL przez dostawcę. Wytyczne dotyczące i zapobieganiu takim awariom, zobacz Rozszerzenia VNDK.

Aby sprostać tym wyzwaniom, Android ma kilka funkcji, takich jak: jak VNDK (opisane w tej sekcji), HIDL, hwbinder, nakładka drzewa urządzenia oraz sepolicy.

Terminy dotyczące VNDK

W dokumentach dotyczących VNDK używana jest ta terminologia:
  • Moduły odnoszą się do bibliotek udostępnionych lub plików wykonywalnych. Czas kompilowania przez moduły zależności.
  • Procesy to zadania systemu operacyjnego generowane z plików wykonywalnych. Procesy przyspieszają działanie zależności.
  • Terminy kwalifikowane przez platformy są związane z partycją system:
    • Pliki wykonywalne struktury odnoszą się do plików wykonywalnych w lokalizacji /system/bin lub /system/xbin
    • Biblioteki udostępnione Framework odnoszą się do bibliotek udostępnionych w /system/lib[64]
    • Moduły platformy odnoszą się do obu bibliotek udostępnionych platformy i plików wykonywalnych platformy.
    • Procesy ramek to procesy wywodzące się z platformy. pliki wykonywalne, takie jak /system/bin/app_process.
  • Warunki dotyczące dostawców odnoszą się do partycji (vendor):
    • Pliki wykonywalne dostawcy odnoszą się do plików wykonywalnych w lokalizacji /vendor/bin
    • Biblioteki udostępnione dostawców odnoszą się do bibliotek udostępnionych w /vendor/lib[64]
    • Moduły dostawcy odnoszą się zarówno do plików wykonywalnych dostawcy, jak i bibliotek udostępnionych dostawcy.
    • Procesy dostawców są procesami opracowanymi przez dostawcę. Pliki wykonywalne, takie jak /vendor/bin/android.hardware.camera.provider@2.4-service.
    .
.

Pojęcia związane z VNDK

W idealnym Androidzie 8.0 lub nowszym procesy platformy nie ładują się biblioteki udostępnione dostawcy, wszystkie procesy dostawcy wczytują tylko biblioteki udostępnione dostawcy (i części bibliotek współdzielonych platformy) oraz komunikację między procesy platformy i procesy dostawcy podlegają HIDL i sprzętowi separatora.

Taki świat wiąże się z możliwością, że stabilne, publiczne interfejsy API biblioteki współdzielone platformy mogą nie być wystarczające dla programistów modułów dostawcy (chociaż interfejsy API mogą się zmieniać w poszczególnych wersjach Androida), co wymaga, bibliotek współdzielonych platformy jest dostępnych dla procesów dostawcy. Ponadto, jak mogą prowadzić do kompromisów. W niektórych przypadkach Listy HAL należy traktować inaczej.

W kolejnych sekcjach dowiesz się, jak VNDK obsługuje biblioteki współdzielone platformy dostawców i listy HAL Same-Process (SP-HAL).

Biblioteki udostępnione platformy dla dostawcy

W tej sekcji znajdziesz kryteria klasyfikowania bibliotek udostępnionych, które są są dostępne dla procesów dostawcy. Są 2 sposoby udzielania pomocy dostawcy modułów w różnych wersjach Androida:

  1. Ustabilizuj interfejsy ABI/API bibliotek udostępnionych platformy. Nowe moduły platformy i stare moduły dostawców mogą używać tej samej biblioteki współdzielonej do zmniejszać ilość pamięci i rozmiar pamięci masowej. Unikalna biblioteka współdzielona pozwala też uniknąć kilka problemów z podwójnym ładowaniem. Jednak koszt opracowania i utrzymania stabilnego poziomu Interfejsy ABI/API mają wysoki poziom i stabilizacja wszystkich interfejsów ABI/API eksportowanych przez z każdej biblioteki współdzielonej platformy.
  2. Skopiuj biblioteki udostępnione ze starej platformy. W zestawie ograniczenie dotyczące kanałów bocznych zdefiniowane jako wszystkie mechanizmy komunikacji wśród modułów platformy i dostawców, w tym między innymi: powiązanie, gniazdo, kreska pionowa, pamięć współdzielona, plik udostępniony i właściwości systemu. OK nie może być komunikacją, chyba że protokół komunikacyjny jest zablokowany i stabilny (np. HIDL za pomocą hwbinder). Podwójne ładowanie bibliotek udostępnionych może spowodować i problemach; na przykład jeśli obiekt utworzony przez nową bibliotekę zostanie przekazany do funkcji ze starej biblioteki, może wystąpić błąd, ponieważ te biblioteki mogą interpretować obiekt inaczej.

Stosujemy różne podejścia w zależności od charakterystycznych cech wspólnych biblioteki. W efekcie biblioteki współdzielone platformy są klasyfikowane na 3 grupy. podkategorie:

  • Biblioteki LL-NDK to biblioteki udostępnione w ramach platformy o których wiemy, że są stabilne. Programiści dbają o utrzymanie Stabilność interfejsów API i ABI.
    • LL-NDK zawiera następujące biblioteki: libEGL.so, libGLESv1_CM.so, libGLESv2.so, libGLESv3.so, libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so, libneuralnetworks.so, libsync.so libvndksupport.so i libvulkan.so,
  • Kwalifikujące się biblioteki VNDK (VNDK) to Udostępnione struktury Biblioteki, których można bezpiecznie skopiować dwukrotnie. Moduły dotyczące struktury oraz Moduły dostawców można łączyć z własnymi kopiami. Udostępniona platforma może zostać kwalifikującą się biblioteką VNDK tylko wtedy, gdy spełnia te warunki kryteria:
    • Nie wysyła ani nie odbiera adresów IPC do/z platformy.
    • Nie jest on związany z maszyną wirtualną ART.
    • Nie umożliwia odczytu i zapisu plików ani partycji w niestabilnych formatach plików.
    • Nie ma specjalnej licencji na oprogramowanie, która wymaga weryfikacji prawnej.
    • Właściciel kodu nie ma zastrzeżeń wobec stosowania przez dostawcę.
  • Biblioteki tylko z ramkami (TYLKO FWK) są udostępnione dla platformy Biblioteki, które nie należą do wymienionych powyżej kategorii. Te biblioteki:
    • Są uznawane za szczegóły wewnętrznej implementacji platformy.
    • Nie są dostępne dla modułów dostawcy.
    • mieć niestabilne interfejsy ABI/API i nie są gwarantowane zgodności z tymi interfejsami;
    • nie są kopiowane.

HAL z takim samym procesem (SP-HAL)

Same-Process HAL (SP-HAL) to zestaw wstępnie określonych HAL. zaimplementowano jako biblioteki udostępnione przez dostawcę i wczytano do ramki Procesy. Listy SP-HAL są izolowane przestrzenią nazw tagu łączącego (steruje biblioteki i symbole widoczne dla bibliotek udostępnionych). Listy SP-HAL muszą zależą tylko od LL-NDK i VNDK-SP.

VNDK-SP to wstępnie zdefiniowany podzbiór odpowiednich bibliotek VNDK. Biblioteki VNDK-SP są starannie sprawdzane pod kątem podwójnego wczytywania bibliotek VNDK-SP do platformy nie powoduje problemów. Zarówno identyfikatory SP-HAL, jak i VNDK-SP są zdefiniowane przez Google.

Te biblioteki są zatwierdzone SP-HAL:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

Biblioteki VNDK-SP określają vndk: { support_system_process: true } w plikach Android.bp. Jeśli vndk: {private:true} to również to biblioteki, które nazywają się VNDK-SP-Private i są niewidoczne dla SP-HALS.

Oto biblioteki przeznaczone wyłącznie do platformy z wyjątkami odnoszących się do wersji RS (FWK-TYLKO-RS):

  • libft2.so (Renderowanie)
  • libmediandk.so (Renderowanie)
.

Obsługa wersji VNDK

Biblioteki udostępnione VNDK mają różne wersje:

  • Właściwość systemowa ro.vndk.version jest dodawana automatycznie do /vendor/default.prop
  • Biblioteki współdzielone VNDK i VNDK-SP są instalowane jako szczytowy priorytet VNDK com.android.vndk.v${ro.vndk.version} i podłączony do /apex/com.android.vndk.v${ro.vndk.version}

Wartość parametru ro.vndk.version jest wybierana przez algorytm poniżej:

  • Jeśli BOARD_VNDK_VERSION nie równa się current, użyj BOARD_VNDK_VERSION.
  • Jeśli BOARD_VNDK_VERSION jest równe current:
    • Jeśli PLATFORM_VERSION_CODENAME to REL, użyj PLATFORM_SDK_VERSION (np. 28).
    • W przeciwnym razie użyj atrybutu PLATFORM_VERSION_CODENAME (np. P).

Vendor Test Suite (VTS)

Android Vendor Test Suite (VTS) wymaga niepusta właściwość ro.vndk.version. Oba nowe urządzenia wprowadzone na rynek Na urządzeniach z tą funkcją musi być zdefiniowany ro.vndk.version. Niektóre testy VNDK przypadki (np. VtsVndkFilesTest i VtsVndkDependencyTest) polegają na: ro.vndk.version w celu wczytania odpowiednich zbiorów danych bibliotek VNDK.