Przestrzenie nazw dla bibliotek natywnych

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.

Przestrzenie nazw dla bibliotek natywnych

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ń, gdzie COMPANYNAME 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:

  1. 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 pliku file_contexts specyficznym dla dostawcy w następujący 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 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.