Omówienie natywnego pakietu do programowania dla sprzedawców (VNDK)

Natywny pakiet do programowania dla sprzedawców (VNDK) to zestaw bibliotek używanych przez inne biblioteki lub pliki binarne w partycji dostawcy lub produktu w czasie wykonywania funkcji dlopen().

Wycofanie

W Androidzie 8.0 wprowadzono NDK dostawcy, aby udostępnić interfejsy API między frameworkem a kodem dostawcy. Chociaż VNDK jest używany od wielu lat, ma pewne wady:
  • Miejsce na dane
    • Pojedynczy pakiet VNDK APEX zawiera wszystkie biblioteki VNDK, niezależnie od tego, czy są używane na urządzeniu.
    • GSI zawiera wiele wersji VNDK APEX, aby obsługiwać wiele wersji obrazów dostawcy.
  • Możliwość aktualizacji
    • Trudno jest aktualizować APEX-y VNDK oddzielnie od aktualizacji platformy.
    • Obrazy dostawcy są często aktualizowane bezprzewodowo (OTA), co zmniejsza korzyści płynące z umieszczania VNDK w ramach obrazu systemu.
Na podstawie tych problemów postanowiliśmy wycofać VNDK, począwszy od Androida 15.

Szczegóły dotyczące wycofania VNDK

Wszystkie biblioteki VNDK są pakowane w VNDK APEX i instalowane w ramach obrazu systemu (-ext). W związku z wycofaniem VNDK biblioteki VNDK są instalowane w ramach obrazu dostawcy (lub produktu) tak samo jak inne biblioteki dostępne dla dostawcy. Te funkcje są usuwane wraz z wycofaniem VNDK:
  • VNDK APEX na Androida 15
  • Właściwości systemu wskazujące wersję docelowego VNDK są usuwane, jeśli partycje dostawcy lub produktu są kompilowane na potrzeby Androida 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Optymalizacje VNDK nie będą dostępne, ponieważ nie ma VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT na urządzeniach z Androidem Go
    • use_vndk_as_stable dla dostawców APEX
  • migawka dostawcy, która jest silnie zależna od VNDK;

Wyjątki od wycofania

Te funkcje nie zmienią się po wycofaniu VNDK:
  • VNDK APEX z wersją VNDK 14 lub starszą, która jest wymagana do obsługi dotychczasowych obrazów dostawcy.
  • LL-NDK nie jest częścią VNDK.

Dlaczego VNDK?

AOSP umożliwia aktualizacje tylko frameworku, w których partycja systemu może zostać zaktualizowana do najnowszej wersji frameworku, a partycja dostawcy pozostaje bez zmian. Pomimo tego, że są kompilowane w różnych momentach, binarnych plików w każdej partycji muszą być w stanie ze sobą współpracować.

Aktualizacje dotyczące tylko frameworka obejmują te problemy:

  • Zależność między modułami platformy a modułami dostawców. Przed Androidem 8.0 moduły w partycji dostawcy i partycji systemowej mogły się ze sobą łączyć. Jednak zależności od modułów dostawców narzucały niechciane ograniczenia na rozwój modułów frameworka.
  • Rozszerzenia bibliotek AOSP. Android wymaga, aby wszystkie urządzenia z Androidem przeszły test CTS, gdy partycja systemowa zostanie zastąpiona standardowym obrazem systemu GSI. Jednak ponieważ producenci rozszerzają biblioteki AOSP, aby zwiększyć wydajność lub dodać dodatkowe funkcje do swoich implementacji HIDL, przeflashowanie partycji systemowej za pomocą standardowego GSI może spowodować uszkodzenie implementacji HIDL przez producenta. Wskazówki dotyczące zapobiegania takim przerwom znajdziesz w artykule VNDK extensions.

Aby rozwiązać te problemy, Android zawiera kilka funkcji, takich jak VNDK (opisany w tej sekcji), HIDL, hwbinder, nakładka drzewa urządzeń i nakładka sepolicy.

Warunki dotyczące VNDK

