Na tej stronie opisujemy, jak włączyć platformę audio i warstwę HAL audio (AHAL) do zarządzania synchronicznymi połączeniami zorientowanymi na połączenie (SCO), czyli procesem określanym jako Audio Managed SCO (AMSCO).
W Androidzie 17 i nowszych 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ą przesyłania strumieniowego dźwięku.
Dzięki scentralizowaniu własności routingu dźwięku w ramach platformy audio ta funkcja dostosowuje implementację warstwy abstrakcji sprzętowej (HAL) dla SCO do innych profili BT, takich jak profil zaawansowanej dystrybucji audio (A2DP) i LE Audio. Ta zmiana upraszcza interakcję między stosami telekomunikacyjnymi i BT, umożliwiając bardziej niezawodną i scentralizowaną architekturę routingu dźwięku.
Omówienie architektury
Architektura AMSCO centralizuje zarządzanie połączeniami SCO w ramach platformy audio Androida, która podejmuje decyzje dotyczące routingu na podstawie aktywności strumieniowania dźwięku. Ta architektura różni się od poprzedniego modelu, w którym stos BT zarządzał połączeniami. Role poszczególnych komponentów w tej architekturze są następujące:
AHAL rozpoczyna i zawiesza sesję SCO tylko wtedy, gdy spełnione są te warunki:
- Aktywny strumień jest przekierowywany do urządzenia SCO.
- Tryb „Tylko dźwięk” jest ustawiony i istnieje połączenie z urządzeniem SCO.
Framework audio uniemożliwia urządzeniu A2DP jednoczesne stosowanie poprawki, gdy spełnione są te konkretne kryteria. Platforma audio nie wysyła już do AHAL zmian stanu SCO ani zawieszeń A2DP.
Za zarządzanie SCO odpowiada platforma audio, więc stos BT nie wywołuje już funkcji łączenia ani rozłączania dźwięku. W przypadku przedwczesnego rozłączenia lub błędu połączenia SCO stos BT informuje platformę audio za pomocą AudioManager#onHfpAudioDisconnected.
Abonament
Przed wprowadzeniem refaktoryzacji zarządzania SCO zapoznaj się z informacjami w tej sekcji, aby ocenić zgodność i wymagania dotyczące architektury.
Zgodność wsteczna
Aby platforma nadal obsługiwała urządzenia, które mogą otrzymywać aktualizacje systemu operacyjnego bez aktualizowania AHAL lub BT AHAL, użyj właściwości systemu, aby wskazać, że należy włączyć nowe zarządzanie SCO. Starsza ścieżka jest zachowywana przez maksymalnie 6 lat w przypadkach, gdy właściwość systemowa jest wyłączona lub wersja HAL jest nieaktualna.
Konfigurowanie sesji HFP
Aby rozpocząć lub wstrzymać odtwarzanie, AHAL musi używać nowego typu sesji profilu zestawu słuchawkowego (HFP), podobnie jak w przypadku innych typów sesji BT. Stan strumienia jest ostatecznie zarządzany za pomocą różnych IBluetoothAudioProviders, które są wyliczane i tworzone przez klasę Factory w zależności od dostępnych ścieżek.
Stos BT w miarę możliwości korzysta z ścieżki odciążania przez sprzęt. 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 i wreszcie sprzęt CVSD jest preferowany przed oprogramowaniem CVSD.
Poniższe diagramy sekwencji przedstawiają interakcje między AHAL a stosem BT wymagane do ustalenia stanu strumienia.
Procedura odciążania przez sprzęt
Ilustracja 1 pokazuje, jak stosy AHAL i BT współpracują ze sobą, 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
Ilustracja 2 przedstawia proces obsługi danych audio, które wymagają przetwarzania przez oprogramowanie systemowe:
Rysunek 2. Procedura ścieżki danych oprogramowania.
Procedura ponownego negocjowania kodeka
Gdy bramka audio (AG) otrzyma nowe polecenie BT available codec (AT+BAC) , bramka AG ponownie uruchomi procedurę negocjacji kodeka. Ilustracja 3 przedstawia procedurę ponownego negocjowania kodeka:
Rysunek 3. Procedura ponownego negocjowania kodeka.
Wpływ na HeadsetStateMachine
Automat stanowy zestawu słuchawkowego w warstwie Java (reprezentowany przez klasę HeadsetStateMachine) pozostaje w dużej mierze bez zmian, 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 z natywnego stosu. Zmiany te są wywoływane przez polecenia AHAL na urządzeniach IBluetoothAudioProvider lub IBluetoothAudioPort.
Implementacja
Aby zintegrować refaktoryzację zarządzania SCO, zaktualizuj komunikację między stosem BT a platformą audio.
Aby wdrożyć tę funkcję, wykonaj te czynności:
Powiadamianie platformy audio o zmianach aktywnego połączenia BT, aby ułatwić prawidłowe zarządzanie inicjowaniem i zamykaniem połączeń SCO podczas łączenia urządzeń HFP oraz obsługiwać zmiany aktywnego urządzenia. Użyj
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo), aby przekazać te informacje do platformy audio.
Rysunek 4. Połącz urządzenie HFP.
Platforma audio używa wywołania zwrotnego
AudioManagerAudioDeviceCallback#onAudioDevicesAddedzamiast starszych transmisji do wskazywania stanu urządzenia audio.Wdróż sterowanie strumieniem AHAL, używając
setCommunicationDevice(AudioDeviceInfodevice)jako głównego punktu sterowania do rozpoczęcia połączenia SCO.Jeśli funkcja
HfpTransport::StartRequestzwróci wartośćBluetoothAudioCtrlAck::PENDING, AHAL musi ponowić próbę wysłania żądania, ponieważ automat stanów HFP nie został ustanowiony.
Przypadki użycia
W sekcjach poniżej przedstawiamy typowe główne ścieżki użytkownika.
Przebieg połączenia telekomunikacyjnego
Zmiany w SCO management refactor powodują, że funkcja phoneStateChanged staje się funkcją blokującą. Ta modyfikacja powoduje, że usługa telekomunikacyjna czeka na zakończenie wykonywania phoneStateChanged w metodzie BluetoothInCallService.onCallAdded(), zanim wywoła interfejs API platformy audio, aby rozpocząć tworzenie połączenia SCO.
Rysunek 5. Odbieranie i rozpoczynanie połączeń przez operatora.
Przebieg połączenia VoIP
Framework audio rozpoczyna proces, wywołując metodę BluetoothHeadset.startScoUsingVirtualVoiceCall. Gdy stos BT przekaże wynik do platformy audio, platforma poleci AHAL wykonanie startStream. Ten przepływ ilustruje poniższy rysunek:
Rysunek 6. Odbieranie i rozpoczynanie połączeń przez VoIP.
Rozpoznawanie głosu
W przypadku rozpoznawania głosu inicjowanego przez urządzenie HF i AG stos BT musi wysłać do platformy audio żądanie otwarcia SCO za pomocą funkcji AudioManager.setCommunicationDevice(). Ilustruje to poniższy rysunek:
Rysunek 7. Uruchamianie rozpoznawania głosu SCO.
Połączenie audio
Stos BT inicjuje połączenie SCO, wysyłając do platformy audio żądanie z parametrem AudioManager.setCommunicationDevice(AudioDeviceInfo) podczas rozpoznawania głosu. Jeśli połączenie jest aktywne, stos BT zamiast tego wysyła żądanie BluetoothInCallService#requestBluetoothAudio do stosu telekomunikacyjnego.
Ten proces przedstawia poniższy rysunek:
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żywaj narzędzia CTS Verifier do interaktywnego testowania routingu audio podczas połączeń.
- Pakiet testów dostawcy (VTS): sprawdź interakcje AHAL i BT AHAL za pomocą VTS.
Wymagania
Ta funkcja podlega tym wymaganiom:
- AHAL: wdrożenie wymaga zgodnego interfejsu AHAL, który obsługuje przekształconą ścieżkę zarządzania SCO.