Zmiana architektury zarządzanego SCO audio

Na tej stronie opisujemy, jak włączyć platformę audio i interfejs HAL audio (AHAL), aby zarządzać synchronicznymi połączeniami zorientowanymi na połączenie (SCO), czyli procesem zwanym zarządzanym przez audio SCO (AMSCO).

W Androidzie 17 i nowszych wersjach platforma audio Androida używa funkcji zarządzania SCO do zarządzania routingiem SCO, który był pierwotnie obsługiwany przez platformę Bluetooth (BT). Ta migracja przenosi stan połączenia SCO ze stanu należącego do platformy BT do stanu będącego konsekwencją aktywności przesyłania strumieniowego audio.

Dzięki scentralizowaniu własności routingu audio w platformie audio ta funkcja dostosowuje implementację warstwy abstrakcji sprzętowej audio (HAL) dla SCO do innych profili BT, takich jak profil zaawansowanej dystrybucji audio (A2DP) i LE Audio. Ta zmiana upraszcza interakcję między stosem telekomunikacyjnym a stosem BT, umożliwiając bardziej niezawodną i scentralizowaną architekturę routingu audio.

Omówienie architektury

Architektura AMSCO centralizuje zarządzanie połączeniami SCO w platformie audio Androida, która opiera decyzje dotyczące routingu na aktywności przesyłania strumieniowego audio. Ta architektura różni się od poprzedniego modelu, w którym połączeniami zarządzał stos BT. Role poszczególnych komponentów w tej architekturze są następujące:

AHAL rozpoczyna i wstrzymuje sesję SCO tylko wtedy, gdy spełnione są te warunki:

• Aktywny strumień jest połączony z urządzeniem SCO.
• Ustawiony jest tryb „Tylko dźwięk” i istnieje połączenie z urządzeniem SCO.

Gdy spełnione są te konkretne kryteria, platforma audio uniemożliwia urządzeniu A2DP jednoczesne połączenie. Platforma audio nie wysyła już do AHAL zmian stanu SCO ani wstrzymania A2DP.

Platforma audio zarządza SCO, więc stos BT nie wywołuje już funkcji łączenia ani rozłączania audio. W przypadku prewencyjnego rozłączenia SCO lub błędu stos BT informuje platformę audio za pomocą funkcji AudioManager#onHfpAudioDisconnected.

Abonament

Zanim zaimplementujesz zmianę zarządzania SCO, zapoznaj się z informacjami w tej sekcji, aby ocenić te wymagania dotyczące zgodności i architektury.

Zgodność wsteczna

Aby platforma nadal obsługiwała urządzenia, które mogą otrzymywać aktualizacje systemu operacyjnego bez aktualizowania interfejsów AHAL lub BT AHAL, użyj właściwości systemu, aby wskazać, że należy włączyć nowe zarządzanie SCO. W przypadku, gdy właściwość systemu jest wyłączona lub wersja HAL jest nieaktualna, ścieżka starsza jest zachowywana przez maksymalnie 6 lat.

Konfigurowanie sesji HFP

Aby rozpocząć lub wstrzymać odtwarzanie, AHAL musi używać nowego typu sesji profilu zestawu głośnomówiącego (HFP), podobnie jak w przypadku innych typów sesji BT. Stanem strumienia zarządza się ostatecznie za pomocą różnych interfejsów IBluetoothAudioProviders, które są wyliczane i tworzone przez klasę Factory w zależności od dostępnych ścieżek.

Stos BT używa ścieżki odciążania przez sprzęt, gdy tylko jest to możliwe. Preferencje dotyczące kodeków podczas negocjacji są następujące: sprzęt LC3 jest preferowany przed oprogramowaniem LC3, a następnie sprzęt mSBC, oprogramowanie mSBC, a na końcu sprzęt CVSD jest preferowany przed oprogramowaniem CVSD.

Te diagramy sekwencji szczegółowo opisują interakcje między AHAL a stosem BT wymagane do ustalenia stanu strumienia.

Procedura odciążania przez sprzęt

Rysunek 1 pokazuje, jak AHAL i stos BT koordynują się, aby utworzyć bezpośrednią ścieżkę danych sprzętowych dla dźwięku SCO:

Rysunek 1. Procedura odciążania przez sprzęt.

Procedura ścieżki danych oprogramowania

Rysunek 2 przedstawia proces obsługi danych audio, które wymagają przetwarzania przez oprogramowanie systemowe:

Rysunek 2. Procedura ścieżki danych oprogramowania.

Procedura ponownej negocjacji kodeka

