Обзор конфигурации

AOSP предлагает следующие варианты хранения информации о конфигурации на устройстве:

• Свойства системы
• Конфигурация устройства ранней загрузки
• Свойства уровня абстрагирования оборудования (HAL)
• XML-файлы конфигурации системы
• Наложения ресурсов (статические и во время выполнения).

Свойства системы

Системные свойства – это пары "ключ-значение", хранящиеся в build.propглобальном словаре. Свойства системы – это ресурсы, которые легко использовать и которые не требуют высокой производительности. При использовании системных свойств вам не нужно применять межпроцессное взаимодействие (IPC), даже если системное свойство используется несколькими процессами. Однако системные свойства похожи на глобальные переменные и могут быть опасны при неправильном использовании. Неправильное использование системных свойств может привести к проблемам, например уязвимостям безопасности и недоступности приложений для пользователей. Прежде чем использовать системные свойства для хранения информации о конфигурации, рассмотрите другие варианты.

Дополнительную информацию о системных свойствах можно найти в разделе Как добавить системные свойства.

Конфигурация устройства на раннем этапе загрузки

В Android 17 и более поздних версиях сервис init_dev_config поддерживает настройку устройств и инициализацию системных свойств. Этот динамический архитектурный механизм запускается автоматически на ранних этапах загрузки.

Если образ системы или поставщика должен поддерживать несколько вариантов оборудования, значения конфигурации не всегда можно жестко закодировать во время сборки. Сервис init_dev_config выполняется на этапе early-init, непосредственно перед apexd-bootstrap, что позволяет поставщикам проверять состояние оборудования (например, с помощью аргументов загрузчика операционной системы, рано подключенных разделов или таблиц конфигурации оборудования) и динамически инициализировать системные свойства до инициализации зависимых сервисов и библиотек.

Интеграция сервисов и жизненный цикл

Сервис init_dev_config по умолчанию определяется в системном файле init.rc и выполняется синхронно во время early-init, до apexd-bootstrap. Интеграторам не нужно заявлять о новом сервисе init.

Вместо этого существующий сервис использует расширение свойства в пути к исполняемому файлу, отделяя объявление системного сервиса от двоичного файла поставщика. Интеграторы указывают путь к двоичному файлу поставщика с помощью свойства ro.vendor.init_dev_config.path и настраивают его с необходимыми ярлыками и разрешениями SELinux.

Требования к реализации для поставщиков

Чтобы интегрировать init_dev_config:

1. Настройте путь к исполняемому файлу поставщика во время сборки, используя PRODUCT_VENDOR_PROPERTIES. Указанный путь к двоичному файлу должен быть действительным путем к двоичному файлу, установленному в системе:

   PRODUCT_VENDOR_PROPERTIES += \
       ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
   

   Если это свойство не задано, init пропускает выполнение службы и загрузка продолжается обычным образом.

2. Поскольку сервис запускается до apexd-bootstrap, полные библиотеки Bionic, предоставленные APEX, ещё недоступны. В Android.bp задайте следующие значения: bootstrap: true

   rust_binary {
       name: "init_dev_config",
       vendor: true,
       srcs: ["src/main.rs"],
       rustlibs: [
           "librustutils",
       ],
       bootstrap: true,
   }
   

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

   use rustutils::system_properties;
   
   fn main() {
       let hw_sku = read_hardware_sku();
   
       // Dynamically initialize vendor-specific properties:
       let display_type = match hw_sku {
           1 => "oled",
           _ => "lcd",
       };
       system_properties::write("vendor.display.panel_type", display_type)
           .expect("Failed to set vendor display property");
   }
   

4. Добавьте к исполняемому файлу поставщика ярлык init_dev_config_exec:

    /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0
   

5. Предоставьте домену init_dev_config разрешение на установку необходимых типов свойств:

    set_prop(init_dev_config, vendor_my_sku_prop)
   

Информацию о том, как использовать init_dev_config для активации и отключения APEX, можно найти в статье Выбор APEX поставщика при загрузке.

Свойства HAL

Если источником достоверной информации о конфигурации является аппаратный компонент устройства, то HAL для этого компонента должен предоставлять информацию. Определите новый метод HAL в существующем HAL для доступа к конфигурации. Дополнительную информацию о разработке HAL можно найти в статье AIDL для HAL.

XML-файлы конфигурации системы

Если данные конфигурации статичны, но имеют сложную структуру, используйте XML или другие подобные форматы. Убедитесь, что схема файла не меняется. Для XML-файлов можно использовать xsd_config, чтобы схема оставалась стабильной и можно было воспользоваться автоматически сгенерированным парсером XML.

Переопределение ресурсов

Вы можете использовать наложения ресурсов, чтобы настроить продукт. Существует два типа оверлеев ресурсов:

• Стандартный оверлей ресурсов, используемый для настройки продукта во время сборки. Информацию о стандартных наложениях ресурсов можно найти в статье Как настроить сборку с помощью наложений ресурсов.

• Переопределение ресурсов во время выполнения (RRO) используется для изменения значений ресурсов целевого пакета во время выполнения. Например, приложение, установленное в образе системы, может менять свое поведение в зависимости от значения ресурса. Вместо того чтобы задавать значение ресурса в коде во время сборки, RRO, установленное в другом разделе, может изменять значения ресурсов приложения во время выполнения. Подробнее о переопределении ресурсов во время выполнения…