Arsitektur ulang SCO yang dikelola audio

Halaman ini menjelaskan cara mengaktifkan framework audio dan HAL audio (AHAL) untuk mengelola koneksi berorientasi koneksi (SCO) sinkron, sebuah proses yang diidentifikasi sebagai Audio Managed SCO (AMSCO).

Di Android 17 dan yang lebih tinggi, framework audio Android menggunakan fitur pengelolaan SCO untuk mengelola perutean SCO, yang awalnya ditangani oleh framework Bluetooth (BT). Migrasi ini memindahkan status koneksi SCO dari status yang dimiliki oleh framework BT ke konsekuensi hilir aktivitas streaming audio.

Dengan memusatkan kepemilikan perutean audio dalam framework audio, fitur ini menyelaraskan penerapan lapisan abstraksi hardware (HAL) audio untuk SCO dengan profil BT lainnya seperti Advanced Audio Distribution Profile (A2DP) dan LE Audio. Refaktor ini menyederhanakan interaksi antara stack telekomunikasi dan BT, sehingga memungkinkan arsitektur perutean audio yang lebih andal dan terpusat.

Ringkasan arsitektur

Arsitektur AMSCO memusatkan pengelolaan koneksi SCO dalam framework audio Android, yang mendasarkan keputusan perutean pada aktivitas streaming audio. Arsitektur ini berbeda dengan model sebelumnya yang menggunakan stack BT untuk mengelola koneksi. Peran setiap komponen dalam arsitektur ini adalah sebagai berikut:

AHAL memulai dan menangguhkan sesi SCO hanya jika kondisi berikut terpenuhi:

  • Aliran aktif dipatch ke perangkat SCO.
  • Mode audio disetel, dan patch ke perangkat SCO ada.

Framework audio mencegah perangkat A2DP memiliki patch serentak saat kriteria khusus ini terpenuhi. Framework audio tidak lagi mengirimkan perubahan status SCO atau penangguhan A2DP ke AHAL.

Framework audio menangani pengelolaan SCO, sehingga stack BT tidak lagi memanggil audio connect atau disconnect. Dalam kasus pemutusan koneksi atau error SCO secara dini, stack BT memberi tahu framework audio dengan AudioManager#onHfpAudioDisconnected.

Rencana

Gunakan informasi di bagian ini untuk menilai persyaratan kompatibilitas dan arsitektur berikut sebelum menerapkan refaktor pengelolaan SCO.

Kompatibilitas mundur

Agar framework dapat terus mendukung perangkat yang mungkin menerima update OS tanpa mengupdate AHAL atau AHAL BT, gunakan properti sistem untuk menunjukkan bahwa pengelolaan SCO baru harus diaktifkan. Jalur lama dipertahankan hingga enam tahun jika properti sistem dinonaktifkan atau versi HAL sudah tidak berlaku.

Menyiapkan sesi HFP

AHAL harus menggunakan jenis sesi profil handsfree (HFP) baru untuk memulai atau menangguhkan pemutaran, mirip dengan jenis sesi BT lainnya. Status streaming pada akhirnya dikelola menggunakan IBluetoothAudioProviders yang berbeda, yang di-enum dan dibangun oleh class Factory, bergantung pada jalur yang tersedia.

Stack BT menggunakan pengurangan beban hardware jika memungkinkan. Preferensi codec selama negosiasi mengikuti urutan ini: hardware LC3 lebih disukai daripada software LC3, diikuti oleh hardware mSBC, lalu software mSBC, dan terakhir hardware CVSD lebih disukai daripada software CVSD.

Diagram urutan berikut menjelaskan interaksi antara AHAL dan stack BT yang diperlukan untuk membuat status streaming.

Prosedur pengurangan beban hardware

Gambar 1 menggambarkan cara AHAL dan stack BT berkoordinasi untuk membuat jalur data hardware langsung untuk audio SCO:

hw-offload-procedure

Gambar 1. Prosedur pengurangan beban hardware.

Prosedur jalur data software

Gambar 2 mengilustrasikan proses penanganan data audio yang memerlukan pemrosesan software sistem:

sw-data-path

Gambar 2. Prosedur jalur data software.

Prosedur negosiasi ulang codec

Saat menerima perintah codec yang tersedia BT baru (AT+BAC), gateway audio (AG) akan memulai ulang prosedur negosiasi codec. Gambar 3 mengilustrasikan prosedur negosiasi ulang codec:

