Przestrzenie nazw dla bibliotek natywnych

W Androidzie 7.0 wprowadzono przestrzenie nazw dla bibliotek natywnych, aby ograniczyć widoczność interfejsów API wewnętrznych i rozwiązać problemy, które występują, gdy aplikacje przypadkowo używają bibliotek platformy zamiast własnych. Aby dowiedzieć się więcej o zmianach dotyczących konkretnych aplikacji, przeczytaj post na blogu dla deweloperów aplikacji na Androida Zwiększanie stabilności dzięki ograniczeniom symboli prywatnych w C/C++ w Androidzie 7.0.

Architektura

W Androidzie 7.0 i nowszych biblioteki systemowe są oddzielone od bibliotek aplikacji.

Rysunek 1. Przestrzeń nazw dla bibliotek natywnych.

Nazwy ojczyste bibliotek natywnych uniemożliwiają aplikacjom korzystanie z na platformie natywnych interfejsów API (jak w przypadku OpenSSL). Zapobiega też sytuacjom, w których aplikacje przypadkowo używają bibliotek platformy zamiast własnych (jak w przypadku libpng). Biblioteki aplikacji rzadko używają przypadkowo wewnętrznych bibliotek systemowych (i na odwrót).

Dodaj dodatkowe biblioteki natywne

Oprócz standardowych publicznych bibliotek natywnych dostawcy układów scalonych (od Androida 7.0) i producenci urządzeń (od Androida 9) mogą udostępniać aplikacjom dodatkowe biblioteki natywne, umieszczając je w odpowiednich folderach bibliotek i wyraźnie wymieniając w plikach .txt.

Foldery biblioteki to:

• /vendor/lib (dla wersji 32-bitowej) i /vendor/lib64 (dla wersji 64-bitowej) dla bibliotek od dostawców układów
• /system/lib (wersja 32-bitowa) i /system/lib64 (wersja 64-bitowa) w przypadku bibliotek producentów urządzeń

Pliki .txt to:

• /vendor/etc/public.libraries.txt dla bibliotek od dostawców układów scalonych.
• /system/etc/public.libraries-COMPANYNAME.txt w przypadku bibliotek od producentów urządzeń, gdzie COMPANYNAME odnosi się do nazwy producenta (np. awesome.company). COMPANYNAME musi być zgodny z [A-Za-z0-9_.-]+; znaki alfanumeryczne, _, . (kropka) i -. Na urządzeniu można mieć wiele takich plików .txt, jeśli niektóre biblioteki pochodzą od zewnętrznych dostawców.

Biblioteki natywne na partycji system, które są udostępnione przez producentów urządzeń jako publiczne, MUSZĄ mieć nazwę lib*COMPANYNAME.so, na przykład libFoo.awesome.company.so. Innymi słowy, libFoo.so bez przyrostka nazwy firmy NIE MOŻE być udostępniona publicznie. Parametr COMPANYNAME w nazwie pliku biblioteki MUSI być zgodny z polem COMPANYNAME w nazwie pliku tekstowego, w której znajduje się nazwa biblioteki.

Biblioteki natywne, które są częścią AOSP, NIE MOGĄ być publiczne (z wyjątkiem standardowych bibliotek natywnych, które są publiczne domyślnie). Dostęp do aplikacji mogą mieć tylko dodatkowe biblioteki dodane przez dostawców układów scalonych lub producentów urządzeń.

Od Androida w wersji 8.0 biblioteki publiczne dostawców obowiązują te dodatkowe ograniczenia i wymagana konfiguracja:

1. Biblioteka natywna dostawcy musi być odpowiednio oznaczona, aby aplikacje mogły z niej korzystać. Jeśli jakakolwiek aplikacja (w tym aplikacje innych firm) wymaga dostępu, biblioteka musi być oznaczona jako same_process_hal_file w pliku file_contexts konkretnego dostawcy w ten sposób:

   /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0

   , gdzie libnative.so to nazwa biblioteki natywnej.
2. Biblioteka nie może bezpośrednio ani pośrednio (poprzez zależności) zależeć od bibliotek systemowych innych niż biblioteki VNDK-SP i LLNDK. Znajdź listę bibliotek VNDK-SP i LLNDK w witrynie development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.

Od Androida 15 biblioteki publiczne dostawcy można umieszczać w bibliotece APEX dostawcy. Jeśli biblioteki są zapakowane w APEX dostawcy, w pliku manifestu APEX wskaż je jako element provideNativeLibs.

Zaktualizuj aplikacje, aby nie używały niepublicznych bibliotek natywnych

Ta funkcja jest włączona tylko w przypadku aplikacji przeznaczonych na pakiet SDK w wersji 24 lub nowszej. Informacje o zgodności wstecznej znajdziesz w tabeli 1. Czego możesz się spodziewać, jeśli Twoja aplikacja jest powiązana z prywatnymi natywnymi bibliotekami. Lista bibliotek natywnych Androida dostępnych dla aplikacji (nazywanych też publicznymi bibliotekami natywnymi) znajduje się w sekcji 3.1.1 CDD. Aplikacje kierowane na Androida 24 lub nowszego, które korzystają z niepublicznych bibliotek, powinny zostać zaktualizowane. Więcej informacji znajdziesz w artykule NDK: aplikacje łączące się z bibliotekami platformy .

Aktualizowanie aplikacji pod kątem zależności bibliotek natywnych

Aplikacje kierowane na pakiet SDK w wersji 31 (Android 12) lub nowszej muszą wyraźnie określić zależności od natywnych bibliotek udostępnionych za pomocą tagu <uses-native-library> w manifeście aplikacji. Jeśli jakakolwiek część żądanej biblioteki nie istnieje na urządzeniu, aplikacja nie jest zainstalowana. Po zainstalowaniu aplikacji są one tylko udostępniane natywnym bibliotekom współdzielonym, których dotyczy żądanie. Oznacza to, że aplikacje nie mają dostępu do natywnych bibliotek udostępnionych, które nie występują w manifeście aplikacji.