Przestrzeń nazw tagu łączącego

Dynamiczne narzędzie łączące eliminuje 2 wyzwania związane z projektowaniem Treble VNDK:

• Biblioteki udostępnione SP-HAL i ich zależności, w tym VNDK-SP są wczytywane do procesów platformy. Trzeba co pozwala zapobiegać konfliktom symboli.
• dlopen() i android_dlopen_ext() mogą przedstawić niektóre zależności środowiska wykonawczego, które są niewidoczne w czasie kompilacji i mogą być trudne do wykrycia za pomocą analizy statycznej.

Te 2 problemy można rozwiązać za pomocą przestrzeni nazw powiązania . Mechanizm ten jest dostarczany przez dynamiczny tag łączący. it biblioteki udostępnione w różnych przestrzeniach nazw tagu łączącego, biblioteki o tej samej nazwie, ale z innymi symbolami nie powodują konfliktu.

Z drugiej strony mechanizm przestrzeni nazw tagu łączącego zapewnia elastyczność Dzięki temu niektóre biblioteki udostępnione można eksportować przez przestrzeń nazw tagu łączącego, a następnie używać ich innej przestrzeni nazw tagu łączącego. Wyeksportowane biblioteki udostępnione mogą zostać interfejsów programowania aplikacji, które są publicznie dostępne dla innych programów ukrywanie szczegółów implementacji w przestrzeniach nazw tagu łączącego.

Na przykład: /system/lib[64]/libcutils.so i /system/lib[64]/vndk-sp-${VER}/libcutils.so to 2 wspólne elementy biblioteki. Te 2 biblioteki mogą mieć różne symbole. Wczytano na różne przestrzenie nazw tagu łączącego, tak aby moduły platformy mogły zależeć od Biblioteki udostępnione /system/lib[64]/libcutils.so i SP-HAL mogą zależy od: /system/lib[64]/vndk-sp-${VER}/libcutils.so.

Z drugiej strony /system/lib[64]/libc.so to przykład biblioteki publicznej eksportowanej przez przestrzeń nazw tagu łączącego i importowanych do w przestrzeniach nazw tagów łączących. Zależności funkcji /system/lib[64]/libc.so, na przykład libnetd_client.so, są wczytywane do przestrzeni nazw, w której /system/lib[64]/libc.so w domu. Inne przestrzenie nazw nie będą miały dostępu do tych zależności. Ten umieszcza w nim szczegóły implementacji, a jednocześnie udostępnia i interfejsów.

Jak to działa

Dynamiczny tag łączący odpowiada za ładowanie określonych bibliotek udostępnionych we wpisach DT_NEEDED lub w bibliotekach udostępnionych określonych przez argument dlopen() lub android_dlopen_ext(). W obu dynamiczny tag linków znajduje przestrzeń nazw tagu łączącego, w której element wywołujący i próbuje wczytać zależności w tej samej przestrzeni nazw tagu łączącego. Jeśli dynamiczny tag łączący nie może wczytać udostępnionej biblioteki do określonego tagu łączącego przestrzeni nazw, prosi o powiązaną przestrzeń nazw tagu łączącego o wyeksportowane dane udostępnione biblioteki.

Format pliku konfiguracji

Format pliku konfiguracji opiera się na formacie pliku INI. Typowa wygląda tak:

dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

[system]
additional.namespaces = sphal,vndk

namespace.default.isolated = true
namespace.default.search.paths = /system/${LIB}
namespace.default.permitted.paths = /system/${LIB}/hw
namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB}
namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw

namespace.sphal.isolated = true
namespace.sphal.visible = true
namespace.sphal.search.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.permitted.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.asan.search.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.search.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.asan.permitted.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.permitted.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.links = default,vndk
namespace.sphal.link.default.shared_libs = libc.so:libm.so
namespace.sphal.link.vndk.shared_libs = libbase.so:libcutils.so

namespace.vndk.isolated = true
namespace.vndk.search.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.permitted.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.links = default
namespace.vndk.link.default.shared_libs = libc.so:libm.so

[vendor]
namespace.default.isolated = false
namespace.default.search.paths = /vendor/${LIB}:/system/${LIB}

Plik konfiguracji zawiera:

