ConfigStore HAL

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

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

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 хранилища конфигураций

Рисунок 1. Проектирование HAL ConfigStore

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

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

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

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