ConfigStore HAL

В Android 10 ConfigStore HAL использует флаги сборки для хранения значений конфигурации в разделе vendor , а служба в system разделе обращается к этим значениям через HIDL (это также актуально в Android 9). Однако из-за высокого потребления памяти и сложности использования ConfigStore HAL был объявлен устаревшим.

HAL-раздел ConfigStore остаётся в AOSP для поддержки разделов устаревших поставщиков. На устройствах под управлением Android 10 и более поздних версий surfaceflinger сначала считывает системные свойства; если системное свойство не определено для элемента конфигурации в файле `SurfaceFlingerProperties.sysprop`, SurfaceFlinger возвращается к HAL-разделу ConfigStore.

В Android 8.0 монолитная ОС Android разделена на общие разделы ( system.img ) и разделы, специфичные для оборудования ( vendor.img и odm.img ). В результате этого изменения условная компиляция должна быть удалена из модулей, установленных в системный раздел, и такие модули должны определять конфигурацию системы во время выполнения (и вести себя по-разному в зависимости от этой конфигурации).

ConfigStore HAL предоставляет набор API для доступа к элементам конфигурации, доступным только для чтения, используемым для настройки платформы Android. На этой странице описывается структура ConfigStore HAL (и почему системные свойства не использовались для этой цели); на других страницах этого раздела подробно описан интерфейс HAL , реализация службы и использование на стороне клиента , все на примере surfaceflinger . Справку по классам интерфейса ConfigStore см. в разделе Добавление классов и элементов интерфейса .

Почему бы не использовать системные свойства?

Мы рассматривали возможность использования системных свойств, но обнаружили несколько фундаментальных проблем, в том числе:

  • Ограничения на длину значений. Системные свойства имеют жёсткие ограничения на длину своих значений (92 байта). Кроме того, поскольку эти ограничения напрямую проявляются в приложениях Android в виде макросов на языке C, увеличение длины может вызвать проблемы с обратной совместимостью.
  • Поддержка типов отсутствует. Все значения по сути являются строками, и API просто преобразуют строку в тип int или bool . Другие составные типы данных (например, массивы и структуры) должны кодироваться/декодироваться клиентами (например, "aaa,bbb,ccc" можно кодировать как массив из трёх строк).
  • Перезапись. Поскольку системные свойства, доступные только для чтения, реализованы как свойства с однократной записью, поставщики/ODM-разработчики, желающие переопределить значения, доступные только для чтения, определённые AOSP, должны импортировать собственные значения, доступные только для чтения, до импорта значений, доступных только для чтения, определённых AOSP. Это, в свою очередь, приводит к переопределению перезаписываемых значений, определённых поставщиком, значениями, определёнными AOSP.
  • Требования к адресному пространству. Системные свойства занимают относительно большой объём адресного пространства в каждом процессе. Системные свойства группируются в единицы prop_area фиксированного размера 128 КБ, которые полностью выделяются адресному пространству процесса, даже если обращение происходит только к одному системному свойству в нём. Это может вызывать проблемы на 32-разрядных устройствах, где адресное пространство имеет решающее значение.

Мы попытались преодолеть эти ограничения, не жертвуя совместимостью, но по-прежнему были обеспокоены тем, что системные свойства не предназначены для поддержки доступа к элементам конфигурации, доступным только для чтения. В конечном итоге мы решили, что системные свойства лучше подходят для совместного использования нескольких динамически обновляемых элементов во всем Android в режиме реального времени, и что существует необходимость в новой системе, предназначенной для доступа к элементам конфигурации, доступным только для чтения.

Проектирование HAL для ConfigStore

Основная конструкция проста:

Проектирование HAL-хранилища Configstore

Рисунок 1. Конструкция HAL ConfigStore

  • Опишите флаги сборки (в настоящее время используемые для условной компиляции фреймворка) в HIDL.
  • Поставщики и OEM-производители предоставляют значения флагов сборки, специфичные для SoC и устройств, путем внедрения службы HAL.
  • Измените фреймворк так, чтобы он использовал службу HAL для поиска значения элемента конфигурации во время выполнения.

Элементы конфигурации, на которые в настоящее время ссылается фреймворк, включены в версионный пакет HIDL ( android.hardware.configstore@1.0 ). Поставщики/OEM-производители предоставляют значения элементам конфигурации, реализуя интерфейсы в этом пакете, и фреймворк использует эти интерфейсы, когда ему необходимо получить значение элемента конфигурации.

Соображения безопасности

Флаги сборки, определённые в одном интерфейсе, подчиняются одной и той же политике SELinux. Если один или несколько флагов сборки должны иметь разные политики SELinux, их необходимо перенести в другой интерфейс . Это может потребовать серьёзной переработки android.hardware.configstore package , поскольку разделённые интерфейсы больше не обладают обратной совместимостью.