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

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

Дизайн хранилища конфигураций HAL

Рис. 1. Проект ConfigStore HAL

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

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

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

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