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

В 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-файла стратегии продукта. К нему можно обратиться через правило по умолчанию buildstrategiesstructurerule следующим образом:

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

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

Файлы настроек 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 аудио-HAL по умолчанию AIDL предоставляет загрузчик XML CAP . Поставщики могут использовать этот загрузчик напрямую, расширив свой аудио-HAL с помощью аудио-HAL по умолчанию или обратившись к библиотеке libaudioserviceexampleimpl .

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

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

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

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

Продуктовые стратегии, определяемые 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>

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

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

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

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

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

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

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

Новое устройство должно запускаться с кодом Android 16 или более поздней версии в разделе vendor . Однако, поскольку у OEM-производителя есть пригодная к использованию конфигурация CAP-движка, он может использовать её в качестве отправной точки (или полностью использовать повторно). 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 HAL без конфигурации CAP. Для конфигурации CAP служба аудиополитик (аудиофреймворк) возвращается к загрузке конфигурации CAP из раздела vendor . В этом случае и определение домена CAP PfW, и конфигурация CAP устройства должны быть загружены из раздела vendor .

Сводка по миграции CAP

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