Аудио фокус

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

Хотя отправка запроса на фокусировку рекомендуется, система не применяет его принудительно. Поэтому рассматривайте фокусировку как способ косвенного управления воспроизведением и предотвращения конфликтов, а не как основной механизм управления аудиосистемой. Работа аудиоподсистемы автомобиля не должна зависеть от системы фокусировки.

Фокусные взаимодействия

Для поддержки AAOS запросы аудиофокуса обрабатываются на основе предопределённых взаимодействий между CarAudioContext запроса и CarAudioContext текущих держателей фокуса. Существует три типа взаимодействий:

  • Эксклюзив
  • Отклонять
  • Одновременный

Эксклюзивное взаимодействие

Это модель взаимодействия, которая чаще всего используется в Android.

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

Отклонить взаимодействие

При взаимодействии с отклонением входящий запрос всегда отклоняется. Например, при попытке воспроизвести музыку во время разговора. В этом случае, если приложение Dialer удерживает аудиофокус для вызова, а второе приложение запрашивает фокус для воспроизведения музыки, музыкальное приложение получает AUDIOFOCUS_REQUEST_FAILED в ответ на запрос. Поскольку запрос фокуса отклонен, потеря фокуса текущему владельцу фокуса не отправляется.

Параллельное взаимодействие

Уникальной особенностью AAOS является возможность одновременного взаимодействия. Это позволяет приложениям, запрашивающим аудиофокус в автомобиле, удерживать фокус одновременно с другими приложениями. Для одновременного взаимодействия должны быть выполнены следующие условия:

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

Обработка параллельных потоков

Хотя параллельное взаимодействие имеет множество применений, будьте осторожны при микшировании и приглушении звука на аппаратном уровне между устройствами вывода. Мы настоятельно рекомендуем направлять экземпляры CarAudioContext , которым разрешено воспроизводиться одновременно, на разные устройства вывода.

Наличие отдельных выходных устройств для параллельных потоков позволяет HAL приглушать один из потоков перед их микшированием или направлять физические потоки на разные динамики в автомобиле. Если логические потоки микшируются в Android, усиление не изменяется и передается как часть одного и того же физического потока.

Например, при одновременном использовании навигации и мультимедиа усиление медиапотока можно временно уменьшить (или приглушить), чтобы команды навигации были слышны более чётко. В качестве альтернативы, навигационный поток можно направить на динамики со стороны водителя, в то время как медиапотоки продолжат воспроизводиться в остальной части салона.

Матрица взаимодействия

В этой таблице представлена ​​матрица взаимодействия, определённая CarAudioService . Каждая строка представляет CarAudioContext текущего держателя фокуса, а каждый столбец — CarAudioContext входящего запроса.

Например, когда музыкальное медиа-приложение удерживает фокус, в то время как навигационное приложение запрашивает фокус, матрица указывает, что два взаимодействия могут воспроизводиться одновременно, предполагая, что выполнены другие критерии для одновременных взаимодействий .

Из-за параллельных взаимодействий возможно наличие нескольких держателей фокуса. В этом случае входящий запрос фокуса сравнивается с каждым из текущих держателей фокуса, прежде чем определить, какое взаимодействие применить. В этом случае побеждает наиболее консервативное взаимодействие. Сначала — «Отклонить», затем — «Исключающее» и, наконец, — «Конкурентное».

Матрица взаимодействия аудиофокуса

Рисунок 1. Матрица взаимодействия аудиофокуса.

В Android 11 появился новый пользовательский параметр, позволяющий изменять взаимодействие между навигацией и телефонными вызовами. При установке параметра android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL взаимодействие между входящими запросами фокуса NAVIGATION и текущими держателями фокуса CALL изменяется с concurrent на rejects . Если пользователь предпочитает, чтобы навигационные инструкции не прерывали вызов, он может включить этот параметр. Этот параметр сохраняется для пользователя и может быть установлен динамически, чтобы последующие запросы фокуса учитывали новую настройку.

Отложенный аудиофокус

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

