オーディオ マネージド SCO の再アーキテクチャ

このページでは、オーディオ フレームワークとオーディオ HAL（AHAL）を有効にして、同期接続指向型（SCO）接続を管理する方法について説明します。このプロセスは、オーディオ マネージド SCO（AMSCO）と呼ばれます。

Android 17 以降では、Android オーディオ フレームワークは SCO 管理機能を使用して SCO ルーティングを管理します。このルーティングは、元々 Bluetooth（BT）フレームワークによって処理されていました。この移行により、SCO 接続ステータスは BT フレームワークが所有する状態から、オーディオ ストリーミング アクティビティの下流の結果に移行します。

この機能では、オーディオ ルーティングの所有権をオーディオ フレームワーク内に集中させることで、SCO の Hardware Abstraction Layer（HAL）の実装を、Advanced Audio Distribution Profile（A2DP）や LE Audio などの他の BT プロファイルと整合させます。このリファクタリングにより、テレコム スタックと BT スタック間のやり取りが簡素化され、より堅牢で一元化されたオーディオ ルーティング アーキテクチャが可能になります。

アーキテクチャの概要

AMSCO アーキテクチャでは、SCO 接続管理を Android オーディオ フレームワーク内に集中させます。このフレームワークは、オーディオ ストリーミング アクティビティに基づいてルーティングを決定します。このアーキテクチャは、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 オーディオの直接ハードウェア データパスを確立する方法を示しています。

hw-offload-procedure

図 1.ハードウェア オフロード手順。

ソフトウェア データパス手順

図 2 は、システム ソフトウェア処理を必要とするオーディオ データを処理するプロセスを示しています。

sw-data-path

図 2.ソフトウェア データパス手順。

コーデックの再ネゴシエーション手順

オーディオ ゲートウェイ（AG）が新しい BT 使用可能コーデック（AT+BAC）コマンドを受信すると、AG はコーデックのネゴシエーション手順を再開します。図 3 は、コーデックの再ネゴシエーション手順を示しています。

codec-renego-process

図 3. コーデックの再ネゴシエーション手順。

HeadsetStateMachine への影響

Java レイヤのヘッドセット ステートマシン（HeadsetStateMachine クラスで表される）は、ネイティブ スタック イベントによって駆動される AUDIO_CONNECTED 状態を除き、ほとんど変更されていません。 Java レイヤ内では、システムは connectAudioNative または disconnectAudioNative を開始しなくなりました。代わりに、ネイティブ スタックからのオーディオ接続状態の変更に応答します。これらの変更は、IBluetoothAudioProvider または IBluetoothAudioPort に対する AHAL のコマンドによってトリガーされます。

実装

SCO 管理のリファクタリングを統合するには、BT スタックとオーディオ フレームワーク間の通信を更新します。

この機能を実装する手順は次のとおりです。

  1. アクティブな BT の変更をオーディオ フレームワークに通知して、HFP デバイス接続時の SCO の開始と終了の適切な管理を支援し、アクティブなデバイスの変更を処理します。AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) を使用して、この情報をオーディオ フレームワークに提供します。

    conn-hfp

    図 4.HFP デバイスを接続する。

    オーディオ フレームワークは、レガシー ブロードキャストの代わりに AudioManagerAudioDeviceCallback#onAudioDevicesAdded コールバックを使用して、オーディオ機器の状態を示します。

  2. setCommunicationDevice(AudioDeviceInfodevice) をプライマリ制御ポイントとして使用して、AHAL ストリーム制御を実装し、SCO 接続を開始します。

    HfpTransport::StartRequest が BluetoothAudioCtrlAck::PENDING を返した場合、HFP ステートマシンが確立されていないため、AHAL はリクエストを再試行する必要があります。

ユースケース

次のセクションでは、一般的なクリティカル ユーザー ジャーニー（CUJ）の概要について説明します。

テレコムの通話フロー

SCO 管理のリファクタリングにより、phoneStateChanged がブロッキング関数に変更されます。この変更により、テレコムは BluetoothInCallService.onCallAdded() メソッド内の phoneStateChanged の実行が完了するまで待機してから、オーディオ フレームワーク API を呼び出して SCO の作成を開始します。

call-telecom

図 5.テレコム経由で電話に出るか、電話をかける。

VOIP 通話フロー

オーディオ フレームワークは、BluetoothHeadset.startScoUsingVirtualVoiceCall メソッドを呼び出してプロセスを開始します。BT スタックがオーディオ フレームワークに結果を提供すると、フレームワークは AHAL に startStream の実行を指示します。次の図に、このフローを示します。

call-voip

図 6.VOIP 経由で電話に出るか、電話をかける。

音声認識

ハンズフリー（HF）と AG のどちらが開始した音声認識の場合でも、BT スタックは AudioManager.setCommunicationDevice() を使用して SCO を開くようにオーディオ フレームワークにリクエストする必要があります。次の図にこれを示します。

voice-recog

図 7.音声認識 SCO の開始。

音声接続

BT スタックは、音声 認識中に AudioManager.setCommunicationDevice(AudioDeviceInfo)を使用してオーディオ フレームワークにリクエストすることで、SCO 接続を開始します。通話がアクティブな場合、BT スタックはテレコム スタックから BluetoothInCallService#requestBluetoothAudio をリクエストします。

このプロセスを次の図に示します。

audio-conn

図 8.音声接続。

検証とテスト

この機能が正しく統合され、品質基準を満たしていることを検証するには、デバイス メーカーは次のテストを実施する必要があります。

  • CTS 検証ツール: 通話中のオーディオ ルーティングのインタラクティブ テストには、CTS 検証ツールを使用します。
  • ベンダー テストスイート（VTS）: VTS を使用して、AHAL と BT AHAL のやり取りを検証します。

要件

この機能には次の要件があります。

  • AHAL: 実装には、リファクタリングされた SCO 管理パスをサポートする互換性のある AHAL が必要です。