Настраиваемый механизм политики звука

В Android 14 автомобильная операционная система Android (AAOS) использует движок настраиваемой политики звука (CAP) для управления автомобильным звуком в пределах основной звуковой зоны. В частности, движок CAP позволяет AAOS управлять только маршрутизацией звука, только громкостью звука или и маршрутизацией, и громкостью одновременно. Для управления поведением можно использовать следующие флаги:

• Используйте флаг useCoreAudioVolume для включения управления громкостью CAP. Если это значение равно true , служба автомобильной аудиосистемы использует API-интерфейсы аудиоменеджера для управления группами громкости.

• Используйте флаг useCoreAudioRouting для включения управления аудиомаршрутизацией CAP. Если это значение равно true , автомобильная аудиослужба использует настраиваемую маршрутизацию аудиополитики для управления аудиомаршрутизацией.

Механизм политики звука также поддерживается в Android по умолчанию в виде стандартного механизма политики звука .

Фон

Механизм CAP основан на фреймворке параметров Intel, который представляет собой фреймворк на основе плагинов и правил для обработки параметров. В частности, для управления аудио Android движок CAP представил возможность определять правила XML-файлов, чтобы указать следующее:

• Стратегия аудиопродукта
• Правила выбора устройства вывода звука
• Правила выбора устройства аудиовхода
• Правила управления громкостью и отключения звука вместе с таблицами громкости

Инициализация CAP до Android 16

На следующем рисунке показан общий обзор управления конфигурацией настраиваемого механизма политики звука в Android 6:

Рисунок 1. Управление конфигурацией движка CAP в Android 6.

Как показано на рисунке, конфигурация движка CAP получается службой политики звука путем анализа информации из файла audio_policy_engine_configuration.xml в разделе vendor . Файл конфигурации движка CAP использует схему, определенную в audio_policy_engine_configuration.xsd , для получения необходимой информации. audio_policy_engine_configuration.xml — пример для автомобильной промышленности. Аналогичные примеры для других форм-факторов находятся в папке frameworks/av/services/audiopolicy/engineconfigurable/config/example/ .

На следующем рисунке показана более подробная информация о том, как загружается настраиваемая информация о движке политики звука в службу политики звука. В этом случае фреймворк параметров загружает структуру и настройки из XML-файлов.

Рисунок 2. Информация CAP, загруженная в службу политики аудио.

Файлы структуры CAP в Android 15 и ниже

Для получения структуры и настроек служба политики аудио считывает файл ParameterFrameworkConfigurationPolicy.xml . Он ссылается на информацию о структуре через местоположение файла описания структуры:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Это указывает на структурную информацию в файле:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

В Android предусмотрена скелетная структура. Информация о структуре требует информации о структуре стратегии продукта, поэтому Android предоставляет инструмент генерации buildStrategiesStructureFile.py , который может генерировать информацию из доступного XML-файла стратегии продукта. На него можно ссылаться через genrule default buildstrategiesstructurerule следующим образом:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Где audio_policy_engine_configuration_files — файлы конфигурации движка политики звука. Этот пример для automotive ссылается на файлы конфигурации политики звука в папке automotive . Другие примеры показывают, как настроить сборку для отправки файлов в раздел поставщика устройства.

Файлы настроек CAP в Android 15 и ниже

Аналогично структуре, информация о настройках, которая представляет правила и значения параметров, указана в файле ParameterFrameworkConfigurationPolicy.xml следующим образом:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android также предоставляет инструменты сборки для генерации этой информации с использованием конфигурации движка политики звука и файлов фреймворка параметров. См. Конфигурации для получения дополнительной информации.

Инициализация AIDL audio HAL CAP

Начиная с Android 16, определение API AIDL Audio HAL расширено конфигурациями движка политики звука, AudioHalCapConfiguration.aidl . На следующем рисунке показан высокоуровневый обзор управления конфигурацией движка CAP по состоянию на Android 16:

Рисунок 3. Управление конфигурацией движка CAP в Android 16.

Служба политики звука получает информацию о движке CAP напрямую с помощью API-интерфейсов AIDL Audio HAL, а не анализирует информацию из XML-файлов в разделе поставщика устройства.

В этой конфигурации структура фреймворка параметров по-прежнему загружается движком CAP на стороне аудиосервера.

Рисунок 4. Структура двигателя CAP.

Во всех случаях конфигурация должна полностью определять информацию, касающуюся стратегий продукта, групп объемов и критериев.

На следующем рисунке показан общий обзор API-интерфейсов AIDL audio HAL, которые используются службой политики звука для получения конфигурации механизма CAP:

Рисунок 5. API-интерфейсы AIDL audio HAL.

В этой настройке служба политики звука получает следующую информацию от аудио HAL AIDL:

• Конфигурация
• Стратегии
• Объемы
• Критерии
• Настройки

Загрузчик AIDL Audio HAL по умолчанию

Для сглаживания перехода от HIDL к AIDL, аудио AIDL Audio HAL по умолчанию предоставляет загрузчик XML CAP engine . Поставщики могут использовать этот загрузчик напрямую, расширяя свой аудио HAL с помощью аудио HAL по умолчанию или ссылаясь на библиотеку libaudioserviceexampleimpl .

Загрузчик AIDL audio HAL по умолчанию использует audio_policy_engine_configuration.xml для получения следующей информации:

• Конфигурация
• Стратегии
• Объемы
• Критерии

Информация о структуре получается из файла PolicyConfigurableDomains.xml . Ключевое отличие от предыдущего механизма заключается в том, что информация о структуре также получается AIDL audio HAL вместо фреймворка параметров в службе политики аудио.

Поставщики могут использовать инструмент domaingeneratorpolicyrule для генерации настраиваемых доменов с использованием информации из конфигурации движка политики аудио. В качестве справочного материала можно использовать пример виртуального устройства Cuttlefish для автомобильной промышленности.

Структура в конфигурации AIDL

В Android 16 и выше служба политики аудио получает информацию о структуре путем чтения и анализа файла ParameterFrameworkConfigurationCap.xml . В частности, она получает информацию из файла описания структуры:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

Фреймворк помещает необходимые файлы в папку /etc/parameter-framework/ с необходимой информацией.

Структура представляет собой параметры, которые должны контролироваться, поэтому на них следует ссылаться в конфигурации или доменах. Для этого конфигурация движка AIDL должна использовать предопределенное имя для параметров. Для стратегий продукта структуры настраиваются в CapProductStrategies.xml .

Стратегии продукта по умолчанию

Начиная со значений по умолчанию, предоставленных в движке по умолчанию , стратегии продукта начинаются с префикса STRATEGY_ :

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Этот формат был предоставлен для облегчения перехода с HIDL на AIDL для устройств, которые использовали стратегии по умолчанию. Это изменение формата имеет некоторые последствия для существующих файлов (например, PfW, XML), которые используются для настройки движка. В частности, все ссылки на стратегии продукта должны быть изменены для использования новых имен, например :

Стратегии продукта, определяемые OEM-производителями

Настраиваемый движок предоставляет возможность OEM-производителям изменять определение стратегий продукта. Чтобы продолжать поддерживать это, файл стратегии продукта CapProductStrategies.xml также предоставляет 40 расширяемых поставщиком стратегий продукта от vx_1000 до vx_1039 . Все расширения поставщика должны начинаться с префикса vx_ и сопровождаться числом, представляющим идентификатор стратегии продукта в определении стратегии продукта AIDL audio HAL. Остальные определения (например, группы аудиоатрибутов, имя) получаются из объекта AudioHALProductStrategy в конфигурации аудиодвижка HAL .

Аналогично стратегиям продукта по умолчанию, определяемые поставщиком OEM-ссылки также должны быть адаптированы между конфигурацией без AIDL и конфигурацией AIDL, например:

Стратегии продукта

Стратегии продукта предоставляют способ настройки того, как аудиопотоки категоризируются и группируются. Это обеспечивает большую гибкость в настройке аудиоустройств, включая то, как они маршрутизируются и как управляются их громкостями. Каждая стратегия продукта может иметь одну или несколько групп аудиоатрибутов , которые определяют потоки, которые должны быть связаны с этой стратегией продукта. Эти группы аудиоатрибутов позволяют использовать более детальный подход к категоризации аудио и могут быть смесью следующих типов:

• Типы использования описывают, почему воспроизводится звук (то есть мультимедиа, уведомление, вызов).
• Типы контента описывают то, что воспроизводится (то есть музыка, речь, видео, озвучивание).
• Типы флагов определяют различное поведение или запросы по отношению к потоку.
• Типы тегов поддерживают любой произвольный список значений строк поставщика.
  • Каждая строка должна начинаться с VX_ за которым следует буквенно-цифровая строка (например, VX_OEM , VX_NAVIGATION ).

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

В этом отрывке показан пример стратегии продукта, используемой в автомобильных эмуляторах . Он содержит два аудиоатрибута с аудиоиспользованием media и game соответственно. Эта стратегия продукта соответствует аудиоконтексту MUSIC , используемому в автомобильном аудиосервисе , но для такого соответствия нет требований. Одной из основных утилит для OEM-производителей, использующих CAP вместе с Android, является обеспечение более гибких определений группирования аудио.

Группы томов