• Kilka właściwości mapowania sekcji katalogów na początku dynamiczny tag łączący, aby wybrać odpowiednią sekcję.
• Kilka sekcji konfiguracji przestrzeni nazw tagu łączącego:
  • Każda sekcja zawiera kilka przestrzeni nazw (wierzchołki grafu) i kilka połączenia zastępcze między przestrzeniami nazw (łuki wykresu).
  • Każda przestrzeń nazw ma własne odizolowanie, ścieżki wyszukiwania, dozwolone ścieżki, i ustawieniami widoczności.

W tabelach poniżej szczegółowo opisujemy znaczenie poszczególnych właściwości.

Właściwość mapowania sekcji katalogu

Właściwość	Opis	Przykład
dir.name	Ścieżka do katalogu, który znajduje się w sekcji [name] . Każda właściwość mapuje pliki wykonywalne w katalogu na tag łączący konfiguracji przestrzeni nazw. Mogą być co najmniej 2 właściwości które mają taką samą wartość name, ale wskazują inną i katalogów.	dir.system = /system/bin dir.system = /system/xbin dir.vendor = /vendor/bin Oznacza to, że konfiguracja określona w tagu Sekcja [system] dotyczy wczytywanych plików wykonywalnych z /system/bin lub /system/xbin. Zastosowanie ma konfiguracja określona w sekcji [vendor] do plików wykonywalnych wczytywanych z lokalizacji /vendor/bin.

Właściwości relacji

Właściwość	Opis	Przykład
additional.namespaces	Rozdzielona przecinkami lista dodatkowych przestrzeni nazw (oprócz default) dla sekcji.	additional.namespaces = sphal,vndk Oznacza to, że istnieją 3 przestrzenie nazw (default, sphal i vndk) w: [system] konfiguracji.
namespace.name.links	Rozdzielona przecinkami lista zastępczych przestrzeni nazw. Jeśli w bieżącej przestrzeni nazw nie można znaleźć udostępnionej biblioteki, komponent dynamiczny tag łączący próbuje wczytać bibliotekę współdzieloną z zastępczych przestrzeni nazw. przestrzeń nazw określona na początku listy ma wyższy priorytet. Uwaga: zastępcze przestrzenie nazw nie są przechodni. Dla: przykład przestrzeni nazw A odsyła do przestrzeni nazw B i przestrzeni nazw Link B prowadzi do przestrzeni nazw C. Jeśli dynamiczny tag łączący nie może znajduje bibliotekę w przestrzeni nazw A, przeszukuje TYLKO przestrzeń nazw B. Nie przeszukuje przestrzeni nazw C.	namespace.sphal.links = default,vndk Jeśli biblioteka współdzielona lub plik wykonywalny żąda biblioteki udostępnionej, która nie można wczytać do przestrzeni nazw sphal, dynamiczny tag łączący próbuje wczytać zasoby udostępnione z biblioteki default przestrzeni nazw. Jeśli nie można załadować biblioteki udostępnionej z poziomu default, dynamiczny tag łączący spróbuje wczytać tag zasoby wspólne z przestrzeni nazw vndk. Jeśli żadna próba się nie powiedzie, dynamiczny tag łączący zwróci błąd.
namespace.name.link.other.shared_libs	Rozdzielona dwukropkiem lista bibliotek udostępnionych, którą można przeszukiwać other przestrzeni nazw, których nie można znaleźć w Przestrzeń nazw name. Tej usługi nie można używać z: namespace.name.link.other.allow_all_shared_libs Uwaga: ta usługa korzysta z tego samego źródła implementacja z biblioteki publiczne.txt . Oba mechanizmy kontrolują zaimportowane biblioteki udostępnione, określając z filtrem nazwy biblioteki. Różnica polega na tym, że pole ld.config.txt jest ładowane przez dynamiczny tag łączący i wszystkie przestrzenie nazw są tworzone podczas uruchamiania programu. W dla kontrastu libnativeloader tworzy przestrzeń nazw tagu łączącego, gdy Proces Zygote jest rozwidlony i specjalny pod kątem aplikacji. Przestrzeń nazw dla bibliotek natywnych aplikacji zawiera link, który pozwala na dostęp tylko do biblioteki nazwy podane w public.libraries.txt.	namespace.sphal.link.default.shared_libs = libc.so:libm.so Oznacza to, że link zastępczy akceptuje tylko libc.so lub libm.so jako żądaną nazwę biblioteki. Dynamiczne linki łączące ignoruje link zastępczy z sphal do default, jeśli żądana nazwa biblioteki nie jest libc.so lub libm.so.
namespace.name.link.other.allow_all_shared_libs	Wartość logiczna wskazująca, czy wszystkie biblioteki udostępnione można wyszukiwano w przestrzeni nazw other, gdy te biblioteki nie mogą zostanie znaleziony w przestrzeni nazw name. Tej usługi nie można używać z: namespace.name.link.other.shared_libs	namespace.vndk.link.sphal.allow_all_shared_libs = true Oznacza to, że wszystkie nazwy bibliotek mogą przejść przez link zastępczego. z przestrzeni nazw vndk do sphal.

