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 в реальном времени, и что существует потребность в новой системе, предназначенной для доступа к элементам конфигурации только для чтения.

ConfigStore HAL дизайн

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

Configstore HAL дизайн

Рисунок 1. Дизайн ConfigStore HAL

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

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

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

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