Omówienie zestawu Vendor Native Development Kit (VNDK)

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

Vendor Native Development Kit (VNDK) to zestaw bibliotek używanych przez inne biblioteki lub pliki binarne w partycji dostawcy lub produktu w czasie wykonywania dla dlopen.

Dlaczego VNDK?

AOSP umożliwia aktualizacje tylko w ramach platformy, w których partycję systemową można zaktualizować do najnowszej wersji platformy, podczas gdy partycja dostawcy pozostaje niezmieniona. Pomimo tego, że są budowane w różnym czasie, pliki binarne w każdej partycji muszą być w stanie ze sobą współpracować.

Aktualizacje dotyczące tylko platformy obejmują następujące wyzwania:

  • Zależność między modułami frameworka a modułami dostawcy . Przed Androidem 8.0 moduły w partycji dostawcy i systemowej mogły się ze sobą łączyć. Jednak zależności od modułów dostawców nałożyły niepożądane ograniczenia na rozwój modułów frameworka.
  • Rozszerzenia do bibliotek AOSP . Android wymaga, aby wszystkie urządzenia z systemem Android przeszły CTS, gdy partycja systemowa zostanie zastąpiona standardowym obrazem systemu ogólnego (GSI). Jednakże, ponieważ dostawcy rozszerzają biblioteki AOSP w celu zwiększenia wydajności lub dodania dodatkowych funkcji do swoich implementacji HIDL, flashowanie partycji systemowej za pomocą standardowego GSI może zepsuć implementację HIDL dostawcy. Aby uzyskać wskazówki dotyczące zapobiegania takim awariom, zobacz Rozszerzenia VNDK .

Aby sprostać tym wyzwaniom, system Android zawiera kilka funkcji, takich jak VNDK (opisane w tej sekcji), HIDL , hwbinder, nakładka drzewa urządzeń i nakładka sepolicy.

Warunki specyficzne dla VNDK

Dokumenty związane z VNDK używają następującej terminologii:
  • Moduły odnoszą się do bibliotek współdzielonych lub plików wykonywalnych. Moduły tworzą zależności czasu kompilacji.
  • Procesy to zadania systemu operacyjnego tworzone z plików wykonywalnych. Procesy tworzą zależności czasu wykonywania.
  • Warunki kwalifikowane dla frameworka dotyczą partycji system :
    • Pliki wykonywalne frameworka odnoszą się do plików wykonywalnych w /system/bin lub /system/xbin .
    • Biblioteki współdzielone frameworka odnoszą się do bibliotek współdzielonych w /system/lib[64] .
    • Moduły platformy odnoszą się zarówno do bibliotek współdzielonych platformy, jak i plików wykonywalnych platformy.
    • Procesy struktury to procesy tworzone z plików wykonywalnych struktury, takich jak /system/bin/app_process .
  • Warunki kwalifikowane dostawcy dotyczą partycji vendor :
    • Pliki wykonywalne dostawcy odnoszą się do plików wykonywalnych w /vendor/bin
    • Biblioteki współdzielone dostawcy odnoszą się do bibliotek współdzielonych w /vendor/lib[64] .
    • Moduły dostawcy odnoszą się zarówno do plików wykonywalnych dostawców, jak i bibliotek współdzielonych dostawców.
    • Procesy dostawcy to procesy tworzone z plików wykonywalnych dostawcy, takich jak /vendor/bin/android.hardware.camera.provider@2.4-service .

Koncepcje VNDK

W idealnym świecie systemu Android 8.0 i nowszych procesy frameworka nie ładują bibliotek współdzielonych dostawcy, wszystkie procesy dostawcy ładują tylko biblioteki współdzielone dostawcy (i część bibliotek współdzielonych platformy), a komunikacja między procesami struktury i procesami dostawcy jest zarządzana przez HIDL i sprzęt spoiwo.

Taki świat obejmuje możliwość, że stabilne, publiczne API z bibliotek współdzielonych frameworka mogą nie być wystarczające dla twórców modułów dostawców (chociaż API mogą się zmieniać między wydaniami Androida), wymagając, aby pewna część bibliotek współdzielonych frameworka była dostępna dla procesów dostawcy. Ponadto, ponieważ wymagania dotyczące wydajności mogą prowadzić do kompromisów, niektóre warstwy HAL o krytycznym znaczeniu dla czasu odpowiedzi muszą być traktowane inaczej.

W poniższych sekcjach szczegółowo opisano, jak VNDK obsługuje biblioteki współdzielone platformy dla dostawców i warstwy HAL tego samego procesu (SP-HAL).

Biblioteki współdzielone platformy dla dostawcy

