В Android 10 ConfigStore HAL использует флаги сборки для хранения значений конфигурации в разделе vendor , а служба в system разделе получает доступ к этим значениям с помощью HIDL (это также верно для Android 9). Однако из-за высокого потребления памяти и сложности использования ConfigStore HAL был признан устаревшим.
HAL ConfigStore остается в AOSP для поддержки устаревших разделов от производителя. На устройствах под управлением Android 10 или более поздней версии surfaceflinger сначала считывает системные свойства; если для элемента конфигурации в `SurfaceFlingerProperties.sysprop` не определено ни одно системное свойство, `surfaceflinger` возвращается к HAL ConfigStore.
В Android 8.0 монолитная ОС Android разделена на общие ( system.img ) и аппаратно-специфичные ( vendor.img и odm.img ) разделы. В результате этого изменения необходимо удалить условную компиляцию из модулей, устанавливаемых в системный раздел, и такие модули должны определять конфигурацию системы во время выполнения (и вести себя по-разному в зависимости от этой конфигурации).
HAL-интерфейс ConfigStore предоставляет набор API для доступа к элементам конфигурации, доступным только для чтения и используемым для настройки платформы Android. На этой странице описывается структура HAL-интерфейса ConfigStore (и почему для этой цели не использовались системные свойства); на других страницах этого раздела подробно описывается интерфейс HAL , реализация сервиса и использование на стороне клиента , все на примере surfaceflinger . Для получения справки по классам интерфейса ConfigStore см. раздел «Добавление классов и элементов интерфейса» .
Почему бы не использовать системные свойства?
Мы рассматривали возможность использования свойств системы, но обнаружили несколько фундаментальных проблем, в том числе:
- Ограничения на длину значений. Системные свойства имеют жесткие ограничения на длину своих значений (92 байта). Кроме того, поскольку эти ограничения напрямую доступны приложениям Android в виде макросов на языке C, увеличение длины может вызвать проблемы с обратной совместимостью.
- Отсутствует поддержка типов. Все значения по сути являются строками, и API просто преобразуют строку в
intилиbool. Другие составные типы данных (например, массив и структура) должны кодироваться/декодироваться клиентами (например,"aaa,bbb,ccc"можно закодировать как массив из трех строк). - Перезапись. Поскольку системные свойства, доступные только для чтения, реализованы как свойства, допускающие однократную запись, поставщики/ODM, желающие переопределить определенные в AOSP значения, доступные только для чтения, должны импортировать свои собственные значения, доступные только для чтения, до импорта значений, определенных в AOSP. Это, в свою очередь, приводит к тому, что значения, определенные поставщиком и допускающие перезапись, переопределяются значениями, определенными в AOSP.
- Требования к адресному пространству. Свойства системы занимают относительно большой объем адресного пространства в каждом процессе. Свойства системы группируются в блоки
prop_areaфиксированного размера 128 КБ, и все это пространство выделяется для адресного пространства процесса, даже если осуществляется доступ только к одному свойству системы. Это может вызвать проблемы на 32-битных устройствах, где адресное пространство имеет решающее значение.
Мы попытались преодолеть эти ограничения, не жертвуя совместимостью, но по-прежнему беспокоились о том, что системные свойства не предназначены для доступа к элементам конфигурации, доступным только для чтения. В конце концов мы решили, что системные свойства лучше подходят для обмена несколькими динамически обновляемыми элементами по всему Android в режиме реального времени, и что существует необходимость в новой системе, предназначенной для доступа к элементам конфигурации, доступным только для чтения.
Проектирование ConfigStore HAL
Базовая конструкция проста:
Рисунок 1. Схема HAL ConfigStore.
- Опишите флаги сборки (в настоящее время используемые для условной компиляции фреймворка) в языке HIDL.
- Производители и OEM-производители предоставляют значения флагов сборки, специфичные для SoC и устройства, путем реализации сервиса HAL.
- Измените структуру платформы, чтобы она использовала службу HAL для определения значения элемента конфигурации во время выполнения.
Элементы конфигурации, на которые в настоящее время ссылается фреймворк, включены в версионированный пакет HIDL ( android.hardware.configstore@1.0 ). Производители/OEM предоставляют значения для элементов конфигурации, реализуя интерфейсы в этом пакете, и фреймворк использует эти интерфейсы, когда ему необходимо получить значение для элемента конфигурации.
Вопросы безопасности
Флаги сборки, определенные в одном и том же интерфейсе, подчиняются одной и той же политике SELinux. Если один или несколько флагов сборки должны иметь разные политики SELinux, их необходимо вынести в отдельный интерфейс . Это может потребовать серьезной доработки android.hardware.configstore package поскольку разделенные интерфейсы больше не будут обратно совместимы.