Właściwości przestrzeni nazw

Właściwość	Opis	Przykład
namespace.name.isolated	Wartość logiczna wskazująca, czy dynamiczny tag łączący powinien sprawdzić gdzie znajduje się biblioteka udostępniona. Jeśli isolated ma wartość true, tylko biblioteki udostępnione znajdujących się w jednym z katalogów search.paths (z wyłączeniem podkatalogów) lub należą do jednego z Katalogi permitted.paths (łącznie z podkatalogami) mogą być wczytano. Jeśli isolated ma wartość false (domyślna), wartość dynamiczna tag łączący nie sprawdza ścieżki bibliotek udostępnionych.	namespace.sphal.isolated = true Oznacza to, że tylko biblioteki udostępnione w Wartość search.paths lub mniej niż permitted.paths może wynosić wczytano do przestrzeni nazw sphal.
namespace.name.search.paths	Rozdzielona dwukropkiem lista katalogów do wyszukania udostępnionych biblioteki. Katalogi określone we właściwości search.paths są dodawane na początku do żądanej nazwy biblioteki, jeśli funkcja wywołuje funkcję dlopen() lub Wpisy (DT_NEEDED) nie określają pełnej ścieżki. Katalog określone na początku listy ma wyższy priorytet. Jeśli isolated ma wartość true, biblioteki udostępnione, które znajdują się w jednym z katalogów search.paths (z wyłączeniem podkatalogi) mogą być ładowane niezależnie od permitted.paths usłudze. Jeśli na przykład search.paths to Zawartość /system/${LIB} i permitted.paths jest pusta, Plik /system/${LIB}/libc.so może zostać wczytany, ale Nie można wczytać /system/${LIB}/vndk/libutils.so. Uwaga: ${LIB} to usługa wbudowana. . W przypadku procesów 32-bitowych została zastąpiona przez lib lib64 w przypadku procesów 64-bitowych.	namespace.default.search.paths = /system/${LIB} Wskazuje to, że /system/${LIB} w przypadku bibliotek udostępnionych.
namespace.name.asan.search.paths	Rozdzielona dwukropkiem lista katalogów, w których należy szukać bibliotek udostępnionych, Usługa AddressSanitizer (ASan) jest włączona. namespace.name.search.paths to jest ignorowany, gdy wartość ASan jest .	namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB} Oznacza to, że gdy ASan jest włączony w dynamiczny tag łączący wyszukuje najpierw /data/asan/system/${LIB} i następnie przeszukuje /system/${LIB}.
namespace.name.permitted.paths	Rozdzielana dwukropkiem lista katalogów (łącznie z podkatalogami), gdzie dynamiczny tag łączący może wczytywać biblioteki udostępnione (oprócz search.paths), gdy isolated to true Biblioteki udostępnione, które należą do podkatalogów Plik permitted.paths też może zostać wczytany. Na przykład, jeśli Obecny stan „permitted.paths”: /system/${LIB}, zarówno /system/${LIB}/libc.so, jak i Element /system/${LIB}/vndk/libutils.so może zostać wczytany. Jeśli isolated to false, permitted.paths zostaną zignorowane i wyświetli się ostrzeżenie. Uwaga: permitted.paths to NIE jest dołączany do żądanych nazw bibliotek, gdy dynamiczny tag łączący jest i wyszukanie zasobów wspólnych. Jego głównym celem jest umożliwienie programistom wczytaj biblioteki udostępnione do izolowanej przestrzeni nazw, określając pełną ścieżkę w zasobach wspólnych.	namespace.default.permitted.paths = /system/${LIB}/hw Oznacza to, że biblioteki udostępnione objęte Plik /system/${LIB}/hw można wczytać do izolowanego Przestrzeń nazw default. Na przykład bez atrybutu permitted.paths Nie udało się wczytać listy libaudiohal.so /system/${LIB}/hw/audio.a2dp.default.so w Przestrzeń nazw default.
namespace.name.asan.permitted.paths	Rozdzielona dwukropkiem lista katalogów, do których może wczytać dynamiczny tag łączący biblioteki udostępnione, gdy włączony jest ASan. namespace.name.permitted.paths to jest ignorowana, gdy włączony jest protokół ASan.	namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw Oznacza to, że gdy włączony jest interfejs ASan, biblioteki udostępnione w ramach pakietu /data/asan/system/${LIB}/hw lub Plik /system/${LIB}/hw można wczytać do izolowanego Przestrzeń nazw default.
namespace.name.visible	Wartość logiczna wskazująca, czy program (inny niż libc) może uzyskać uchwyt przestrzeni nazw tagu łączącego z parametrem android_get_exported_namespace() i otwórz bibliotekę udostępnioną w przestrzeni nazw tagu łączącego, przekazując uchwyt do android_dlopen_ext() Jeśli visible to true, android_get_exported_namespace() zawsze zwraca nick, jeśli przestrzeń nazw istnieje. Jeśli visible to false (domyślna), android_get_exported_namespace() zawsze zwraca NULL niezależnie od obecności przestrzeni nazw. Biblioteki udostępnione mogą zostać wczytane do tej przestrzeni nazw tylko wtedy, gdy (1) zostaną zażądane przez inny podmiot przestrzeń nazw tagu łączącego, która ma link zastępczy do tej przestrzeni nazw; (2) są to żądane przez inne biblioteki udostępnione lub pliki wykonywalne w tej przestrzeni nazw.	namespace.sphal.visible = true Oznacza to, że android_get_exported_namespace("sphal") może zwracać prawidłowy uchwyt przestrzeni nazw tagu łączącego.

