Google is committed to advancing racial equity for Black communities. See how.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

ConfigStore HAL

Android 8.0 разделяет монолитную ОС Android на общие ( system.img ) и аппаратно- vendor.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 поскольку отдельные интерфейсы больше не имеют обратной совместимости.