Dokumenty związane z VNDK używają tej terminologii:
  • Moduły to biblioteki udostępnione lub pliki wykonywalne. Moduł określa zależności na etapie kompilacji.
  • Procesy to zadania systemu operacyjnego utworzone z plików wykonywalnych. Procesy tworzą zależności w czasie wykonywania.
  • Terminy z kwalifikatorem Framework odnoszą się do partycji system:
    • Pliki wykonywalne frameworka to pliki wykonywalne w folderze /system/bin lub /system/xbin.
    • Biblioteki udostępnione w ramach frameworku to zasoby wspólne w sekcji /system/lib[64].
    • Moduły frameworku odnoszą się zarówno do bibliotek udostępnionych frameworku, jak i plików wykonywalnych frameworku.
    • Procesy frameworka to procesy utworzone z wykonalnych plików frameworka, takich jak /system/bin/app_process.
  • Warunki kwalifikowania się do dostawcy dotyczą następujących podziałów:vendor
    • Pliki wykonywalne dostawcy to pliki wykonywalne w folderze /vendor/bin
    • Biblioteki udostępnione dostawcy to biblioteki udostępnione w sekcji /vendor/lib[64].
    • Moduły dostawcy odnoszą się zarówno do plików wykonywalnych dostawcy, jak i do bibliotek wspólnych dostawcy.
    • Procesy dostawcy to procesy utworzone z plików wykonywalnych dostawcy, takich jak /vendor/bin/android.hardware.camera.provider@2.4-service.

Pojęcia związane z VNDK

W idealnym świecie w Androidzie 8.0 i nowszych procesy frameworku nie wczytują bibliotek udostępnianych przez dostawcę, wszystkie procesy dostawcy wczytują tylko biblioteki udostępniane przez dostawcę (oraz część bibliotek udostępnianych przez framework), a komunikacja między procesami frameworku a procesami dostawcy jest regulowana przez HIDL i binder sprzętowy.

W takim świecie stabilne, publiczne interfejsy API z bibliotek współdzielonych frameworku mogą nie wystarczyć deweloperom modułów dostawców (chociaż interfejsy API mogą się zmieniać między wersjami Androida), co wymaga, aby część bibliotek współdzielonych frameworku była dostępna dla procesów dostawców. Dodatkowo, ponieważ wymagania dotyczące wydajności mogą prowadzić do kompromisów, niektóre HAL-e o krytycznym czasie odpowiedzi muszą być traktowane inaczej.

W następnych sekcjach opisano szczegółowo, jak VNDK obsługuje biblioteki udostępniane przez framework dla dostawców i interfejsy HAL w ramach tego samego procesu (SP-HAL).

Biblioteki udostępnione w ramach frameworku dla dostawcy

W tej sekcji opisano kryteria klasyfikacji udostępnionych bibliotek, które są dostępne dla procesów dostawców. Istnieją 2 metody obsługi modułów dostawców w różnych wersjach Androida:

  1. Stabilizacja ABI-ów/interfejsów API bibliotek udostępnionych frameworku. Nowe moduły frameworku i starsze moduły dostawców mogą korzystać z tej samej wspólnej biblioteki, aby zmniejszyć obciążenie pamięci i rozmiar pamięci masowej. Unikalna biblioteka współdzielona zapobiega też kilku problemom związanym z podwójnym wczytywaniem. Jednak koszty rozwoju związane z utrzymywaniem stabilnych ABI/interfejsów API są wysokie, a stabilizacja wszystkich ABI/interfejsów API eksportowanych przez każdą bibliotekę wspólną frameworku jest nierealna.
  2. Skopiuj biblioteki udostępnione starego frameworka. Wprowadza silne ograniczenia dotyczące kanałów bocznych, zdefiniowanych jako wszystkie mechanizmy komunikacji między modułami frameworku i modułami dostawców, w tym między innymi binder, socket, pipe, współdzielona pamięć, współdzielony plik i właściwości systemu. Nie może być żadnej komunikacji, chyba że protokół komunikacji jest zamrożony i stabilny (np. HIDL przez hwbinder). Podwójne wczytywanie bibliotek współdzielonych może też powodować problemy. Jeśli na przykład obiekt utworzony przez nową bibliotekę zostanie przekazany do funkcji ze starej biblioteki, może wystąpić błąd, ponieważ te biblioteki mogą interpretować obiekt w inny sposób.

