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

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, установленная на другом разделе, может изменять значения ресурсов приложения во время выполнения. Дополнительную информацию о функциях RRO см. в разделе «Изменение значений ресурсов приложения во время выполнения» .