Przestrzenie nazw dla bibliotek natywnych

W Androidzie 7.0 wprowadzono przestrzenie nazw dla bibliotek natywnych, aby ograniczyć wewnętrzny interfejs API widoczność i rozwiązywanie problemów, kiedy aplikacje przypadkowo korzystają z platformy, do własnych bibliotek. Zobacz poprawki Stabilność z ograniczeniami dotyczącymi prywatnych symboli C/C++ w Androidzie 7.0 Android Post na blogu dla deweloperów zawierający informacje o zmianach w poszczególnych aplikacjach.

Architektura

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

Rysunek 1. Przestrzenie nazw dla bibliotek natywnych.

Przestrzenie nazw dla bibliotek natywnych uniemożliwiają aplikacjom korzystanie z natywnej platformy prywatnej interfejsów API (tak jak w OpenSSL). Eliminuje również sytuacje, w których aplikacje przypadkowe korzystanie z bibliotek platformy zamiast własnych (jak widać, korzystając z libpng). Biblioteki aplikacji mogą mieć trudności z używaniem wewnętrznych przez przypadek (i odwrotnie).

Dodaj dodatkowe biblioteki natywne

Oprócz standardowych publicznych bibliotek natywnych, dostawców krzemów (od Androida 7.0) oraz producenci urządzeń (począwszy od Androida 9) mogą udostępnić dodatkowe biblioteki natywne; są dostępne dla aplikacji, umieszczając je w odpowiednich folderach biblioteki i podając ich listę w plikach .txt.

Foldery w bibliotece to:

• /vendor/lib (w wersji 32-bitowej) i /vendor/lib64 (w wersji 64-bitowej) dla bibliotek dostawców krzemu
• /system/lib (w wersji 32-bitowej) i /system/lib64 (w wersji 64-bitowej) dla bibliotek producentów urządzeń

Pliki .txt:

• /vendor/etc/public.libraries.txt w przypadku bibliotek od dostawców krzemu
• /system/etc/public.libraries-COMPANYNAME.txt w przypadku bibliotek producentów urządzeń, gdzie COMPANYNAME odnosi się do nazwy producenta (np. awesome.company). Wartość COMPANYNAME musi pasować do: [A-Za-z0-9_.-]+; znaki alfanumeryczne, _, . (kropka) i -. To możliwe mieć na urządzeniu wiele takich plików .txt, jeśli niektóre biblioteki pochodzą z rozwiązania zewnętrznego. dostawców usług.

Biblioteki natywne w partycji system, które są upubliczniane przez producentów urządzeń MUSI mieć nazwę lib*COMPANYNAME.so, np. libFoo.awesome.company.so. Innymi słowy, wiadomości libFoo.so bez sufiksu nazwy firmy NIE MOGĄ być publikowane publicznie. Pole COMPANYNAME w nazwie pliku biblioteki MUSI być zgodne z COMPANYNAME w .txt z nazwą biblioteki.

Biblioteki natywne, które wchodzą w skład AOSP, NIE MOGĄ być publiczne (z wyjątkiem bibliotek standardowych) publicznych bibliotek natywnych, które domyślnie są publiczne). Tylko biblioteki dodane przez dostawców krzemów i producentów urządzeń.

Począwszy od Androida 8.0, biblioteki publiczne dostawców obejmują te dodatkowe Ograniczenia i wymagane konfiguracje:

1. Biblioteka natywna w dostawcy musi być odpowiednio oznaczona etykietą, dostępne dla aplikacji. Jeśli jakakolwiek aplikacja wymaga dostępu (w tym aplikacje innych firm), biblioteka musi być oznaczona etykietą same_process_hal_file w określonym przez dostawcę pliku file_contexts 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, ani bezpośrednio, ani pośrednio przez swoje zależności, nie może zależą od bibliotek systemowych innych niż biblioteki VNDK-SP i LLNDK. Znajdź listę Biblioteki VNDK-SP i LLNDK w development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv

Począwszy od Androida 15 (AOSP Experiment) biblioteki publiczne dostawców można umieszczać w dostawcy APEX. Po spakowaniu w APEX dostawcy podaj listę bibliotek we właściwości provideNativeLibs w pliku manifestu APEX.

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

Ta funkcja jest włączona tylko w przypadku aplikacji kierowanych na pakiet SDK w wersji 24 lub nowszej. w celu uzyskania zgodności wstecznej, zapoznaj się z tabelą 1.Czego możesz się spodziewać w przypadku łączenia aplikacji z prywatnymi bibliotekami natywnymi Lista bibliotek natywnych Androida dostępnych dla aplikacji (nazywana też publicznych bibliotek natywnych) są wymienione w sekcji 3.1.1 CDD. Aplikacje kierowane na wersję 24 lub i korzystanie z bibliotek niepublicznych należy zaktualizować. Zobacz NDK Aplikacje łączące się z bibliotekami platformy , gdzie znajdziesz więcej informacji.

Zaktualizuj aplikacje 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 natywnych zasobów wspólnych, korzystając z tagu <uses-native-library> w manifeście aplikacji. Jeśli jakakolwiek część żądanego Biblioteka nie istnieje na urządzeniu, oznacza to, że aplikacja nie jest zainstalowana. Zainstalowane aplikacje mogą udostępniać tylko natywne biblioteki udostępnione, o które poprosili. Oznacza to, że Aplikacje nie mają dostępu do natywnych bibliotek udostępnionych, które nie są widoczne w manifeście aplikacji.