W zależności od właściwości udostępnionych bibliotek stosuje się różne podejścia. W związku z tym biblioteki udostępnione w ramach są podzielone na 3 podkategorie:

  • Biblioteki LL-NDK to biblioteki udostępnione frameworka, które są stabilne. Ich deweloperzy są zobowiązani do utrzymywania stabilności interfejsu API i ABI.
    • LL-NDK zawiera te 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.
  • Odpowiednie biblioteki VNDK (VNDK) to biblioteki udostępnione w ramach frameworka, które można bezpiecznie skopiować dwukrotnie. Moduły frameworka i Moduły dostawcy mogą łączyć się z własnymi kopiami. Biblioteka współdzielona frameworku może stać się odpowiednią biblioteką VNDK tylko wtedy, gdy spełnia te kryteria:
    • Nie wysyła ani nie odbiera interfejsów IPC do lub z ramy.
    • Nie jest to związane z maszyną wirtualną ART.
    • Nie odczytuje ani nie zapisze plików/partycji o niestabilnych formatach.
    • Nie ma specjalnej licencji na oprogramowanie, która wymaga sprawdzenia pod kątem zgodności z prawem.
    • Właściciel kodu nie ma zastrzeżeń do używania kodu przez dostawców.
  • Biblioteki tylko dla platformy (FWK-ONLY) to biblioteki udostępnione przez platformę, które nie należą do wymienionych powyżej kategorii. Te biblioteki:
    • są uważane za szczegóły implementacji wewnętrznej platformy;
    • Nie mogą być dostępne dla modułów dostawców.
    • niestabilne ABI/interfejsy API i brak gwarancji zgodności interfejsów API/ABI;
    • nie są kopiowane;

Interfejs HAL w tym samym procesie (SP-HAL)

HAL w tym samym procesie (SP-HAL) to zestaw wstępnie określonych bibliotek HAL, które są implementowane jako biblioteki współdzielone dostawcy i ładowane do procesów frameworka. Pliki SP-HAL są izolowane za pomocą przestrzeni nazw linkera (kontroluje biblioteki i symbole widoczne dla zasobów wspólnych). HAL-e SP 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 mieć pewność, że podwójne wczytywanie bibliotek VNDK-SP do procesów frameworku nie powoduje problemów. Zarówno interfejsy SP-HAL, jak i VNDK-SP są definiowane przez Google.

Te biblioteki są zatwierdzonymi bibliotekami HAL dla usług płatnych:

  • 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 określono też vndk: {private:true}, biblioteki te są wywoływane jako VNDK-SP-Private i są niewidoczne dla SP-HALS.

Oto biblioteki tylko dla frameworka z wyjątkami RS (FWK-ONLY-RS):

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

Wersje VNDK

Biblioteki udostępnione VNDK są ponumerowane:

  • Właściwość systemowa ro.vndk.version zostanie automatycznie dodana do /vendor/default.prop.
  • Biblioteki udostępnione VNDK i VNDK-SP są instalowane jako szczyt VNDKcom.android.vndk.v${ro.vndk.version} i montowane w /apex/com.android.vndk.v${ro.vndk.version}.

Wartość ro.vndk.version jest wybierana przez algorytm w ten sposób:

  • Jeśli BOARD_VNDK_VERSION nie równa się current, użyj BOARD_VNDK_VERSION.
  • Jeśli BOARD_VNDK_VERSION jest równa 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).

Vendor Test Suite (VTS)

Pakiet testów dostawców Androida (VTS) wymaga niepustej właściwości ro.vndk.version. Zarówno nowo uruchomione urządzenia, jak i urządzenia przechodzące na nową wersję muszą mieć zdefiniowaną wartość ro.vndk.version. Niektóre przypadki testów VNDK (np. VtsVndkFilesTest i VtsVndkDependencyTest) polegają na wczytaniu przez usługę ro.vndk.version odpowiednich zestawów danych bibliotek VNDK.