Audio managed SCO rearchitecture

This page describes how to enable the audio framework and audio HAL (AHAL) to manage synchronous connection-oriented (SCO) connections, a process identified as Audio Managed SCO (AMSCO).

In Android 17 and higher, the Android audio framework uses the SCO management feature to manage SCO routing, which was originally handled by the Bluetooth (BT) framework. This migration moves the SCO connection status from a state owned by the BT framework to a downstream consequence of audio streaming activity.

By centralizing ownership of audio routing within the audio framework, this feature aligns the audio hardware abstraction layer (HAL) implementation for SCO with other BT profiles like Advanced Audio Distribution Profile (A2DP) and LE Audio. This refactor simplifies the interaction between the telecom and BT stacks, enabling a more robust and centralized audio routing architecture.

Architectural overview

The AMSCO architecture centralizes SCO connection management within the Android audio framework, which bases routing decisions on audio streaming activity. This architecture contrasts with the previous model where the BT stack managed connections. The roles of each component in this architecture are as follows:

The AHAL starts and suspends the SCO session only if the following conditions are met:

• An active stream is patched to a SCO device.
• The audio mode is set, and a patch to a SCO device exists.

The audio framework prevents an A2DP device from having a concurrent patch when these specific criteria are satisfied. The audio framework no longer sends SCO state changes or A2DP suspends to the AHAL.

The audio framework handles SCO management, so the BT stack no longer calls connect or disconnect audio. In cases of preemptive SCO disconnection or error, the BT stack informs the audio framework with AudioManager#onHfpAudioDisconnected.

Plan

Use the information in this section to assess the following compatibility and architectural requirements before implementing the SCO management refactor.

Backward compatibility

To enable the framework to continue to support devices that might receive OS updates without updating their AHALs or BT AHALs, use a system property to indicate that the new SCO management must be enabled. The legacy path is preserved for up to six years in cases where the system property is disabled or the HAL version is out of date.

Set up the HFP session

The AHAL must use the new hands-free profile (HFP) session type to start or suspend playback, similar to other BT session types. The stream state is ultimately managed using different IBluetoothAudioProviders, which are enumerated and built by a Factory class depending on the available pathways.

The BT stack uses a hardware offload path whenever possible. The preference for codecs during negotiation follows this order: LC3 hardware is preferred over LC3 software, followed by mSBC hardware, then mSBC software, and finally CVSD hardware is preferred over CVSD software.

The following sequence diagrams detail the interactions between the AHAL and the BT stack required to establish the stream state.

Hardware offload procedure

Figure 1 illustrates how the AHAL and BT stack coordinate to establish a direct hardware data path for SCO audio:

Figure 1. Hardware offload procedure.

Software data path procedure

Figure 2 illustrates the process for handling audio data that requires system software processing:

Figure 2. Software data path procedure.

Codec renegotiation procedure

When the audio gateway (AG) receives a new BT available codec (AT+BAC) command, the AG restarts the codec negotiation procedure. Figure 3 illustrates the codec renegotiation procedure:

Figure 3. Codec renegotiation procedure.

Impact on HeadsetStateMachine

The Java layer headset state machine (represented by the HeadsetStateMachine class) remains largely unchanged with the exception of the AUDIO_CONNECTED state, which is driven by native stack events. Within the Java layer, the system no longer initiates connectAudioNative or disconnectAudioNative. Instead, the system responds to audio connection state changes from the native stack. These changes are triggered by the AHAL's commands on IBluetoothAudioProvider or IBluetoothAudioPort.

Implementation

To integrate the SCO management refactor, update the communication between the BT stack and the audio framework.

Follow these steps to implement the feature:

1. Notify the audio framework about changes to the active BT to help with the proper management of SCO initiation and teardown during HFP device connections and to handle active device changes. Use AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) to provide this information to the audio framework.

   

   Figure 4. Connect HFP device.

   The audio framework uses the AudioManagerAudioDeviceCallback#onAudioDevicesAdded callback instead of legacy broadcasts to indicate the audio device state.

2. Implement AHAL stream control using setCommunicationDevice(AudioDeviceInfodevice) as the primary control point to start the SCO connection.

   If HfpTransport::StartRequest returns BluetoothAudioCtrlAck::PENDING, the AHAL must retry the request because the HFP state machine isn't established.

Use cases

The following sections outline typical critical user journeys (CUJs).

Telecom call flow

The SCO management refactor changes phoneStateChanged into a blocking function. This modification causes telecom to wait for the phoneStateChanged execution within the BluetoothInCallService.onCallAdded() method to complete before it invokes the audio framework API to start SCO creation.

Figure 5. Answer or start a call through telecom.

VOIP call flow

The audio framework starts the process by calling the BluetoothHeadset.startScoUsingVirtualVoiceCall method. After the BT stack provides a result to the audio framework, the framework directs the AHAL to execute startStream. The following figure illustrates this flow:

Figure 6. Answer or start a call through VOIP.

Voice recognition

For both hands-free (HF) and AG initiated voice recognition, the BT stack must request the audio framework to open SCO using AudioManager.setCommunicationDevice(). This is illustrated in the following figure:

Figure 7. Voice recognition SCO initiation.

Audio connection

The BT stack initiates an SCO connection by requesting the audio framework with AudioManager.setCommunicationDevice(AudioDeviceInfo) during voice recognition. If a call is active, the BT stack instead requests BluetoothInCallService#requestBluetoothAudio from the telecom stack.

This process is shown in the following figure:

Figure 8. Audio connection.

Validation and testing

To validate that the feature is correctly integrated and meets quality standards, device manufacturers must run the following tests:

• CTS Verifier: Use the CTS Verifier for interactive testing of audio routing during calls.
• Vendor Test Suite (VTS): Validate the AHAL and BT AHAL interactions using VTS.

Requirements

This feature is subject to the following requirements:

• AHAL: Implementation requires a compatible AHAL that supports the refactored SCO management path.