Кроме того, каждая группа аудиоатрибутов должна иметь связанную группу томов. Эта группа томов связана с любым потоком, соответствующим аудиоатрибутам, принадлежащим группе аудиоатрибутов. Пример стратегии музыкального продукта в разделе Стратегии продукта имеет группу томов media , а определение группы томов media выглядит следующим образом:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

В этом определении группа томов содержит:

• Название группы
• Минимальный индекс группы
• Групповой максимальный индекс
• Кривые групп объема

Кривые группы громкости содержат точечное отображение между индексом группы громкости и усилением громкости в миллибелах. Предоставленные точки используются для линейной интерполяции наилучшего соответствующего усиления при управлении громкостью. Каждая кривая группы громкости связана с категорией типа устройства (например, гарнитура, динамик, внешний носитель).

Группа громкости управляет громкостью потоков, входящих в группу аудиоатрибутов. Например, когда запускается поток с аудиоатрибутами, содержащими музыку или игру, используется последний установленный индекс громкости для группы громкости мультимедиа. В этом случае соответствующая кривая категории устройства выбирается на основе выбранного устройства, а соответствующее усиление устанавливается при запуске потока.

Конфигурации

В движке CAP конфигурации используются для определения условий или правил, которые определяют, как должен вести себя звук. Эти конфигурации оцениваются во время выполнения, чтобы выбрать соответствующие правила для применения в зависимости от текущего состояния аудиосистемы.

Как показано на рисунке 5, API содержит несколько доменов, цель каждого домена — разбить логику на более мелкие задачи маршрутизации для решения (например, устройство 1, устройство 2).

Каждый домен имеет конфигурации, а каждая конфигурация имеет набор правил. Правила устанавливаются на основе критериев, которые предоставляются AudioPolicyManager :

• Аудио режим
• Доступные устройства ввода и вывода
• Доступные адреса устройств ввода и вывода
• Использовать для
  • СМИ
  • Коммуникация
  • Запись
  • Док
  • Система
  • аудиосистема HDMI
  • Кодированное объемное звучание
  • Виброзвонок

Каждый домен содержит конфигурации, которые диктуют правила, которые должны влиять на поведение. Обратите внимание, что порядок конфигурации имеет значение, и важно убедиться, что конфигурации находятся в требуемом порядке. После проверки правил для конфигурации выбирается конфигурация.

В следующем коде показан фрагмент примера файла структуры параметров, который можно использовать для генерации необходимого XML-файла для настройки настраиваемых доменов:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

Домен DeviceForProductStrategies определяет, как следует применять различные правила при обработке выбора устройств стратегий продукта. Синие части описывают правила, которые следует учитывать, а зеленая часть — применяемая конфигурация. Этот конкретный пример содержит следующие конфигурации:

• Выберите устройство Bluetooth A2DP для стратегии музыкального продукта (ID 1000, vx_1000 )
  • Если используется для мультимедиа, не исключает A2DP
  • Если используется для связи, не является ли BT SCO
  • Если доступны устройства, включите BT A2DP
• Выберите шинное устройство
  • Если шина устройств доступна
  • Если адрес BUS00_MEDIA
• В противном случае выберите устройство вывода по умолчанию.

Чтобы создать соответствующий XML-файл настраиваемого механизма политики, запустите файлы структуры параметров (PFW) через систему сборки , определив правило сборки, выполнив следующие шаги:

1. В файле Android.bp создайте файловую группу для файла:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Добавьте файл к другим файлам PfW (если таковые имеются).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. Создайте соответствующее правило генерации домена :

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Где domaingeneratorpolicyrule — это правило генерации , предоставляемое фреймворком для генерации файла PolicyConfigurableDomains.xml . Другие исходные файлы ( scrs ), включенные в правила генерации домена, следующие:

   Источник	Описание
   audio_policy_pfw_toplevel	Файл конфигурации параметров верхнего уровня.
   audio_policy_pfw_structure_files	Файлы структуры генерации домена, которые используются для генерации файлов конфигурации.
   audio_policy_engine_criterion_types	XML-файл типов критериев, описывающий критерии, используемые при генерации.
   edd_files	Список файлов одного домена (каждый из которых содержит один тег <ConfigurableDomain>).

После запуска правила генерации в сборке PolicyConfigurableDomains.xml генерируется со всеми доменами. Ниже показан фрагмент из сгенерированного файла с использованием примера правил PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Отладка CAP

Для сброса конфигураций CAP можно использовать remote-process :

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Здесь показаны все домены и конфигурации, включая условия применимости. Ниже показан фрагмент из автомобильного устройства Cuttlefish, использующего Bluetooth A2DP, шинное устройство и конфигурации по умолчанию. См. Конфигурации :

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Для получения дополнительной информации о других командах, доступных для отладки структуры параметров CAP, используйте этот инструмент:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Чтобы использовать инструмент, производители OEM должны разрешить настройку в устройстве. Чтобы проверить, позволяет ли устройство настройку, используйте следующую команду:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

