Przestrzenie nazw bibliotek natywnych

W Androidzie 7.0 wprowadzono przestrzenie nazw dla bibliotek natywnych, aby ograniczyć widoczność wewnętrznego interfejsu API i rozwiązać sytuacje, w których aplikacje przypadkowo używają bibliotek platformy zamiast własnych. Więcej informacji o zmianach dotyczących aplikacji znajdziesz w poście na blogu dla deweloperów aplikacji na Androida pt. Zwiększanie stabilności dzięki ograniczeniom dotyczącym prywatnych symboli C/C++ w Androidzie 7.0.

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 prywatnych natywnych interfejsów API platformy (jak to miało miejsce w przypadku OpenSSL). Eliminują też sytuacje, w których aplikacje przypadkowo używają bibliotek platformy zamiast własnych (jak to miało miejsce w przypadku libpng). Bibliotekom aplikacji trudno jest przypadkowo używać wewnętrznych bibliotek systemowych (i odwrotnie).

Dodawanie dodatkowych bibliotek natywnych

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ć dodatkowe biblioteki natywne, do których aplikacje mają dostęp, umieszczając je w odpowiednich folderach bibliotek i wyraźnie wymieniając je w plikach .txt.

Foldery bibliotek to:

• /vendor/lib (dla 32-bitowych) i /vendor/lib64 (dla 64-bitowych) w przypadku bibliotek od dostawców układów scalonych,
• /system/lib (dla 32-bitowych) i /system/lib64 (dla 64-bitowych) w przypadku bibliotek od producentów urządzeń.

Pliki .txt to:

• /vendor/etc/public.libraries.txt w przypadku bibliotek od dostawców układów scalonych
• /system/etc/public.libraries-COMPANYNAME.txt w przypadku bibliotek od producentów urządzeń, gdzie COMPANYNAME to nazwa producenta (np. awesome.company). COMPANYNAME musi pasować do wzorca [A-Za-z0-9_.-]+ (znaki alfanumeryczne, _, . (kropka) i -). (dot) and -. It is possible to have multiple such .txt files in a device if some libraries are from external solution providers.

Biblioteki natywne w partycji system, które są udostępniane publicznie przez producentów urządzeń MUSZĄ mieć nazwę lib*COMPANYNAME.so, np. libFoo.awesome.company.so. Innymi słowy, biblioteka libFoo.so bez sufiksu z nazwą firmy NIE MOŻE być udostępniana publicznie. COMPANYNAME w nazwie pliku biblioteki MUSI być zgodna z COMPANYNAME w nazwie pliku txt, w którym znajduje się nazwa biblioteki.

Biblioteki natywne, które są częścią AOSP, NIE MOGĄ być udostępniane publicznie (z wyjątkiem standardowych publicznych bibliotek natywnych, które są publiczne domyślnie). Aplikacje mogą mieć dostęp tylko do dodatkowych bibliotek dodanych przez dostawców układów scalonych lub producentów urządzeń.

Od Androida 8.0 publiczne biblioteki dostawców mają te dodatkowe ograniczenia i wymagane konfiguracje:

1. Biblioteka natywna w folderze dostawcy musi być odpowiednio oznaczona, aby była dostępna dla aplikacji. Jeśli dostęp jest wymagany przez jakiekolwiek aplikacje (w tym aplikacje innych firm), biblioteka musi być oznaczona jako same_process_hal_file w pliku file_contexts specyficznym dla 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, bezpośrednio lub pośrednio przez swoje zależności, nie może zależeć od bibliotek systemowych innych niż biblioteki VNDK-SP i LLNDK. Listę bibliotek VNDK-SP i LLNDK znajdziesz w pliku development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.

Od Androida 15 publiczne biblioteki dostawców można umieścić w APEX dostawcy. Gdy biblioteki są spakowane w APEX dostawcy, wymień je we właściwości provideNativeLibs w pliku manifestu APEX.

Aktualizowanie aplikacji, aby nie korzystały z niepublicznych bibliotek natywnych

Ta funkcja jest włączona tylko w przypadku aplikacji kierowanych na wersję SDK 24 lub nowszą. Informacje o zgodności wstecznej znajdziesz w tabeli 1.Czego możesz się spodziewać, jeśli Twoja aplikacja jest połączona z prywatnymi bibliotekami natywnymi. Lista bibliotek natywnych Androida dostępnych dla aplikacji (znanych też jako publiczne biblioteki natywne) znajduje się w sekcji 3.1.1 dokumentu CDD. Aplikacje kierowane na wersję 24 lub nowszą, które korzystają z bibliotek niepublicznych, należy zaktualizować. Więcej informacji znajdziesz w artykule NDK Aplikacje łączące się z bibliotekami platformy .

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

Aplikacje kierowane na wersję SDK 31 (Android 12) lub nowszą muszą wyraźnie określać swoje zależności od natywnych bibliotek współdzielonych za pomocą tagu <uses-native-library> w pliku manifestu aplikacji. Jeśli jakakolwiek część żądanej biblioteki nie istnieje na urządzeniu, aplikacja nie zostanie zainstalowana. Po zainstalowaniu aplikacji są udostępniane tylko natywne biblioteki współdzielone, o które aplikacja poprosiła. Oznacza to, że aplikacje nie mogą uzyskiwać dostępu do natywnych bibliotek współdzielonych, które nie są wymienione w pliku manifestu aplikacji.