이 페이지에서는 동기식 연결 지향 (SCO) 연결을 관리하기 위해 오디오 프레임워크와 오디오 HAL (AHAL)을 사용 설정하는 방법을 설명합니다. 이 프로세스는 오디오 관리 SCO (AMSCO)로 식별됩니다.
Android 17 이상에서 Android 오디오 프레임워크는 SCO 관리 기능을 사용하여 SCO 라우팅을 관리합니다. 원래는 블루투스 (BT) 프레임워크에서 처리했습니다. 이 이전은 SCO 연결 상태를 BT 프레임워크가 소유한 상태에서 오디오 스트리밍 활동의 다운스트림 결과로 이동합니다.
오디오 프레임워크 내에서 오디오 라우팅 소유권을 중앙 집중화함으로써 이 기능은 SCO의 오디오 하드웨어 추상화 계층 (HAL) 구현을 고급 오디오 배포 프로필 (A2DP) 및 LE 오디오와 같은 다른 BT 프로필과 정렬합니다. 이 리팩터링은 통신 및 BT 스택 간의 상호작용을 간소화하여 더 강력하고 중앙 집중화된 오디오 라우팅 아키텍처를 지원합니다.
아키텍처 개요
AMSCO 아키텍처는 Android 오디오 프레임워크 내에서 SCO 연결 관리를 중앙 집중화합니다. 이 프레임워크는 오디오 스트리밍 활동을 기반으로 라우팅 결정을 내립니다. 이 아키텍처는 BT 스택이 연결을 관리하는 이전 모델과 대조됩니다. 이 아키텍처에서 각 구성요소의 역할은 다음과 같습니다.
AHAL은 다음 조건이 충족되는 경우에만 SCO 세션을 시작하고 일시중지합니다.
- 활성 스트림이 SCO 기기에 패치됩니다.
- 오디오 모드가 설정되어 있고 SCO 기기에 대한 패치가 있습니다.
오디오 프레임워크는 이러한 특정 기준이 충족될 때 A2DP 기기에 동시 패치가 적용되지 않도록 합니다. 오디오 프레임워크는 더 이상 SCO 상태 변경사항이나 A2DP 일시중지를 AHAL에 전송하지 않습니다.
오디오 프레임워크가 SCO 관리를 처리하므로 BT 스택은 더 이상 오디오 연결 또는 연결 해제를 호출하지 않습니다. 선제적 SCO 연결 해제 또는 오류의 경우 BT 스택은 AudioManager#onHfpAudioDisconnected로 오디오 프레임워크에 알립니다.
계획
이 섹션의 정보를 사용하여 SCO 관리 리팩터링을 구현하기 전에 다음 호환성 및 아키텍처 요구사항을 평가하세요.
이전 버전과의 호환성
프레임워크가 AHAL이나 BT AHAL을 업데이트하지 않고 OS 업데이트를 받을 수 있는 기기를 계속 지원할 수 있도록 시스템 속성을 사용하여 새 SCO 관리를 사용 설정해야 함을 나타냅니다. 시스템 속성이 사용 중지되거나 HAL 버전이 오래된 경우 기존 경로는 최대 6년 동안 보존됩니다.
HFP 세션 설정
AHAL은 다른 BT 세션 유형과 마찬가지로 새로운 핸즈프리 프로필 (HFP) 세션 유형을 사용하여 재생을 시작하거나 일시중지해야 합니다. 스트림 상태는 궁극적으로 다양한 IBluetoothAudioProviders를 사용하여 관리되며, 이는 사용 가능한 경로에 따라 Factory 클래스에 의해 열거되고 빌드됩니다.
BT 스택은 가능한 경우 하드웨어 오프로드 경로를 사용합니다. 협상 중 코덱 선호도는 LC3 하드웨어가 LC3 소프트웨어보다 우선하고, mSBC 하드웨어가 그 다음, mSBC 소프트웨어가 그 다음, 마지막으로 CVSD 하드웨어가 CVSD 소프트웨어보다 우선하는 순서로 따릅니다.
다음 시퀀스 다이어그램은 스트림 상태를 설정하는 데 필요한 AHAL과 BT 스택 간의 상호작용을 자세히 설명합니다.
하드웨어 오프로드 절차
그림 1은 AHAL과 BT 스택이 SCO 오디오의 직접 하드웨어 데이터 경로를 설정하기 위해 어떻게 조정되는지 보여줍니다.
그림 1. 하드웨어 오프로드 절차입니다.
소프트웨어 데이터 경로 절차
그림 2는 시스템 소프트웨어 처리가 필요한 오디오 데이터를 처리하는 프로세스를 보여줍니다.
그림 2. 소프트웨어 데이터 경로 절차
코덱 재협상 절차
오디오 게이트웨이 (AG)가 새로운 블루투스 사용 가능 코덱 (AT+BAC) 명령어를 수신하면 AG는 코덱 협상 절차를 다시 시작합니다. 그림 3은 코덱 재협상 절차를 보여줍니다.
그림 3. 코덱 재협상 절차입니다.
HeadsetStateMachine에 미치는 영향
Java 레이어 헤드셋 상태 머신 (HeadsetStateMachine 클래스로 표시됨)은 네이티브 스택 이벤트로 구동되는 AUDIO_CONNECTED 상태를 제외하고는 대체로 변경되지 않습니다.
Java 레이어 내에서 시스템은 더 이상 connectAudioNative 또는 disconnectAudioNative를 시작하지 않습니다. 대신 시스템은 네이티브 스택의 오디오 연결 상태 변경에 응답합니다. 이러한 변경사항은 IBluetoothAudioProvider 또는 IBluetoothAudioPort에 대한 AHAL의 명령에 의해 트리거됩니다.
구현
SCO 관리 리팩터링을 통합하려면 BT 스택과 오디오 프레임워크 간 통신을 업데이트하세요.
이 기능을 구현하려면 다음 단계를 따르세요.
HFP 기기 연결 중에 SCO 시작 및 해체를 적절하게 관리하고 활성 기기 변경사항을 처리할 수 있도록 활성 BT 변경사항을 오디오 프레임워크에 알립니다.
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)를 사용하여 오디오 프레임워크에 이 정보를 제공합니다.
그림 4. HFP 기기를 연결합니다.
오디오 프레임워크는 기존 브로드캐스트 대신
AudioManagerAudioDeviceCallback#onAudioDevicesAdded콜백을 사용하여 오디오 기기 상태를 나타냅니다.setCommunicationDevice(AudioDeviceInfodevice)을 SCO 연결을 시작하는 기본 제어 지점으로 사용하여 AHAL 스트림 제어를 구현합니다.HfpTransport::StartRequest가BluetoothAudioCtrlAck::PENDING를 반환하면 HFP 상태 시스템이 설정되지 않았으므로 AHAL이 요청을 다시 시도해야 합니다.
사용 사례
다음 섹션에서는 일반적인 중요한 사용자 여정 (CUJ)을 간략하게 설명합니다.
통신 호출 흐름
SCO 관리 리팩터링은 phoneStateChanged를 차단 함수로 변경합니다. 이 수정으로 인해 통신은 BluetoothInCallService.onCallAdded() 메서드 내에서 phoneStateChanged 실행이 완료될 때까지 기다린 후 오디오 프레임워크 API를 호출하여 SCO 생성을 시작합니다.
그림 5. 통신사를 통해 전화를 받거나 시작합니다.
VoIP 통화 흐름
오디오 프레임워크는 BluetoothHeadset.startScoUsingVirtualVoiceCall 메서드를 호출하여 프로세스를 시작합니다. BT 스택이 오디오 프레임워크에 결과를 제공하면 프레임워크는 AHAL에 startStream를 실행하도록 지시합니다. 다음 그림은 이 흐름을 보여줍니다.
그림 6. VOIP를 통해 전화를 받거나 시작합니다.
음성 인식
핸즈프리 (HF) 및 AG 시작 음성 인식의 경우 BT 스택은 AudioManager.setCommunicationDevice()를 사용하여 오디오 프레임워크에 SCO를 열도록 요청해야 합니다. 다음 그림을 참고하세요.
그림 7. 음성 인식 SCO 시작
오디오 연결
BT 스택은 음성 인식 중에 AudioManager.setCommunicationDevice(AudioDeviceInfo)로 오디오 프레임워크를 요청하여 SCO 연결을 시작합니다. 통화가 활성 상태이면 BT 스택은 통신 스택에서 BluetoothInCallService#requestBluetoothAudio를 요청합니다.
이 프로세스는 다음 그림에 나와 있습니다.
그림 8. 오디오 연결
유효성 검사 및 테스트
기능이 올바르게 통합되고 품질 표준을 충족하는지 확인하려면 기기 제조업체는 다음 테스트를 실행해야 합니다.
- CTS 인증 도구: 통화 중 오디오 라우팅의 대화형 테스트에 CTS 인증 도구를 사용합니다.
- 공급업체 테스트 모음 (VTS): VTS를 사용하여 AHAL과 BT AHAL 상호작용을 검증합니다.
요구사항
이 기능에는 다음 요구사항이 적용됩니다.
- AHAL: 구현에는 리팩터링된 SCO 관리 경로를 지원하는 호환 AHAL이 필요합니다.