ConfigStore HAL

Android 8.0 расколов монолитного Android OS в родовой ( system.img ) и аппаратно-специфическое ( vendor.img и odm.img ) разделы. В результате этого изменения условная компиляция должна быть удалена из модулей, установленных в системный раздел, и такие модули должны определять конфигурацию системы во время выполнения (и вести себя по-разному в зависимости от этой конфигурации).

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