На этой странице описано, как включить в аудиофреймворке и аудио HAL (AHAL) управление синхронными соединениями с установлением соединения (SCO), процесс, известный как Audio Managed SCO (AMSCO).
В Android 17 и более поздних версиях аудиофреймворк Android использует функцию управления SCO для управления маршрутизацией SCO, которая изначально обрабатывалась фреймворком Bluetooth (BT). В результате этого перехода статус подключения SCO перестает быть состоянием, принадлежащим фреймворку BT, и становится следствием потоковой передачи аудио.
Централизация управления маршрутизацией звука в рамках аудиосистемы позволяет согласовать реализацию уровня аппаратной абстракции звука (HAL) для SCO с другими профилями Bluetooth, такими как Advanced Audio Distribution Profile (A2DP) и LE Audio. Эта рефакторизация упрощает взаимодействие между телекоммуникационным и Bluetooth-стеками, обеспечивая более надежную и централизованную архитектуру маршрутизации звука.
Архитектурный обзор
Архитектура AMSCO централизует управление соединениями SCO в рамках аудиофреймворка Android, который принимает решения о маршрутизации на основе активности потоковой передачи аудио. Эта архитектура отличается от предыдущей модели, где соединениями управлял стек Bluetooth. Роли каждого компонента в этой архитектуре следующие:
AHAL запускает и приостанавливает сессию SCO только при соблюдении следующих условий:
- Активный поток данных подключается к устройству SCO.
- Аудиорежим установлен, и существует патч для устройства SCO.
Аудиофреймворк предотвращает одновременную установку патчей на устройстве A2DP при соблюдении следующих условий. Аудиофреймворк больше не отправляет в AHAL изменения состояния SCO или приостановки A2DP.
Управление SCO осуществляется через аудиофреймворк, поэтому стек Bluetooth больше не вызывает функции подключения или отключения звука. В случаях упреждающего отключения SCO или ошибки стек Bluetooth информирует аудиофреймворк с помощью AudioManager#onHfpAudioDisconnected .
План
Используйте информацию из этого раздела для оценки следующих требований к совместимости и архитектуре, прежде чем внедрять рефакторинг управления SCO.
Обратная совместимость
Чтобы обеспечить дальнейшую поддержку устройств, которые могут получать обновления ОС без обновления их AHAL или BT AHAL, используйте системное свойство, указывающее на необходимость включения нового управления SCO. В случаях, когда системное свойство отключено или версия HAL устарела, путь к устаревшему интерфейсу сохраняется до шести лет.
Настройте сессию HFP.
Для начала или приостановки воспроизведения AHAL должен использовать новый тип сессии hands-free profile (HFP), аналогично другим типам сессий Bluetooth. В конечном итоге состояние потока управляется с помощью различных IBluetoothAudioProviders , которые перечисляются и создаются классом Factory в зависимости от доступных путей.
В стеке Bluetooth по возможности используется аппаратная разгрузка. При согласовании предпочтение отдается следующим кодекам: аппаратный кодек LC3 предпочтительнее программного LC3, затем аппаратный кодек mSBC, затем программный кодек mSBC, и, наконец, аппаратный кодек CVSD предпочтительнее программного CVSD.
На следующих диаграммах последовательности подробно описаны взаимодействия между AHAL и стеком BT, необходимые для установления состояния потока.
Процедура аппаратной разгрузки
На рисунке 1 показано, как стеки AHAL и BT координируют свои действия для установления прямого аппаратного пути передачи данных для аудиосигнала SCO:
Рисунок 1. Процедура аппаратной разгрузки.
Процедура передачи данных программного обеспечения
На рисунке 2 показан процесс обработки аудиоданных, требующий обработки системным программным обеспечением:
Рисунок 2. Процедура передачи данных в программном обеспечении.
процедура пересмотра кодека
Когда аудиошлюз (AG) получает команду на новый доступный кодек Bluetooth (AT+BAC), он перезапускает процедуру согласования кодеков. На рисунке 3 показана процедура повторного согласования кодеков:
Рисунок 3. Процедура пересогласования кодека.
Влияние на HeadsetStateMachine
В Java-слое конечный автомат состояния гарнитуры (представленный классом HeadsetStateMachine ) остается практически неизменным, за исключением состояния AUDIO_CONNECTED , которое управляется событиями нативного стека. В Java-слое система больше не инициирует вызовы connectAudioNative или disconnectAudioNative . Вместо этого система реагирует на изменения состояния аудиосоединения из нативного стека. Эти изменения запускаются командами AHAL на IBluetoothAudioProvider или IBluetoothAudioPort .
Выполнение
Для интеграции рефакторинга управления SCO необходимо обновить взаимодействие между стеком Bluetooth и аудиофреймворком.
Для реализации этой функции выполните следующие шаги:
Уведомите аудиофреймворк об изменениях в активном Bluetooth, чтобы обеспечить надлежащее управление инициализацией и завершением SCO во время подключения устройств HFP, а также для обработки изменений активных устройств. Используйте
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo), чтобы предоставить эту информацию аудиофреймворку.
Рисунок 4. Подключение устройства HFP.
В аудиофреймворке для индикации состояния аудиоустройства используется коллбэк
AudioManagerAudioDeviceCallback#onAudioDevicesAddedвместо устаревших широковещательных сообщений.Реализуйте управление потоком AHAL, используя
setCommunicationDevice(AudioDeviceInfodevice)в качестве основной точки управления для начала соединения SCO.Если
HfpTransport::StartRequestвозвращаетBluetoothAudioCtrlAck::PENDING, AHAL должен повторить запрос, поскольку конечный автомат HFP еще не установлен.
Варианты использования
В следующих разделах описаны типичные критически важные сценарии взаимодействия пользователя с системой (CUJ).
Схема обработки телефонных звонков
В результате рефакторинга управления SCO функция phoneStateChanged становится блокирующей. Это изменение заставляет телекоммуникационную компанию ждать завершения выполнения phoneStateChanged в методе BluetoothInCallService.onCallAdded() прежде чем вызывать API аудиофреймворка для начала создания SCO.
Рисунок 5. Ответ на звонок или начало разговора по телефону.
Схема обработки VoIP-звонков
Аудиофреймворк запускает процесс, вызывая метод BluetoothHeadset.startScoUsingVirtualVoiceCall . После того, как стек Bluetooth передаст результат аудиофреймворку, тот дает указание AHAL выполнить startStream . На следующем рисунке показана эта последовательность действий:
Рисунок 6. Ответ на звонок или начало звонка через VoIP.
распознавание голоса
Как для распознавания голоса в режиме громкой связи (HF), так и для распознавания голоса, инициируемого AG, стек Bluetooth должен запросить у аудиоплатформы открытие SCO с помощью AudioManager.setCommunicationDevice() . Это показано на следующем рисунке:
Рисунок 7. Инициализация SCO распознавания голоса.
Аудиосоединение
Стек Bluetooth инициирует соединение SCO, запрашивая у аудиофреймворка метод AudioManager.setCommunicationDevice(AudioDeviceInfo) во время распознавания голоса. Если активен вызов, стек Bluetooth вместо этого запрашивает у телекоммуникационного стека BluetoothInCallService#requestBluetoothAudio .
Этот процесс показан на следующем рисунке:
Рисунок 8. Аудиоподключение.
Проверка и тестирование
Для подтверждения корректной интеграции функции и соответствия стандартам качества производители устройств должны провести следующие тесты:
- CTS Verifier: Используйте CTS Verifier для интерактивного тестирования маршрутизации звука во время звонков.
- Набор инструментов для тестирования поставщиков (VTS): Проверка взаимодействия AHAL и BT AHAL с использованием VTS.
Требования
Данная функция требует соблюдения следующих условий:
- AHAL: Для реализации требуется совместимый AHAL, поддерживающий рефакторизованный путь управления SCO.