codec-renego-process

Gambar 3. Prosedur negosiasi ulang codec.

Dampak pada HeadsetStateMachine

Mesin status headset lapisan Java (diwakili oleh class HeadsetStateMachine) sebagian besar tidak berubah, kecuali status AUDIO_CONNECTED, yang didorong oleh peristiwa stack native. Dalam lapisan Java, sistem tidak lagi memulai connectAudioNative atau disconnectAudioNative. Sebagai gantinya, sistem merespons perubahan status koneksi audio dari stack native. Perubahan ini dipicu oleh perintah AHAL di IBluetoothAudioProvider atau IBluetoothAudioPort.

Penerapan

Untuk mengintegrasikan refaktor pengelolaan SCO, perbarui komunikasi antara stack BT dan framework audio.

Ikuti langkah-langkah berikut untuk menerapkan fitur ini:

  1. Memberi tahu framework audio tentang perubahan pada BT aktif untuk membantu pengelolaan yang tepat atas inisiasi dan penghentian SCO selama koneksi perangkat HFP dan untuk menangani perubahan perangkat aktif. Gunakan AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) untuk memberikan informasi ini ke framework audio.

    conn-hfp

    Gambar 4. Hubungkan perangkat HFP.

    Framework audio menggunakan callback AudioManagerAudioDeviceCallback#onAudioDevicesAdded alih-alih siaran lama untuk menunjukkan status perangkat audio.

  2. Terapkan kontrol streaming AHAL menggunakan setCommunicationDevice(AudioDeviceInfodevice) sebagai titik kontrol utama untuk memulai koneksi SCO.

    Jika HfpTransport::StartRequest menampilkan BluetoothAudioCtrlAck::PENDING, AHAL harus mencoba lagi permintaan karena state machine HFP belum dibuat.

Kasus penggunaan

Bagian berikut menguraikan perjalanan penting pengguna (CUJ) yang umum.

Alur panggilan telekomunikasi

Refaktor pengelolaan SCO mengubah phoneStateChanged menjadi fungsi pemblokiran. Modifikasi ini menyebabkan telekomunikasi menunggu penyelesaian eksekusi phoneStateChanged dalam metode BluetoothInCallService.onCallAdded() sebelum memanggil API framework audio untuk memulai pembuatan SCO.

call-telecom

Gambar 5. Menjawab atau memulai panggilan melalui telekomunikasi.

Alur panggilan VOIP

Framework audio memulai proses dengan memanggil metode BluetoothHeadset.startScoUsingVirtualVoiceCall. Setelah stack BT memberikan hasil ke framework audio, framework mengarahkan AHAL untuk mengeksekusi startStream. Gambar berikut menggambarkan alur ini:

call-voip

Gambar 6. Menjawab atau memulai panggilan melalui VOIP.

Pengenalan suara

Untuk pengenalan suara yang dimulai oleh AG dan handsfree (HF), stack BT harus meminta framework audio untuk membuka SCO menggunakan AudioManager.setCommunicationDevice(). Hal ini diilustrasikan dalam gambar berikut:

voice-recog

Gambar 7. Inisiasi SCO pengenalan suara.

Koneksi audio

Stack BT memulai koneksi SCO dengan meminta framework audio dengan AudioManager.setCommunicationDevice(AudioDeviceInfo) selama pengenalan suara. Jika panggilan aktif, stack BT akan meminta BluetoothInCallService#requestBluetoothAudio dari stack telekomunikasi.

Proses ini ditunjukkan dalam gambar berikut:

audio-conn

Gambar 8. Koneksi audio.

Validasi dan pengujian

Untuk memvalidasi bahwa fitur diintegrasikan dengan benar dan memenuhi standar kualitas, produsen perangkat harus menjalankan pengujian berikut:

  • CTS Verifier: Gunakan CTS Verifier untuk pengujian interaktif perutean audio selama panggilan.
  • Vendor Test Suite (VTS): Memvalidasi interaksi AHAL dan BT AHAL menggunakan VTS.

Persyaratan

Fitur ini tunduk pada persyaratan berikut:

  • AHAL: Implementasi memerlukan AHAL yang kompatibel yang mendukung jalur pengelolaan SCO yang di-refactor.