Natywny zestaw programistyczny dostawcy (VNDK)

Vendor Native Development Kit (VNDK) to zestaw bibliotek przeznaczonych wyłącznie dla dostawców do implementacji swoich warstw HAL. W VNDK statków system.img i jest dynamicznie połączone z kodem sprzedawcy przy starcie.

Dlaczego VNDK?

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

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

  • Zależność między modułami ramowych i modułów dostawców. 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 na temat zapobiegania takie pęknięcia, zobacz rozszerzeń VNDK ).

Aby sprostać tym wyzwaniom, Android 8.0 wprowadza kilka technik, takich jak VNDK (opisane w tym rozdziale), HIDL , hwbinder, urządzenia drzewa nakładki i sepolicy nakładki.

Zasoby VNDK

Ta sekcja zawiera następujące zasoby VNDK:

  • Koncepcje VNDK (poniżej) opisuje ramowe współdzielonych bibliotek, warstwy HAL tego samego procesu (SP-HALS) oraz terminologię VNDK.
  • VNDK rozszerzenia klasyfikuje sprzedawca specyficzne zmiany na 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 budować poparcie systemu opisuje konfiguracje systemu budowania i moduł składnie definicji, które są związane z VNDK.
  • VNDK Definicja Narzędzie ułatwia migrację drzewa źródłowego do Androida 8.0 i wyższych.
  • Linker nazw zapewnia precyzyjną kontrolę nad wspólnymi powiązań bibliotek.
  • Katalogi, zasad, a sepolicy definiuje strukturę katalogu dla urządzeń z systemem Android 8.0 i wyżej, zasady VNDK i związane sepolicy.
  • VNDK Projekt prezentacja przedstawia podstawowe koncepcje VDNK używane w Androidzie 8.0 i wyższej.

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. Ustabilizować Abis / API ram wspólne bibliotek. 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. Kopiowanie starych ram współdzielonych bibliotek. 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 charakterystyki bibliotek współdzielonych stosowane są różne podejścia. W rezultacie biblioteki współdzielone frameworka są podzielone na trzy podkategorie:

  • LL-NDK Bibliotekiramowe bibliotek, które są znane jako 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 ,
  • Uprawnieni VNDK biblioteki (VNDK)ramowe współdzielone biblioteki, które są bezpieczne do skopiowania dwukrotnie. Ramy Moduły i dostawcy Moduły można połączyć 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.
    • Jego właściciel kodu nie ma zastrzeżeń do zastosowań dostawcy.
  • Framework tylko biblioteki (FWK-ONLY)ramowe bibliotek, 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)

Tego samego procesu hal (SP-Hal) jest zestaw z góry określonych HAL realizowanych Dostawców biblioteki współdzielone i ładowane do procesów ramowych. SP-HAL są izolowane przez przestrzeń nazw konsolidatora (kontroluje biblioteki i symbole, które są widoczne dla bibliotek współdzielonych). SP-HAL musi polegać tylko na 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ślić vndk: { support_system_process: true } w swoich plikach Android.bp. Jeśli vendor_available: false jest również określona, wówczas te biblioteki są nazywane VNDK-SP-prywatne i są niewidoczne dla SP-HALS.

Poniżej znajdują się biblioteki ramowe tylko RS wyjątkami (FWK-Only-RS):

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

Terminologia VNDK

  • Moduły odnoszą się do każdej biblioteki współdzielone lub wykonywalnych.
  • Procesy działają zadania systemowe zrodził od wykonywalnych.
  • Ramy -qualified terminy odnoszą się do pojęć związanych z partycji systemowej.
  • Sprzedawca -qualified terminy odnoszą się do pojęć związanych z partycjami dostawców.