В Android 15 и ниже файл может отличаться, поэтому используйте следующую команду:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

Файл должен содержать TuningAllowed="true" вместе с соответствующим портом сервера:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Этот файл автоматически генерируется в соответствии с типом образа сборки (или используйте другой файл для выпуска или отладки для устаревшей сборки). Сборка выпуска устанавливает TuningAllowed в false без порта сокета (сокеты запрещены для этого в сборках выпуска). Инженерные и userdebug сборки устанавливают его в true с используемым портом сокета. Обратите внимание, что это файл, на который ссылается audio_policy_pfw_toplevel . Инструмент remote-process также должен быть включен в файл сборки или сборки устройства :

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

Также необходимо включить соответствующую политику SELinux, разрешающую сокеты. Это работает только для режима отладки, поскольку режим выпуска явно запрещает сокеты:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Миграция CAP в Android 16

Учитывая основные изменения, внесенные AIDL audio HAL CAP engine и предыдущими версиями, существуют различные сценарии перехода устройств, которые следует рассмотреть. В этом разделе рассматриваются наиболее важные сценарии перехода и даются рекомендации по работе для включения конфигурации CAP engine.

Сценарий 1: Новое устройство с Android 16 или выше, нет предыдущего источника для конфигурации CAP устройства

Новое устройство должно запускаться с кодом Android 16 или выше в разделе vendor . Это означает, что оно должно предоставлять конфигурацию настраиваемого движка политики звука через интерфейс AIDL audio HAL. Конфигурация движка CAP устройства должна быть скопирована из примеров. В разделе vendor не должно быть определения домена PfW CAP.

Образ системы, используемый для устройства, — Android 16 или выше. Структура аудиосервиса обнаруживает конфигурацию CAP через аудиоинтерфейс AIDL HAL, поэтому она инициализирует PfW, используя определение домена PfW CAP из образа системы, и загружает конфигурацию CAP устройства, полученную через AIDL.

Для примера см. виртуальное устройство automotive Cuttlefish , которое было введено в этом изменении и может быть использовано для получения требуемых файлов, правил сборки и файлов make, необходимых для настройки требуемых файлов конфигурации. Это работает с загрузчиками, предоставленными в стандартном AIDL audio HAL .

Сценарий 2: Новое устройство с Android 16 или выше, с предыдущего устройства с CAP

Новое устройство должно запускаться с кодом Android 16 или выше в разделе vendor . Однако, поскольку у OEM есть пригодная для использования конфигурация движка CAP устройства, OEM захочет использовать ее в качестве отправной точки (или полностью повторно использовать ее). Версия AIDL конфигурации CAP имеет некоторые изменения по сравнению с Android 15 и более ранними версиями, поэтому поставщик должен преобразовать существующую конфигурацию в AIDL. См. обсуждение в разделе «Стратегии продукта» для изменений между Android 16 и более ранними версиями для получения информации о необходимых изменениях. В целом, аудиофреймворк обнаруживает и загружает конфигурацию CAP так же, как в сценарии 1.

Сценарий 3: существующее устройство с CAP, обновляющее до Android 16 только системный раздел

В этом сценарии раздел vendor содержит версию конфигурации CAP устройства Android 15 и ниже, а также определение домена PfW CAP. Раздел vendor нетронут, поэтому он по-прежнему использует HIDL HAL. Фреймворк следует сценарию Android 15 и ниже и загружает всю конфигурацию, связанную с CAP, из раздела vendor .

Сценарий 4: Существующее устройство, выпущенное на базе Android 15 с CAP

CAP не поддерживался в AIDL на Android 15, поэтому некоторые поставщики выпустили новые устройства с AIDL Audio HAL и CAP, которые загружались аудиофреймворком. Этот гибридный режим был неофициальным, но включен в Android 16. Обратите внимание, что этот режим не должен использоваться для выпуска новых устройств на Android 16, а скорее для того, чтобы существующие устройства с поставщиком Android 15 могли быть обновлены до Android 16 (обновление system раздела).

Аудиофреймворк обнаруживает аудиоконфигурацию AIDL audio HAL без конфигурации CAP. Для конфигурации CAP служба политики аудио (аудиофреймворк) возвращается к загрузке конфигурации CAP из раздела vendor . В этом случае и определение домена PfW CAP, и конфигурация CAP устройства должны быть загружены из раздела vendor .

Резюме миграции CAP

В следующей таблице приведены совместимые конфигурации систем и поставщиков, а также требования к конфигурации CAP: