Переход на новую архитектуру управляемого аудио SCO

На этой странице рассказывается, как включить аудиофреймворк и аудиоуровень абстрагирования (AHAL), чтобы управлять синхронными подключениями, ориентированными на установление соединения (SCO). Этот процесс называется Audio Managed SCO (AMSCO).

В Android 17 и более поздних версиях фреймворк Android Audio использует функцию управления SCO для маршрутизации SCO, которая изначально обрабатывалась фреймворком Bluetooth (BT). При этом статус подключения SCO переходит из состояния, которым управляет фреймворк Bluetooth, в состояние, которое является следствием потоковой передачи аудио.

Централизованное управление маршрутизацией аудио в рамках аудиофреймворка позволяет привести реализацию уровня абстракции аудиооборудования (HAL) для SCO в соответствие с другими профилями Bluetooth, такими как профиль расширенного распространения аудио (A2DP) и LE Audio. Это изменение упрощает взаимодействие между телекоммуникационным и Bluetooth-стеками, что позволяет создать более надежную и централизованную архитектуру маршрутизации аудио.

Обзор архитектуры

Архитектура AMSCO централизует управление подключением SCO в рамках аудиофреймворка Android, который принимает решения о маршрутизации на основе активности потоковой передачи аудио. Эта архитектура отличается от предыдущей модели, в которой стек Bluetooth управлял подключениями. Ниже описаны роли каждого компонента в этой архитектуре.

AHAL запускает и приостанавливает сеанс SCO, только если выполняются следующие условия:

  • Активный поток передается на устройство SCO.
  • Режим "Только аудио" задан, и для устройства SCO существует исправление.

Аудиофреймворк не позволяет устройству A2DP иметь параллельный патч, когда выполняются эти конкретные критерии. Аудиофреймворк больше не отправляет изменения состояния SCO или приостановки A2DP в AHAL.

Управление SCO осуществляется аудиофреймворком, поэтому стек BT больше не вызывает функции подключения или отключения аудио. В случае превентивного отключения SCO или ошибки стек Bluetooth информирует аудиофреймворк с помощью AudioManager#onHfpAudioDisconnected.

План

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

Обратная совместимость

Чтобы фреймворк продолжал поддерживать устройства, которые могут получать обновления ОС без обновления AHAL или BT AHAL, используйте системное свойство, чтобы указать, что необходимо включить новое управление SCO. Устаревший путь сохраняется до шести лет, если системное свойство отключено или версия HAL устарела.

Настройте сеанс HFP

Для запуска или приостановки воспроизведения AHAL должен использовать новый тип сеанса профиля Hands-Free (HFP), как и другие типы сеансов BT. Состояние потока управляется с помощью различных IBluetoothAudioProviders, которые перечисляются и создаются классом Factory в зависимости от доступных путей.

Стек Bluetooth по возможности использует аппаратную разгрузку. При выборе кодеков во время согласования приоритет отдается следующим вариантам: аппаратный кодек LC3, программный кодек LC3, аппаратный кодек mSBC, программный кодек mSBC, аппаратный кодек CVSD, программный кодек CVSD.

На приведенных ниже диаграммах последовательности показано взаимодействие между AHAL и стеком Bluetooth, необходимое для установления состояния потока.

Процедура разгрузки оборудования

На рисунке 1 показано, как AHAL и стек Bluetooth взаимодействуют, чтобы установить прямой аппаратный путь передачи данных для аудио SCO:

hw-offload-procedure

Рисунок 1. Процедура аппаратной разгрузки.

Процедура определения пути к данным ПО

На рисунке 2 показан процесс обработки аудиоданных, требующий системного программного обеспечения:

sw-data-path

Рисунок 2. Процедура обработки данных ПО.

Процедура повторного согласования кодека

Когда аудиошлюз (AG) получает новую команду BT available codec (AT+BAC), он перезапускает процедуру согласования кодека. На рисунке 3 показана процедура повторного согласования кодека:

codec-renego-process

Рисунок 3. Процедура повторных переговоров о кодеке.

Влияние на HeadsetStateMachine

Конечный автомат гарнитуры на уровне Java (представленный классом HeadsetStateMachine) остается в основном неизменным, за исключением состояния AUDIO_CONNECTED, которое управляется событиями нативного стека. На уровне Java система больше не запускает connectAudioNative или disconnectAudioNative. Вместо этого система реагирует на изменения состояния подключения аудио, полученные от встроенного стека. Эти изменения активируются командами AHAL на IBluetoothAudioProvider или IBluetoothAudioPort.

Реализация

Чтобы интегрировать рефакторинг управления SCO, обновите связь между стеком BT и аудиофреймворком.

Чтобы включить эту функцию, выполните следующие действия:

  1. Уведомлять аудиофреймворк об изменениях активного подключения Bluetooth, чтобы правильно управлять инициализацией и завершением сеанса SCO при подключении устройства HFP и обрабатывать изменения активного устройства. Чтобы передать эту информацию в аудиофреймворк, используйте AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo).

    conn-hfp

    Рисунок 4. Подключите устройство HFP.

    Для определения состояния аудиоустройства в аудиофреймворке используется обратный вызов AudioManagerAudioDeviceCallback#onAudioDevicesAdded вместо устаревших трансляций.

  2. Реализуйте управление потоком AHAL с помощью setCommunicationDevice(AudioDeviceInfodevice) в качестве основной точки управления для запуска подключения SCO.

    Если HfpTransport::StartRequest возвращает BluetoothAudioCtrlAck::PENDING, AHAL должен повторить запрос, поскольку конечный автомат HFP не установлен.

Примеры использования

В разделах ниже описаны типичные алгоритмы достижения цели.

Процесс звонка в телекоммуникациях

В результате рефакторинга управления SCO функция phoneStateChanged стала блокирующей. После этого изменения телекоммуникации будут ждать завершения выполнения phoneStateChanged в методе BluetoothInCallService.onCallAdded, прежде чем вызывать API аудиофреймворка для запуска создания SCO.

call-telecom

Рисунок 5. Отвечать на звонки и совершать их через оператора связи.

Процесс VoIP-вызова

Аудиофреймворк запускает процесс, вызывая метод BluetoothHeadset.startScoUsingVirtualVoiceCall. После того как стек Bluetooth передаст результат аудиофреймворку, фреймворк направит AHAL на выполнение startStream. На рисунке ниже показан этот процесс.

call-voip

Рисунок 6. Отвечать на звонки и совершать их по IP-телефонии.

Распознавание речи

Для голосового управления (HF) и распознавания речи, инициированного AG, стек BT должен запросить у аудиофреймворка открытие SCO с помощью AudioManager.setCommunicationDevice. Это показано на рисунке ниже.

voice-recog

Рисунок 7. Инициализация SCO для распознавания речи.

Аудиоподключение

Стек Bluetooth инициирует подключение SCO, запрашивая у аудиофреймворка AudioManager.setCommunicationDevice(AudioDeviceInfo) во время распознавания речи. Если звонок активен, стек Bluetooth запрашивает у стека Telecom BluetoothInCallService#requestBluetoothAudio.

Ниже показана схема процесса:

audio-conn

Рисунок 8. Аудиоподключение.

Проверка и тестирование

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

  • CTS Verifier. Используйте CTS Verifier для интерактивного тестирования маршрутизации аудио во время звонков.
  • Набор тестов поставщика (VTS): проверьте взаимодействия AHAL и BT AHAL с помощью VTS.

Требования

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

  • HAL автомобиля: для реализации требуется совместимый HAL автомобиля, поддерживающий реорганизованный путь управления SCO.