Правила для отложенных запросов аудиофокуса

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

  • Одновременно может быть отложен только один запрос. Если отложенный запрос выполняется при наличии уже отложенного запроса, исходный отложенный запрос получает событие изменения AUDIOFOCUS_LOSS , а новый запрос получает синхронный ответ AUDIOFOCUS_REQUEST_DELAYED .

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

Запрос отложенного фокуса

Чтобы создать запрос, который можно отложить:

  1. Используйте AudioFocusRequest.Builder#setAcceptsDelayedFocusGain .

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();
    
    mDelayedFocusRequest = new AudioFocusRequest
         .Builder(AudioManager.AUDIOFOCUS_GAIN)
         .setAudioAttributes(mMusicAudioAttrib)
         .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
         .setForceDucking(false)
         .setWillPauseWhenDucked(false)
         .setAcceptsDelayedFocusGain(true)
         .build();
    
  2. При выполнении запроса обработайте ответ AUDIOFOCUS_REQUEST_DELAYED :

    int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
    if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
        // start audio playback
        return;
    }
    if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
         // audio playback delayed to audio focus listener
         return;
    }
    
  3. Если запрос задерживается, прослушиватель фокуса обрабатывает изменения фокуса:

    private final class MediaWithDelayedFocusListener implements
    OnAudioFocusChangeListener {
           @Override
           public void onAudioFocusChange(int focusChange) {
               synchronized (mLock) {
                   switch (focusChange) {
                       case AudioManager.AUDIOFOCUS_GAIN:
                            // Start focus playback
                       case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                            // Pause media transiently
                       case AudioManager.AUDIOFOCUS_LOSS:
                            // Stop media
    

Системное принудительное затухание

В Android 15 реализована функция системного затухания звука в AAOS. В Android фокус звука не контролируется системой. Поэтому, хотя разработчикам приложений рекомендуется соблюдать правила фокуса звука, если приложение продолжает громко воспроизводить звук даже после потери фокуса звука, система не может этого предотвратить.

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

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

Высокоуровневый дизайн

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

Высокоуровневое проектирование для системно-управляемой функции затухания

Рисунок 2. Высокоуровневая конструкция для системно-управляемой функции затухания.

  • Целенаправленное затухание: Системное принудительное затухание в Android 15 специально разработано для ситуаций, когда приложение теряет аудиофокус, но продолжает воспроизводить звук.
  • Механизм затухания: когда приложение теряет аудиофокус и переключается на новое запрашивающее приложение:
    • Аудиофреймворк автоматически приглушает звук проигрывающего приложения.
    • После затухания система отключает аудиопоток.
    • Затем приложение получает уведомление о потере аудиофокуса.
    • Некорректно работающие приложения отключаются до тех пор, пока не восстановится аудиофокус.
    • Логика по умолчанию — плавное появление приложений, которые затем исчезают через 2 секунды. Однако производители оригинального оборудования могут настроить любое значение тайм-аута.
    • Аудиофреймворк использует конфигурации OEM для операций постепенного затухания и нарастания звука.
  • Файл конфигурации OEM: Android 15 включает новый файл конфигурации car_audio_fade_configuration.xml :

    • Этот файл позволяет производителям оригинального оборудования определять критерии, при которых принудительное применение аудиофокуса системы к проигрывающему приложению.
    • Аудиофреймворк применяет затухание и отключение звука только в том случае, если проигрывающее приложение соответствует правилам, определенным OEM-производителем в этом XML-файле.
    • Это дает OEM-производителям возможность настраивать поведение функции на основе характеристик приложения или типов использования аудио.
  • Управление функциями с помощью RRO: введен новый флаг функции наложения ресурсов времени выполнения (RRO), audioUseFadeManagerConfiguration , для включения или отключения этой функции:

    • По умолчанию эта функция отключена.
    • Чтобы активировать принудительную потерю фокуса звука в системе, OEM-производители должны установить этот флаг в true .
    • Хотя фреймворк автомобильной аудиосистемы ожидает допустимых определений конфигурации затухания при включении флага, отсутствие таких определений не приводит автоматически к фатальному исключению.
    • Все приложения с конфигурациями плавного перехода должны иметь соответствующие определения. Обращение к конфигурации плавного перехода (по имени) как к части конфигурации автомобильной аудиосистемы без предоставления корректного определения является фатальной ошибкой.
    • Если флаг отключен, все определения конфигураций затухания и любые ссылки на конфигурации игнорируются.

Конфигурация менеджера затухания

Аудиофреймворк Android 15 представляет унифицированный FadeManagerConfiguration , предоставляющий OEM-производителям возможность детального управления затуханием звука. Этот фреймворк показан на рисунке 3.

Конфигурация менеджера затухания

Рисунок 3. Конфигурация менеджера затухания.

Эта конфигурация включает в себя:

  • Свойства плавного перехода: настройки для плавного затухания и плавного появления.
    • Может быть определен с помощью конкретных аудио-использований или атрибутов.
    • Позволяет настраивать пользовательскую длительность.
    • Эти настройки используются для построения VolumeShaper.Configuration .
  • Политики затухания: правила, регулирующие момент затухания.
    • Глобальный переключатель для включения или выключения затухания.
    • Настраиваемый список вариантов использования звука с плавным затуханием (с возможностью плавного затухания при потере фокуса).
    • Списки исключений (без возможности затухания) предотвращают затухание критически важных или определенных источников звука. Эти списки могут быть основаны на:
      • Типы контента
      • Аудио атрибуты
      • UID приложений (можно задать только во время выполнения)

OEM-конфигурации

В этом разделе мы рассмотрим доступные OEM-кастомизации.

XML-файл конфигурации затухания автомобильной аудиосистемы

В Android 15 представлен новый файл конфигурации car_audio_fade_configuration.xml , который позволяет OEM-производителям выполнять расширенную настройку поведения затухания звука при потере фокуса.

  • Этот XML-файл позволяет определить несколько отдельных конфигураций затухания, каждая из которых требует уникального имени для перекрестных ссылок в car_audio_configuration.xml .
  • Эти конфигурации можно гибко применять в различных аудиозонах и конфигурациях зон.
  • Примечательно, что каждая конфигурация затухания принимает только значения длительности в миллисекундах, которые система затем использует для внутренней генерации соответствующего VolumeShaper.Configuration .

Для практического руководства по реализации ознакомьтесь с примерами конфигураций, предоставленными для эмулятора, расположенными в device/generic/car/emulator/audio/car_audio_fade_configuration.xml .

XML-файл конфигурации автомобильной аудиосистемы

В Android 15 представлен обновлённый файл car_audio_configuration.xml версии 4, включающий новые теги applyFadeConfigs и fadeConfig . Тег applyFadeConfigs может содержать несколько определений fadeConfig , что обеспечивает гибкую настройку плавного перехода. Каждое определение:

  • Необходимо включить один fadeConfig по умолчанию, обозначенный как isDefault = true .
  • Может включать несколько определений переходных fadeConfig . Эти переходные конфигурации применяются специально во время взаимодействий с потерей аудиофокуса и только тогда, когда приложение, возвращающее аудиофокус, соответствует критериям, заданным в переходной конфигурации.

Для практического руководства по реализации ознакомьтесь с примерами конфигураций, предоставленными для эмулятора, расположенными в device/generic/car/emulator/audio/car_audio_configuration.xml .

Расширение сервиса OEM-аудиофокусировки

Производители оригинального оборудования (OEM), реализующие специализированную службу фокусировки звука автомобиля, могут гибко настраивать параметры затухания звука, добавляя их в OemCarAudioFocusResult . Это можно сделать с помощью метода конструктора setAudioAttributesToCarAudioFadeConfigurationMap() :

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

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

Диаграмма последовательности

Эта диаграмма последовательности иллюстрирует поведение после предоставления аудиофокуса App2 и последующей потери аудиофокуса App1 :

  • После того, как автомагнитола отправляет сообщение о потере аудиофокуса на App1 , воспроизведение с проигрывателя App1 плавно затухает, как определено активными параметрами FadeManagerConfiguration . После завершения операции плавного затухания App1 получает стандартный обратный вызов о потере аудиофокуса.
  • При желании звук для App1 можно плавно увеличивать по истечении заданного времени. Производители оригинального оборудования могут задать это время с помощью Builder#setFadeInDurationForUsage(int, long) в соответствии с требованиями своего продукта.

Диаграмма последовательности действий для функции затухания звука в автомобиле

Рисунок 4. Диаграмма последовательности для функции затухания звука в автомобиле.

Многозонное управление фокусировкой

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

Для всех приложений CarAudioService автоматически управляет фокусом. Аудиозона запроса фокуса определяется связанным с ней UserId или UID (подробнее см. в разделе «Многозонная маршрутизация звука »).

Запросить аудио из нескольких зон одновременно

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

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

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

HAL аудиофокус

Начиная с Android 11, HAL может запрашивать фокусировку для внешних потоков. Хотя использование этих API необязательно, мы настоятельно рекомендуем использовать их для оптимального взаимодействия внешних звуков с экосистемой Android и обеспечения бесперебойного пользовательского опыта.

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

HAL должен заблаговременно отключать потоки Android по мере необходимости при воспроизведении экстренных или критически важных для безопасности звуков, чтобы гарантировать их отчетливую слышимость.

AudioControl@2.0

Версия AudioControl HAL 2.0 представляет следующие новые API:

API Цель
IAudioControl#registerFocusListener Регистрирует экземпляр IFocusListener в AudioControl HAL. Этот прослушиватель позволяет HAL запрашивать и отменять аудиофокус. HAL предоставляет экземпляр ICloseHandle , который Android может использовать для отмены регистрации прослушивателя.
IAudioControl#onAudioFocusChange Уведомляет HAL об изменениях статуса запросов фокусировки, сделанных HAL через IFocusListener , включая ответы на первоначальные запросы фокусировки.
IFocusListener#requestAudioFocus Запрашивает фокус от имени HAL для указанного использования, идентификатора зоны и типа усиления фокуса.
IFocusListener#abandonAudioFocus Отменяет существующие запросы фокуса HAL для указанного использования и идентификатора зоны.

HAL может одновременно обрабатывать несколько запросов на фокус, но ограничен одним запросом на каждое использование и сопряжение идентификатора зоны. Android предполагает, что HAL сразу же начинает воспроизводить звуки для использования после получения запроса и продолжает это делать до тех пор, пока не потеряет фокус.

За исключением registerFocusListener , эти запросы являются oneway , чтобы гарантировать, что Android не задержит HAL во время обработки запроса на фокус. HAL не должен дожидаться получения фокуса, прежде чем воспроизводить критически важные для безопасности звуки. HAL может прослушивать изменения фокуса звука и реагировать на них с помощью IAudioControl#onAudioFocusChange .

OEM-сервис по фокусировке автоаудио

В Android 14 AAOS представила службы подключаемых модулей OEM для автомобилей, обеспечивающие возможность настройки некоторых компонентов автомобиля. Служба подключаемых модулей Car Audio позволяет OEM-производителям управлять запросами фокусировки, перехваченными службой автомобильной аудиосистемы. Это дает OEM-производителям больше гибкости в управлении фокусировкой в ​​соответствии с требованиями правил и положений. Таким образом, взаимодействие с аудиофокусом может различаться у разных производителей и в разных регионах. Основная предпосылка для аудиофокуса по-прежнему остается в силе: приложения должны по-прежнему запрашивать фокусировку для лучшего управления аудио и улучшения пользовательского опыта. В целом, для запросов аудиофокуса приложениями по-прежнему действуют определенные правила:

  • Приложения без какого-либо постоянного, высокоприоритетного аудиофокуса (включая телефонный звонок, экстренное оповещение или уведомление о безопасности) должны иметь возможность получить аудиофокус либо временно, либо постоянно.

  • Пока активное внимание СМИ:

    • Приложения, запрашивающие фокус на использовании вызовов, должны иметь возможность принимать вызовы либо одновременно, либо исключительно.

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

    • Приложения, запрашивающие фокус использования помощника, должны иметь возможность получать фокус использования либо одновременно, либо по отдельности.

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

Хотя эти рекомендации не являются исчерпывающими, они могут помочь приложениям, запрашивающим фокус, получить его при отсутствии активных высокоприоритетных звуков. Даже при наличии активных высокоприоритетных звуков отложенные запросы на фокус должны учитываться и должны получать фокус после прекращения воспроизведения высокоприоритетного звука.