Пространства имен для собственных библиотек

В Android 7.0 появились пространства имен для нативных библиотек, чтобы ограничить внутреннюю видимость API и разрешить ситуации, когда приложения случайно используют библиотеки платформы вместо своих собственных. См. публикацию в блоге разработчиков Android 7.0, посвященную улучшению стабильности с помощью ограничений частных символов C/C++ , чтобы узнать об изменениях, связанных с конкретным приложением.

Архитектура

В Android 7.0 и выше системные библиотеки отделены от библиотек приложений.

Пространства имен для нативных библиотек

Рисунок 1. Пространства имен для нативных библиотек

Пространства имен для собственных библиотек не позволяют приложениям использовать собственные API-интерфейсы частных платформ (как это было сделано с OpenSSL). Это также устраняет ситуации, когда приложения случайно используют библиотеки платформы вместо своих собственных (как видно из libpng ). Библиотекам приложений сложно случайно использовать внутренние системные библиотеки (и наоборот).

Добавление дополнительных нативных библиотек

В дополнение к стандартным общедоступным нативным библиотекам поставщики микросхем (начиная с Android 7.0) и производители устройств (начиная с Android 9) могут предоставлять дополнительные нативные библиотеки, доступные для приложений, помещая их в соответствующие папки библиотек и явно перечисляя их в .txt. файлы.

Папки библиотеки:

  • /vendor/lib (для 32-разрядной версии) и /vendor/lib64 (для 64-разрядной версии) для библиотек от поставщиков микросхем.
  • /system/lib (для 32-разрядной версии) и /system/lib64 (для 64-разрядной версии) для библиотек от производителей устройств.

Файлы .txt:

  • /vendor/etc/public.libraries.txt для библиотек от поставщиков микросхем.
  • /system/etc/public.libraries-COMPANYNAME.txt для библиотек от производителей устройств, где COMPANYNAME относится к имени производителя (например, awesome.company ). COMPANYNAME должно совпадать с [A-Za-z0-9_.-]+ ; буквенно-цифровые символы, _, . (точка) и -. В устройстве может быть несколько таких файлов .txt, если некоторые библиотеки получены от внешних поставщиков решений.

Нативные библиотеки в system разделе, опубликованные производителями устройств, ДОЛЖНЫ называться lib*COMPANYNAME.so , например, libFoo.awesome.company.so . Другими словами, libFoo.so без суффикса названия компании НЕ ДОЛЖЕН публиковаться. COMPANYNAME в имени файла библиотеки ДОЛЖНО совпадать с COMPANYNAME в имени файла txt, в котором указано имя библиотеки.

Нативные библиотеки, являющиеся частью AOSP, НЕ ДОЛЖНЫ быть общедоступными (за исключением стандартных общедоступных нативных библиотек, которые являются общедоступными по умолчанию). Только дополнительные библиотеки, добавленные поставщиками микросхем или производителями устройств, могут быть доступны для приложений.

Начиная с Android 8.0, общедоступные библиотеки поставщиков имеют следующие дополнительные ограничения и обязательные настройки:

  1. Собственная библиотека поставщика должна быть правильно помечена, чтобы она была доступна для приложений. Если доступ требуется каким-либо приложениям (в том числе сторонним приложениям), библиотека должна быть помечена как same_process_hal_file в файле file_contexts конкретного поставщика следующим образом:
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    , где libnative.so — имя собственной библиотеки.
  2. Библиотека ни напрямую, ни транзитивно через свои зависимости не должна зависеть от других системных библиотек, кроме библиотек VNDK-SP и LLNDK. Найдите список библиотек VNDK-SP и LLNDK в development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

Обновление приложений, чтобы они не использовали непубличные нативные библиотеки

Эта функция включена только для приложений, предназначенных для SDK версии 24 или более поздней; для обратной совместимости см. Таблицу 1. Чего ожидать, если ваше приложение линкуется с частными нативными библиотеками . Список нативных библиотек Android, доступных для приложений (также известных как общедоступные нативные библиотеки), приведен в разделе CDD 3.1.1. Приложения, предназначенные для версии 24 или более поздней версии и использующие закрытые библиотеки, должны быть обновлены. Дополнительные сведения см. в разделе Связывание приложений NDK с библиотеками платформ .

Обновление приложений для их зависимостей родной библиотеки

Приложения, предназначенные для SDK версии 31 (Android 12) или более поздней версии, должны явно указывать собственные зависимости общей библиотеки с помощью <uses-native-library> в манифесте приложения. Если какая-либо часть запрошенной библиотеки не существует на устройстве, приложение не установлено. Когда приложения установлены, им предоставляются только запрошенные собственные общие библиотеки. Это означает, что приложения не могут получить доступ к собственным общим библиотекам, которые не отображаются в манифесте приложения.