Natywny zestaw programistyczny dostawcy (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 wyłącznie dla dostawców w celu implementacji swoich warstw HAL. VNDK jest dostarczany w pliku system.img i jest dynamicznie łączony z kodem dostawcy w czasie wykonywania.

Dlaczego VNDK?

System Android 8.0 i nowszy umożliwia aktualizacje tylko w ramach struktury, w których partycję systemową można zaktualizować do najnowszej wersji, podczas gdy partycje dostawcy pozostają niezmienione. Oznacza to, że pliki binarne zbudowane w różnym czasie muszą być w stanie ze sobą współpracować; VNDK obejmuje zmiany API/ABI w różnych wersjach systemu Android.

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

  • Zależność między modułami frameworka a modułami dostawcy . Przed Androidem 8.0 moduły z obu stron mogły łączyć się z modułami z drugiej strony. 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 . System Android 8.0 i nowszy 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 8.0 wprowadza kilka technik, takich jak VNDK (opisane w tej sekcji), HIDL , hwbinder, nakładka drzewa urządzeń i nakładka sepolicy.

Zasoby VNDK

Ta sekcja zawiera następujące zasoby VNDK:

  • Koncepcje VNDK (poniżej) opisują biblioteki współdzielone platformy, warstwy HAL tego samego procesu (SP-HAL) i terminologię VNDK.
  • Rozszerzenia VNDK klasyfikują zmiany specyficzne dla dostawcy w kategorie. Na przykład biblioteki z rozszerzonymi funkcjami, na których opierają się moduły dostawcy, muszą zostać skopiowane do partycji dostawcy, ale zmiany niezgodne z ABI są zabronione.
  • VNDK Build System Support opisuje konfiguracje systemu kompilacji i składnię definicji modułów, które są związane z VNDK.
  • Narzędzie definicji VNDK pomaga w migracji drzewa źródłowego do systemu Android 8.0 lub nowszego.
  • Przestrzeń nazw konsolidatora zapewnia precyzyjną kontrolę nad powiązaniami bibliotek współdzielonych.
  • Katalogi, reguły i sepolicy definiują strukturę katalogów dla urządzeń z systemem Android 8.0 lub nowszym, regułami VNDK i skojarzoną sepolityką.
  • Prezentacja VNDK Design ilustruje podstawowe koncepcje VDNK używane w systemie Android 8.0 i nowszych.

Koncepcje VNDK

W idealnym świecie Androida 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 frameworka 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 dostawców. 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ą frameworka 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 tylko) 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 cech 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 interfejsu 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 określono również vendor_available: false , 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)

Terminologia VNDK

  • Moduły odnoszą się do bibliotek współdzielonych lub plików wykonywalnych .
  • Procesy to zadania systemu operacyjnego tworzone z plików wykonywalnych .
  • Terminy kwalifikowane do frameworka odnoszą się do pojęć związanych z partycją systemową .
  • Terminy kwalifikowane dostawcy odnoszą się do pojęć związanych z partycjami dostawcy .

Na przykład:

  • Pliki wykonywalne frameworka odnoszą się do plików wykonywalnych w /system/bin lub /system/xbin .
  • Biblioteki współdzielone platformy odnoszą się do bibliotek współdzielonych w /system/lib[64] .
  • Moduły frameworka odnoszą się zarówno do bibliotek współdzielonych , jak i plików wykonywalnych frameworka .
  • Procesy Frameworka to procesy tworzone z plików wykonywalnych Frameworka (np. /system/bin/app_process ).
  • 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 dostawcy , jak i bibliotek udostępnionych dostawcy .
  • Procesy dostawcy to procesy tworzone z plików wykonywalnych dostawcy (np
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Wersjonowanie VNDK

W systemie Android 9 biblioteki współdzielone VNDK są wersjonowane:

  • Właściwość systemowa ro.vndk.version jest automatycznie dodawana do /vendor/default.prop .
  • Biblioteki współdzielone VNDK są instalowane w /system/lib[64]/vndk-${ro.vndk.version} .
  • Biblioteki współdzielone VNDK-SP są instalowane w /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Plik konfiguracyjny dynamicznego konsolidatora jest instalowany w /system/etc/ld.config.${ro.vndk.version}.txt .

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 ).

Aktualizowanie urządzeń

Jeśli urządzenie z Androidem 8.x wyłączyło wymuszanie środowiska wykonawczego VNDK, ponieważ zostało zbudowane bez BOARD_VNDK_VERSION , może dodać PRODUCT_USE_VNDK_OVERRIDE := false do BoardConfig.mk podczas uaktualniania do Androida 9.

Jeśli PRODUCT_USE_VNDK_OVERRIDE ma wartość false , właściwość ro.vndk.lite zostanie automatycznie dodana do /vendor/default.prop i jej wartość będzie true . W konsekwencji dynamiczny linker załaduje konfigurację przestrzeni nazw linkera z /system/etc/ld.config.vndk_lite.txt , który izoluje tylko SP-HAL i VNDK-SP.

Aby zaktualizować urządzenie z Androidem 7.0 lub starszym do Androida 9, dodaj PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false do BoardConfig.mk .

Zestaw testów dostawcy (VTS)

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

Jeśli właściwość ro.product.first_api_level jest większa niż 27, właściwość ro.vndk.lite nie może być zdefiniowana. VtsTreblePlatformVersionTest zakończy się niepowodzeniem, jeśli ro.vndk.lite zostanie zdefiniowany na nowo uruchomionym urządzeniu z systemem Android 9.

Historia dokumentu

Ta sekcja śledzi zmiany w dokumentacji VNDK.

Zmiany w Androidzie 9

  • Dodaj sekcję wersjonowania VNDK.
  • Dodaj sekcję VTS.
  • Zmieniono nazwy niektórych kategorii VNDK:
    • Nazwa LL-NDK-Indirect została zmieniona na LL-NDK-Private.
    • Nazwa VNDK-Indirect została zmieniona na VNDK-Private.
    • Nazwa VNDK-SP-Indirect-Private została zmieniona na VNDK-SP-Private.
    • VNDK-SP-Indirect został usunięty.

Zmiany w Androidzie 8.1

  • Biblioteki SP-NDK zostały połączone w biblioteki LL-NDK.
  • Zamień libui.so na libft2.so w sekcji przestrzeni nazw RS. Błędem było dołączenie libui.so .
  • Dodaj libGLESv3.so i libandroid_net.so do bibliotek LL-NDK.
  • Dodaj libion.so do bibliotek VNDK-SP.
  • Usuń libstdc++.so z bibliotek LL-NDK. Zamiast tego użyj libc++.so . Niektóre wersje autonomicznych łańcuchów narzędzi mogą dodawać -lstdc++ do domyślnych flag konsolidatora. Aby wyłączyć ustawienia domyślne, dodaj -nodefaultlibs -lc -lm -ldl do LDFLAGS .
  • Przenieś libz.so z LL-NDK do bibliotek VNDK-SP. W niektórych konfiguracjach libz.so może nadal być LL-NDK. Jednak nie powinno być żadnych zauważalnych różnic.