Gdy brama audio (AG) otrzyma nowe polecenie AT+BAC dostępne w BT, AG ponownie uruchomi procedurę negocjacji kodeka. Rysunek 3 przedstawia procedurę ponownej negocjacji kodeka:

Rysunek 3. Procedura ponownej negocjacji kodeka.

Wpływ na HeadsetStateMachine

Automat stanów zestawu słuchawkowego w warstwie Java (reprezentowany przez klasę HeadsetStateMachine) pozostaje w dużej mierze niezmieniony, z wyjątkiem stanu AUDIO_CONNECTED, który jest sterowany przez zdarzenia stosu natywnego. W warstwie Java system nie inicjuje już funkcji connectAudioNative ani disconnectAudioNative. Zamiast tego system reaguje na zmiany stanu połączenia audio ze stosu natywnego. Te zmiany są wywoływane przez polecenia AHAL w interfejsach IBluetoothAudioProvider lub IBluetoothAudioPort.

Implementacja

Aby zintegrować zmianę zarządzania SCO, zaktualizuj komunikację między stosem BT a platformą audio.

Aby zaimplementować tę funkcję, wykonaj te czynności:

1. Powiadom platformę audio o zmianach w aktywnym BT, aby ułatwić prawidłowe zarządzanie inicjowaniem i zamykaniem SCO podczas połączeń z urządzeniami HFP oraz obsługiwać zmiany aktywnego urządzenia. Aby przekazać te informacje platformie audio, użyj funkcji AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo).

   

   Rysunek 4. Łączenie urządzenia HFP.

   Platforma audio używa wywołania zwrotnego AudioManagerAudioDeviceCallback#onAudioDevicesAdded zamiast starszych transmisji, aby wskazać stan urządzenia audio.

2. Zaimplementuj sterowanie strumieniem AHAL za pomocą setCommunicationDevice(AudioDeviceInfodevice) jako głównego punktu sterowania do rozpoczęcia połączenia SCO.

   Jeśli funkcja HfpTransport::StartRequest zwróci wartość BluetoothAudioCtrlAck::PENDING, AHAL musi ponowić próbę, ponieważ automat stanów HFP nie jest ustanowiony.

Przypadki użycia

W kolejnych sekcjach opisujemy typowe najważniejsze ścieżki użytkownika.

Przebieg połączenia telekomunikacyjnego

Zmiana zarządzania SCO zmienia funkcję phoneStateChanged w funkcję blokującą. Ta modyfikacja powoduje, że telekomunikacja czeka na zakończenie wykonania funkcji phoneStateChanged w metodzie BluetoothInCallService.onCallAdded, zanim wywoła interfejs API platformy audio, aby rozpocząć tworzenie SCO.

Rysunek 5. Odbieranie lub rozpoczynanie połączenia za pomocą telekomunikacji.

Przebieg połączenia VoIP

Platforma audio rozpoczyna proces, wywołując metodę BluetoothHeadset.startScoUsingVirtualVoiceCall. Gdy stos BT przekaże wynik do platformy audio, platforma poleci AHAL wykonanie funkcji startStream. Ten proces ilustruje rysunek poniżej:

Rysunek 6. Odbieranie lub rozpoczynanie połączenia za pomocą VoIP.

Rozpoznawanie głosu

W przypadku rozpoznawania głosu inicjowanego przez HF i AG stos BT musi poprosić platformę audio o otwarcie SCO za pomocą funkcji AudioManager.setCommunicationDevice. Ilustruje to rysunek poniżej:

Rysunek 7. Inicjowanie SCO rozpoznawania głosu.

Połączenie audio

Stos BT inicjuje połączenie SCO, wysyłając żądanie do platformy audio za pomocą AudioManager.setCommunicationDevice(AudioDeviceInfo) podczas rozpoznawania głosu. Jeśli połączenie jest aktywne, stos BT zamiast tego wysyła żądanie BluetoothInCallService#requestBluetoothAudio ze stosu telekomunikacyjnego.

Ten proces przedstawia rysunek poniżej:

Rysunek 8. Połączenie audio.

Weryfikacja i testowanie

Aby sprawdzić, czy funkcja jest prawidłowo zintegrowana i spełnia standardy jakości, producenci urządzeń muszą przeprowadzić te testy:

• CTS Verifier: użyj narzędzia CTS Verifier do interaktywnego testowania routingu audio podczas połączeń.
• Vendor Test Suite (VTS): zweryfikuj interakcje AHAL i BT AHAL za pomocą VTS.

Wymagania

Ta funkcja podlega tym wymaganiom:

• AHAL: implementacja wymaga zgodnego interfejsu AHAL, który obsługuje zmienioną ścieżkę zarządzania SCO.