Tworzenie przestrzeni nazw tagu łączącego

Na Androidzie 11 konfiguracja tagu łączącego jest tworzona w czasie działania w /linkerconfig zamiast zwykłych plików tekstowych w ${android-src}/system/core/rootdir/etc Konfiguracja jest generowana podczas uruchamiania urządzenia w zależności od środowiska wykonawczego, które obejmuje te elementy:

• Jeśli urządzenie obsługuje VNDK
• Docelowa wersja VNDK partycji dostawcy
• Wersja VNDK partycji produktu
• Zainstalowane moduły APEX

Konfiguracja tagu łączącego jest tworzona przez rozwiązanie zależności między przestrzeniami nazw tagu łączącego. Dla: Jeśli na przykład są jakieś aktualizacje modułów APEX, które obejmują aktualizacje zależności, tag łączący odzwierciedlenie tych zmian. Więcej informacji o tworzeniu konfiguracji tagu łączącego znajduje się w ${android-src}/system/linkerconfig

Izolacja przestrzeni nazw tagu łączącego

Istnieją 3 typy konfiguracji. W zależności od wartości PRODUCT_TREBLE_LINKER_NAMESPACES i BOARD_VNDK_VERSION w: BoardConfig.mk, odpowiednia konfiguracja jest generowana podczas uruchamiania urządzenia.

PRODUCT_TREBLE_ LINKER_NAMESPACES	BOARD_VNDK_ VERSION	Wybrana konfiguracja	Wymagania dotyczące VTS
true	current	VNDK	Obowiązkowe w przypadku urządzeń z Androidem 9 lub nowszym
	Puste	VNDK Lite	Obowiązkowe na urządzeniach wprowadzonych na rynek z Androidem 8.x
false	Puste	Legacy	Urządzenia inne niż wysokie

