W systemie Android 7.0 wprowadzono przestrzenie nazw dla bibliotek natywnych, aby ograniczyć widoczność wewnętrznego interfejsu API i rozwiązać sytuacje, w których aplikacje przypadkowo korzystają z bibliotek platformy zamiast własnych. Zobacz wpis dotyczący poprawy stabilności dzięki ograniczeniom prywatnych symboli C/C++ w blogu dla programistów systemu Android 7.0, aby zapoznać się ze zmianami specyficznymi dla aplikacji.
Architektura
W systemie Android 7.0 i nowszych wersjach biblioteki systemowe są oddzielone od bibliotek aplikacji.

Rysunek 1. Przestrzenie nazw dla bibliotek natywnych
Przestrzenie nazw bibliotek natywnych uniemożliwiają aplikacjom korzystanie z natywnych interfejsów API platformy prywatnej (tak jak miało to miejsce w przypadku OpenSSL). Eliminuje także sytuacje, w których aplikacje przypadkowo korzystają z bibliotek platformy zamiast z własnych (o czym świadczy libpng
). Bibliotekom aplikacji trudno jest przypadkowo korzystać z wewnętrznych bibliotek systemowych (i odwrotnie).
Dodanie dodatkowych bibliotek natywnych
Oprócz standardowych publicznych bibliotek natywnych dostawcy krzemu (począwszy od Androida 7.0) i producenci urządzeń (począwszy od Androida 9) mogą zdecydować się na udostępnienie aplikacjom dodatkowych bibliotek natywnych, umieszczając je w odpowiednich folderach bibliotek i wyraźnie wymieniając je w formacie .txt akta.
Foldery biblioteki to:
-
/vendor/lib
(dla wersji 32-bitowej) i/vendor/lib64
(dla wersji 64-bitowej) dla bibliotek od dostawców krzemu -
/system/lib
(dla wersji 32-bitowej) i/system/lib64
(dla wersji 64-bitowej) dla bibliotek producentów urządzeń
Pliki .txt to:
-
/vendor/etc/public.libraries.txt
dla bibliotek od dostawców krzemu -
/system/etc/public.libraries-COMPANYNAME.txt
dla bibliotek producentów urządzeń, gdzieCOMPANYNAME
odnosi się do nazwy producenta (np.awesome.company
).COMPANYNAME
musi pasować do[A-Za-z0-9_.-]+
; znaki alfanumeryczne, _, . (kropka) i -. Możliwe jest posiadanie wielu takich plików .txt na urządzeniu, jeśli niektóre biblioteki pochodzą od zewnętrznych dostawców rozwiązań.
Biblioteki natywne na partycji system
, które są udostępniane publicznie przez producentów urządzeń MUSZĄ mieć nazwę lib*COMPANYNAME.so
, na przykład libFoo.awesome.company.so
. Innymi słowy, plik libFoo.so
bez przyrostka nazwy firmy NIE MOŻE być upubliczniany. COMPANYNAME
w nazwie pliku biblioteki MUSI odpowiadać NAZWIE COMPANYNAME
w nazwie pliku txt, w którym wymieniona jest nazwa biblioteki.
Biblioteki natywne będące częścią AOSP NIE WOLNO upubliczniać (z wyjątkiem standardowych publicznych bibliotek natywnych, które są domyślnie publiczne). Tylko dodatkowe biblioteki dodane przez dostawców układów krzemowych lub producentów urządzeń mogą być udostępniane aplikacjom.
Począwszy od systemu Android 8.0 biblioteki publiczne dostawców mają następujące dodatkowe ograniczenia i wymagane konfiguracje:
- Natywna biblioteka 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 ten
same_process_hal_file
w plikufile_contexts
specyficznym dla dostawcy w następujący sposób:/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
gdzielibnative.so
to nazwa biblioteki natywnej. - Biblioteka, bezpośrednio lub przechodnio poprzez swoje zależności, nie może zależeć od bibliotek systemowych innych niż biblioteki VNDK-SP i LLNDK. Znajdź listę bibliotek VNDK-SP i LLNDK pod
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv
.
Aktualizowanie aplikacji tak, aby nie korzystały z niepublicznych bibliotek natywnych
Ta funkcja jest włączona tylko dla aplikacji przeznaczonych dla zestawu SDK w wersji 24 lub nowszej; Informacje o kompatybilności wstecznej można znaleźć w Tabeli 1. Czego można się spodziewać, jeśli aplikacja łączy się z prywatnymi bibliotekami natywnymi . Lista natywnych bibliotek Androida dostępnych dla aplikacji (zwanych także publicznymi bibliotekami natywnymi) znajduje się w sekcji CDD 3.1.1. Należy zaktualizować aplikacje przeznaczone dla wersji 24 lub nowszej i korzystające z bibliotek niepublicznych. Więcej szczegółów można znaleźć w artykule Łączenie aplikacji NDK z bibliotekami platform .
Aktualizowanie aplikacji pod kątem natywnych zależności bibliotek
Aplikacje przeznaczone dla zestawu SDK w wersji 31 (Android 12) lub nowszej muszą jawnie określić swoje natywne zależności od bibliotek współdzielonych, używając tagu <uses-native-library>
w manifeście aplikacji. Jeśli na urządzeniu nie ma żadnej części żądanej biblioteki, aplikacja nie zostanie zainstalowana. Po zainstalowaniu aplikacji udostępniane są tylko natywne biblioteki współdzielone, o które poprosiły. Oznacza to, że aplikacje nie mają dostępu do natywnych bibliotek współdzielonych, które nie pojawiają się w manifeście aplikacji.