Na przykład:

  • Ramy wykonywalne znajdują się pliki wykonywalne w /system/bin lub /system/xbin .
  • Ramowe biblioteki współdzielone odnoszą się do bibliotek dzielonych pod /system/lib[64] .
  • Moduły ramowe odnoszą się zarówno do ramowego Shared Libraries i ramowego wykonywalnych.
  • Procesy ramowe są procesy zrodził od ramowego wykonywalne (np /system/bin/app_process ).
  • Wykonywalne dostawcy odnoszą się do plików wykonywalnych w /vendor/bin
  • Sprzedawca biblioteki współdzielone odnoszą się do bibliotek dzielonych pod /vendor/lib[64] .
  • Sprzedawca Moduły odnoszą się zarówno dostawcy wykonywalne i dostawców bibliotek dzielonych.
  • Procesy dostawcy procesy sklonowane od dostawcy wykonywalne (np
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Wersjonowanie VNDK

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

  • ro.vndk.version właściwość systemu jest automatycznie dodawany do /vendor/default.prop .
  • VNDK dzielone biblioteki są zainstalowane /system/lib[64]/vndk-${ro.vndk.version} .
  • VNDK-SP dzielone biblioteki są zainstalowane /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Dynamiczny plik konfiguracyjny łącznik jest zainstalowany /system/etc/ld.config.${ro.vndk.version}.txt .

Wartość ro.vndk.version wybiera 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ówna current :
    • Jeśli PLATFORM_VERSION_CODENAME jest REL , korzystanie PLATFORM_SDK_VERSION (np 28 ).
    • W przeciwnym razie korzystanie PLATFORM_VERSION_CODENAME (np P ).

Aktualizowanie urządzeń

Jeśli urządzenie Android 8.x niepełnosprawnych VNDK egzekwowanie run-time przez budowane bez BOARD_VNDK_VERSION , może dodać PRODUCT_USE_VNDK_OVERRIDE := false do BoardConfig.mk podczas aktualizacji do Androida 9.

Jeśli PRODUCT_USE_VNDK_OVERRIDE jest false , ro.vndk.lite nieruchomość zostanie automatycznie dodany do /vendor/default.prop a jej wartość będzie true . W konsekwencji, linker dynamiczny ładuje konfigurację przestrzeni nazw łącznikiem z /system/etc/ld.config.vndk_lite.txt , która izoluje tylko SP-HAL i VNDK-SP.

Aby zaktualizować urządzenie z Androidem 7.0 lub niższej do Androida 9, dodać PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false do BoardConfig.mk .

Zestaw testów dostawcy (VTS)

Android 9 Vendor testowy Suite (VTS) mandaty niepusty ro.vndk.version nieruchomość. Zarówno nowo uruchomiona urządzeń i modernizacji urządzeń musi zdefiniować ro.vndk.version . Niektóre przypadki testowe VNDK (np VtsVndkFilesTest i VtsVndkDependencyTest ) polegać na ro.vndk.version nieruchomości kwalifikujących się załadować bibliotek VNDK zestawów danych modelach.

Jeśli ro.product.first_api_level nieruchomość jest większa niż 27, ro.vndk.lite nieruchomość nie musi być zdefiniowana. VtsTreblePlatformVersionTest zawiedzie jeśli ro.vndk.lite jest zdefiniowana w nowo uruchomionej 9 Android urządzenia.

Historia dokumentu

Ta sekcja śledzi zmiany w dokumentacji VNDK.

Zmiany w Androidzie 9

  • Dodaj sekcję wersjonowania VNDK.
  • Dodaj sekcję VTS.
  • Niektóre kategorie VNDK zostały zmienione:
    • 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.
  • Wymienić libui.so z libft2.so w RS części przestrzeni nazw. To był błąd w celu włączenia libui.so .
  • Dodaj libGLESv3.so i libandroid_net.so bibliotek LL-NDK.
  • Dodaj libion.so bibliotek VNDK-SP.
  • Usuń libstdc++.so z bibliotek LL-NDK. Użyj libc++.so zamiast. Niektóre wersje toolchains autonomicznych może dodać -lstdc++ do flagi domyślne łącznikowych. Aby wyłączyć domyślne, dodać -nodefaultlibs -lc -lm -ldl do LDFLAGS .
  • Przenieś libz.so z LL-NDK do bibliotek VNDK-SP. W niektórych konfiguracjach, libz.so mogą nadal być LL-NDK. Jednak nie powinno być żadnych zauważalnych różnic.