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

В Android 14 операционная система Android Automotive Operating System (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 . Другие примеры показывают, как настроить сборку для отправки файлов в раздел поставщика устройства.

Файлы настроек 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 для аудиосистем, используемых службой политики аудио для получения конфигурации механизма CAP:

Рисунок 5. Аудио API HAL для AIDL.

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

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

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

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

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

• Конфигурация
• Стратегии
• Тома
• Критерии

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

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

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

В Android 16 и выше служба политики аудио получает информацию о структуре, считывая и анализируя файл ParameterFrameworkConfigurationCap.xml [файл](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

В частности, он получает информацию из файла описания структуры:

<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), используемых для настройки движка. В частности, все ссылки на стратегии продукта должны быть изменены на использование новых имен, например :

Стратегии разработки продукции, определяемые производителем оборудования

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

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

Группы томов

Кроме того, каждая группа аудиоатрибутов должна иметь связанную с ней группу громкости. Эта группа громкости связана с любым потоком, соответствующим аудиоатрибутам, принадлежащим к данной группе аудиоатрибутов. В примере стратегии музыкального продукта в разделе « Стратегии продуктов» указана группа громкости 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?
  • Если имеются подходящие устройства, включите Bluetooth 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 . Инструмент удаленной обработки также должен быть включен в файл make или build устройства :

# 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 HAL CAP и предыдущими версиями, существует множество сценариев перехода на новые устройства, которые следует рассмотреть. В этом разделе рассматриваются наиболее распространенные сценарии перехода и даются рекомендации по работе по настройке движка CAP.

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

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

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

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

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

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

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

В этом сценарии раздел vendor содержит конфигурацию CAP устройства для Android 15 и более ранних версий, а также определение домена CAP PfW. Раздел 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 раздела).

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

Сводка по миграции в рамках Единой сельскохозяйственной политики

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