ConfigStore HAL

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

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. На этой странице описана структура HAL ConfigStore и объясняется, почему для этой цели не использовались системные свойства. На других страницах этого раздела подробно рассказывается об интерфейсе 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). Поставщики и производители устройств предоставляют значения для элементов конфигурации, реализуя интерфейсы в этом пакете, а фреймворк использует эти интерфейсы, когда ему нужно получить значение для элемента конфигурации.

Безопасность

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