W tej sekcji opisano kryteria klasyfikowania bibliotek współdzielonych, które są dostępne dla procesów dostawców. Istnieją dwa podejścia do obsługi modułów dostawców w wielu wersjach systemu Android:

  1. Ustabilizuj interfejsy ABI/API bibliotek współdzielonych platformy . Nowe moduły frameworka i moduły starych dostawców mogą korzystać z tej samej biblioteki współdzielonej, aby zmniejszyć zużycie pamięci i rozmiar pamięci. Unikalna biblioteka współdzielona pozwala również uniknąć kilku problemów z podwójnym ładowaniem. Jednak koszt rozwoju w celu utrzymania stabilnych interfejsów ABI/API jest wysoki, a stabilizacja wszystkich interfejsów ABI/API eksportowanych przez każdą bibliotekę współdzieloną platformy jest nierealna.
  2. Skopiuj stare biblioteki współdzielone frameworka . Zawiera silne ograniczenie dotyczące kanałów bocznych, definiowanych jako wszystkie mechanizmy komunikacji między modułami frameworka i modułami dostawców, w tym (ale nie wyłącznie) binder, socket, potok, pamięć współdzielona, ​​współdzielony plik i właściwości systemu. Nie może być komunikacji, chyba że protokół komunikacyjny jest zamrożony i stabilny (np. HIDL przez hwbinder). Podwójne ładowanie bibliotek współdzielonych również może powodować problemy; na przykład, jeśli obiekt utworzony przez nową bibliotekę jest przekazywany do funkcji ze starej biblioteki, może wystąpić błąd, ponieważ te biblioteki mogą inaczej interpretować obiekt.

W zależności od charakterystyki bibliotek współdzielonych stosowane są różne podejścia. W rezultacie biblioteki współdzielone frameworka są podzielone na trzy podkategorie:

  • Biblioteki LL-NDK to biblioteki współdzielone platformy , o których wiadomo, że są stabilne. Ich programiści są zobowiązani do utrzymania stabilności API/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 biblioteki udostępnione w ramach platformy, które można bezpiecznie skopiować dwukrotnie. Moduły ramowe i moduły dostawcy mogą łączyć się z własnymi kopiami. Biblioteka współdzielona frameworku może stać się kwalifikującą się biblioteką VNDK tylko wtedy, gdy spełnia następujące kryteria:
    • Nie wysyła/odbiera IPC do/z frameworka.
    • Nie jest związany z maszyną wirtualną ART.
    • Nie odczytuje/zapisuje plików/partycji o niestabilnych formatach plików.
    • Nie posiada specjalnej licencji na oprogramowanie, która wymaga przeglądu prawnego.
    • Właściciel kodu nie ma zastrzeżeń do zastosowań dostawcy.
  • Biblioteki Framework-Only (FWK-ONLY) to Framework Shared Libraries , które nie należą do kategorii wymienionych powyżej. Te biblioteki:
    • Są uważane za wewnętrzne szczegóły implementacji ram.
    • Nie mogą być dostępne przez moduły dostawców.
    • Mają niestabilne interfejsy ABI/API i brak gwarancji zgodności API/ABI.
    • Nie są kopiowane.

HAL tego samego procesu (SP-HAL)

Same-Process HAL ( SP-HAL ) to zestaw wstępnie określonych warstw HAL zaimplementowanych jako biblioteki udostępnione przez dostawców i załadowanych do procesów Framework . SP-HAL są izolowane przez przestrzeń nazw konsolidatora (kontroluje biblioteki i symbole, które są widoczne dla bibliotek współdzielonych). SP-HAL muszą zależeć tylko od LL-NDK i VNDK-SP .

VNDK-SP to wstępnie zdefiniowany podzbiór kwalifikujących się bibliotek VNDK. Biblioteki VNDK-SP są dokładnie sprawdzane, aby zapewnić, że podwójne ładowanie bibliotek VNDK-SP do procesów frameworka nie spowoduje problemów. Zarówno SP-HAL, jak i VNDK-SP są zdefiniowane przez Google.

Następujące biblioteki są zatwierdzonymi 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 swoich plikach Android.bp. Jeśli podano również vndk: {private:true} , to te biblioteki noszą nazwę VNDK-SP-Private i są niewidoczne dla SP-HALS.

Poniżej znajdują się biblioteki tylko dla frameworków z wyjątkami RS (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

Wersjonowanie VNDK

Biblioteki współdzielone VNDK są wersjonowane:

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

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

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

Zestaw testów dostawcy (VTS)

Pakiet testowy dostawcy systemu Android (VTS) nakazuje niepustą właściwość ro.vndk.version . Zarówno nowo uruchomione urządzenia, jak i urządzenia aktualizujące muszą definiować ro.vndk.version . Niektóre przypadki testowe VNDK (np VtsVndkFilesTest i VtsVndkDependencyTest ) polegają na właściwości ro.vndk.version w celu załadowania pasujących zestawów danych odpowiednich bibliotek VNDK.