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. Дизайн ConfigStore HAL

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

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

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

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