Przestrzenie nazw bibliotek natywnych

W Androidzie 7.0 wprowadzono przestrzenie nazw dla bibliotek natywnych, aby ograniczyć widoczność wewnętrznych interfejsów 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 Poprawa stabilności dzięki ograniczeniom dotyczącym prywatnych symboli C/C++ w Androidzie 7.0.

Architektura

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

Rysunek 1. Przestrzenie nazw bibliotek natywnych.

Przestrzenie nazw bibliotek natywnych uniemożliwiają aplikacjom korzystanie z prywatnych interfejsów API platformy natywnej (jak w przypadku OpenSSL). Eliminuje to też sytuacje, w których aplikacje przypadkowo używają bibliotek platformy zamiast własnych (jak w przypadku libpng). Biblioteki aplikacji nie mogą 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 .Wystarczy, że umieszczą je w odpowiednich folderach bibliotek i wyraźnie wymienią w plikach TXT.

Foldery biblioteki to:

• /vendor/lib (w przypadku bibliotek 32-bitowych) i /vendor/lib64 (w przypadku bibliotek 64-bitowych) w przypadku bibliotek dostarczanych przez producentów układów
• /system/lib (w przypadku wersji 32-bitowej) i /system/lib64 (w przypadku wersji 64-bitowej) w przypadku bibliotek od producentów urządzeń

Pliki TXT to:

• /vendor/etc/public.libraries.txt w przypadku bibliotek od dostawców krzemu.
• /system/etc/public.libraries-COMPANYNAME.txt w przypadku bibliotek od producentów urządzeń, gdzie COMPANYNAME to nazwa producenta (np. awesome.company). COMPANYNAME musi być zgodne z [A-Za-z0-9_.-]+; znaki alfanumeryczne, _, . (kropka) i -. Na urządzeniu może być kilka takich plików tekstowych, jeśli niektóre biblioteki pochodzą od zewnętrznych dostawców rozwiązań.

Biblioteki natywne w partycji system udostępnione przez producentów urządzeń MUSZĄ mieć nazwę lib*COMPANYNAME.so, np. libFoo.awesome.company.so. Innymi słowy, adres libFoo.so bez sufiksu z nazwą firmy NIE MOŻE być upubliczniony. Symbol COMPANYNAME w nazwie pliku biblioteki MUSI być zgodny z symbolem COMPANYNAME w nazwie pliku tekstowego, 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 krzemu lub producentów urządzeń.

Od Androida 8.0 publiczne biblioteki dostawców mają te dodatkowe ograniczenia i wymagania dotyczące konfiguracji:

1. Biblioteka natywna w folderze dostawcy musi być odpowiednio oznaczona, aby aplikacje mogły mieć do niej dostęp. 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 za pomocą 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 development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.

Od Androida 15 publiczne biblioteki dostawców mogą być umieszczane w APEX-ie dostawcy. Jeśli są one spakowane w APEX dostawcy, wymień biblioteki w provideNativeLibs w pliku manifestu APEX.

Zaktualizuj aplikacje, aby nie korzystały z 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 z wcześniejszymi wersjami 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 Androida 24 lub nowszego, które korzystają z bibliotek niepublicznych, powinny zostać zaktualizowane. Więcej informacji znajdziesz w artykule NDK Apps Linking to Platform Libraries (Aplikacje NDK łączące się z bibliotekami platformy).

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

Aplikacje, których docelowa wersja SDK to 31 (Android 12) lub nowsza, muszą wyraźnie określać zależności od natywnych bibliotek współdzielonych za pomocą tagu <uses-native-library> w pliku manifestu aplikacji. Jeśli na urządzeniu nie ma żadnej części żądanej biblioteki, aplikacja nie zostanie zainstalowana. Po zainstalowaniu aplikacji otrzymują one tylko natywne biblioteki współużytkowane, o które poprosiły. Oznacza to, że aplikacje nie mogą uzyskiwać dostępu do natywnych bibliotek udostępnionych, które nie są wymienione w pliku manifestu aplikacji.