Konfiguracja VNDK Lite izoluje biblioteki współdzielone SP-HAL i VNDK-SP. W Androidzie 8.0 musi być plikiem konfiguracji dynamicznego tagu łączącego, gdy Obecny stan „PRODUCT_TREBLE_LINKER_NAMESPACES”: true.

Konfiguracja VNDK izoluje też biblioteki współdzielone SP-HAL i VNDK-SP. Ponadto ta konfiguracja zapewnia pełną izolację dynamicznego tagu łączącego. Dzięki temu moduły w partycji systemowej nie są zależne od współdzielonej na partycjach dostawcy i odwrotnie.

W Androidzie 8.1 i nowszych konfiguracja VNDK jest konfiguracją domyślną Zdecydowanie zalecamy włączenie pełnej izolacji dynamicznego tagu łączącego za pomocą ustawienia BOARD_VNDK_VERSION do current.

Konfiguracja VNDK

Uwaga: ta sekcja zawiera odwołania do biblioteki RenderScript. Od Androida 12, interfejsy RenderScript API zostały wycofane. Zostaną natomiast nadal działają, ale od producentów urządzeń i komponentów oczekujemy, , aby z czasem nie zapewniać obsługi akceleracji sprzętowej. Aby w pełni wykorzystać możliwości GPU acceleration, AOSP zaleca migrację z RenderScriptu.

Konfiguracja VNDK izoluje zależności biblioteki współdzielonej między partycją systemową a partycjami dostawcy. W porównaniu z konfiguracji wymienionych w poprzedniej podsekcji, różnice są opisane poniżej:

• Procesy platformy

  • default, vndk, Tworzone są przestrzenie nazw sphal i rs.
  • Wszystkie przestrzenie nazw są izolowane.
  • Systemowe biblioteki udostępnione są wczytywane do przestrzeni nazw default.
  • Listy SP-HAL są wczytywane do przestrzeni nazw sphal.
  • Biblioteki udostępnione VNDK-SP wczytane do przestrzeni nazw vndk.

• Procesy dostawców

  • Tworzone są przestrzenie nazw default, vndk i system.
  • Przestrzeń nazw default jest izolowana.
  • Biblioteki udostępnione dostawcy są wczytywane do przestrzeni nazw default.
  • Biblioteki udostępnione VNDK i VNDK-SP są wczytywane do przestrzeni nazw vndk.
  • Zasób LL-NDK i jego zależności są wczytywane do przestrzeni nazw system.

Poniżej przedstawiono relację między przestrzeniami nazw tagu łączącego.

Rysunek 1. Izolacja przestrzeni nazw tagu łączącego (konfiguracja VNDK).

Na powyższym obrazie LL-NDK i VNDK-SP oznaczają następujące znaki biblioteki udostępnione:

• LL-NDK
  • 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
  • libvulkan.so
• VNDK-SP,
  • [e-mail]
  • [e-mail]
  • [e-mail]
  • [e-mail]
  • libRSCpuRef.so
  • libRSDriver.so
  • libRS_internal.so
  • libbase.so
  • libbcinfo.so
  • libc++.so
  • libcutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidlmemory.so
  • libhidltransport.so
  • libhwbinder.so
  • libion.so
  • libutils.so
  • libz.so

Więcej informacji znajdziesz w sekcji /linkerconfig/ld.config.txt z poziomu urządzenia.

Konfiguracja VNDK Lite

Od Androida w wersji 8.0 dynamiczny tag łączący jest skonfigurowany tak, aby izolować SP-HAL i kody łączące Biblioteki udostępnione VNDK-SP w taki sposób, aby ich symbole nie kolidowały z innymi biblioteki współdzielone platformy. Relacja między przestrzeniami nazw tagu łączącego: poniżej.

Rysunek 2. Izolacja przestrzeni nazw tagu łączącego (konfiguracja VNDK Lite)

.

LL-NDK i VNDK-SP oznaczają następujące biblioteki współdzielone:

• LL-NDK
  • libEGL.so
  • libGLESv1_CM.so
  • libGLESv2.so
  • libc.so
  • libdl.so
  • liblog.so
  • libm.so
  • libnativewindow.so
  • libstdc++.so (nie znajduje się w konfiguracji)
  • libsync.so
  • libvndksupport.so
  • libz.so (przeniesiono do VNDK-SP w konfigurację)
• VNDK-SP,
  • [e-mail]
  • [e-mail]
  • [e-mail]
  • [e-mail]
  • libbase.so
  • libc++.so
  • libcutils.so
  • libhardware.so
  • libhidlbase.so
  • libhidlmemory.so
  • libhidltransport.so
  • libhwbinder.so
  • libion.so
  • libutils.so

Tabela poniżej zawiera konfigurację przestrzeni nazw na potrzeby platformy które jest wyodrębnione z sekcji [system] w konfiguracji VNDK Lite.

Przestrzeń nazw	Właściwość	Wartość
default	search.paths	/system/${LIB} /odm/${LIB} /vendor/${LIB} /product/${LIB}
	isolated	false
sphal	search.paths	/odm/${LIB} /vendor/${LIB}
	permitted.paths	/odm/${LIB} /vendor/${LIB}
	isolated	true
	visible	true
	links	default,vndk,rs
	link.default.shared_libs	LL-NDK
	link.vndk.shared_libs	VNDK-SP,
	link.rs.shared_libs	libRS_internal.so
vndk (dla VNDK-SP)	search.paths	/odm/${LIB}/vndk-sp /vendor/${LIB}/vndk-sp /system/${LIB}/vndk-sp-${VER}
	permitted.paths	/odm/${LIB}/hw /odm/${LIB}/egl /vendor/${LIB}/hw /vendor/${LIB}/egl /system/${LIB}/vndk-sp-${VER}/hw
	isolated	true
	visible	true
	links	default
	link.default.shared_libs	LL-NDK
rs (dla RenderScript)	search.paths	/odm/${LIB}/vndk-sp /vendor/${LIB}/vndk-sp /system/${LIB}/vndk-sp-${VER} /odm/${LIB} /vendor/${LIB}
	permitted.paths	/odm/${LIB} /vendor/${LIB} /data (dla skompilowanego jądra RS)
	isolated	true
	visible	true
	links	default,vndk
	link.default.shared_libs	LL-NDK libmediandk.so libft2.so
	link.vndk.shared_libs	VNDK-SP,

Tabela poniżej przedstawia konfigurację przestrzeni nazw dla procesów dostawcy, który pochodzi z sekcji [vendor] w konfiguracji VNDK Lite.

Przestrzeń nazw	Właściwość	Wartość
default	search.paths	/odm/${LIB} /odm/${LIB}/vndk /odm/${LIB}/vndk-sp /vendor/${LIB} /vendor/${LIB}/vndk /vendor/${LIB}/vndk-sp /system/${LIB}/vndk-${VER} /system/${LIB}/vndk-sp-${VER} /system/${LIB} (wycofano) /product/${LIB} (wycofano)
	isolated	false

Więcej informacji znajdziesz w sekcji /linkerconfig/ld.config.txt z poziomu urządzenia.

Historia dokumentu

Zmiany w Androidzie 11

• Na Androidzie 11 statyczne pliki ld.config.*.txt są zostaną usunięte z bazy kodu, a LinkerConfig generuje je w środowisku wykonawczym.

Zmiany w Androidzie 9

• W Androidzie 9 przestrzeń nazw tagu łączącego vndk jest dodawana do dostawcy procesy i biblioteki udostępnione VNDK są odizolowane od domyślnego tagu łączącego przestrzeni nazw.
• Zastąp PRODUCT_FULL_TREBLE bardziej szczegółowym tekstem PRODUCT_TREBLE_LINKER_NAMESPACES
• Android 9 zmienia nazwy tej konfiguracji dynamicznego tagu łączącego .
  

  Android 8.x	Android 9	Opis
  ld.config.txt.in	ld.config.txt	Dla urządzeń z izolacją przestrzeni nazw kreatora linków środowiska wykonawczego
  ld.config.txt	ld.config.vndk_lite.txt	Dla urządzeń z izolacją przestrzeni nazw tagu łączącego VNDK-SP
  ld.config.legacy.txt	ld.config.legacy.txt	Starsze urządzenia z Androidem 7.x lub starszym

• Usuń [e-mail].
• Dodano partycje product i odm.