Wytyczne dotyczące certyfikacji przełącznika dźwięku

Przygotowanie do certyfikacji

  • Przygotuj urządzenia testowe.
    • Potrzebne będą 5 urządzeń z Androidem.
      • Urządzenia te muszą zawierać:
        • co najmniej 1 Android T (13) i 1 Android V (15);
        • Co najmniej 1 Samsung i 1 Pixel.
        • Na przykład:
          • 1 OnePlus (Android 10).
          • 3 Samsung (Android 11, 12, 13).
          • 1 Pixel (Android 15).
    • Jedno urządzenie bez przełącznika dźwięku:
      • dowolny iPhone, komputer PC, laptop z Bluetooth (BT) lub telefon z Androidem, na którym wyłączono przełącznik dźwięku.
        • Możesz wyłączyć przełącznik Audio w ustawieniach szczegółów urządzenia Bluetooth.
      • W przypadku testu 2.8 połączenia wielopunktowego (MP) oprócz 5 testowych telefonów potrzebne jest urządzenie bez przełącznika dźwięku.

  • Dołącz do grupy testowej przełącznika Audio za pomocą kont testowych, aby wyświetlać powiadomienia debugowania na telefonach testowych.

    • Umożliwia to Google zbieranie danych testowych w Google Analytics.

Klasyczny z A2DP + HFP

  • Upewnij się, że na wszystkich urządzeniach z Androidem jest zainstalowana usługa GmsCore w wersji 23.xx.xx lub nowszej.

BLE z LE Audio

  • Co najmniej 2 telefony referencyjne muszą obsługiwać LE Audio.
    • Na przykład jeden telefon Samsung i jeden telefon Pixel obsługujące LE Audio.
  • Upewnij się, że na wszystkich urządzeniach z Androidem jest zainstalowana usługa GmsCore w wersji 24.33.xx lub nowszej.

Kryteria certyfikacji

  • Wskaźnik sukcesu w przypadku przełączania na docelowe musi przekraczać 95% we wszystkich testach.

  • W przypadku testów wymagających przełączenia połączenia profilu i stanu przełącznika w co najmniej 75% przypadków muszą się one zakończyć w ciągu 3 sekund od wywołania zdarzeń audio.

Klasyczny z A2DP + HFP

Testy samodzielne należy przeprowadzać w tych kombinacjach:

  • Telefon A=Android S (12) + Telefon B=Android T (13)
  • Telefon A=Android T (13) + telefon B=Android S (12)

BLE z LE Audio

Testy samodzielne należy przeprowadzać w tych kombinacjach:

  • Telefon A: klasyczny Bluetooth, telefon B: klasyczny Bluetooth
  • Telefon A: LE Audio, telefon B: BT Classic
  • Telefon A: klasyczny BT, telefon B: LE Audio

Opcjonalnie dostawcy, którzy obsługują połączenia Dual LE Audio, powinni przetestować:

  • Telefon A: LE Audio, telefon B: LE Audio

Przewodnik dotyczący testowania

Przygotowanie urządzenia testowanego (DUT)

  • Sprawdź, czy urządzenie BT nie zostało wcześniej sparowane z żadnym telefonem zalogowanym na konto Google testowe.
    • Jeśli urządzenie jest sparowane z kontem Google używanym do testowania, wykonaj te czynności, aby anulować parowanie:
      • W sekcji sparowanych urządzeń:
        • Otwórz ustawienia Bluetootha.
        • Wybierz „Zapomnij o tym urządzeniu”.
        • Włącz i wyłącz tryb samolotowy.
    • Upewnij się, że opcja „Automatycznie zapisuj urządzenia” jest włączona.
      • Ten przełącznik jest domyślnie wyłączony.
      • Opcję tę znajdziesz w sekcji Ustawienia > Google > Urządzenia > Zapisane urządzenia (po jednym na DUT).
    • Włącz na urządzeniu Bluetooth tryb parowania.
    • Parowanie początkowego urządzenia Bluetooth (A).
    • sparować kolejne urządzenia Bluetooth z innymi urządzeniami (B, C, D itd.).

Zakres

  • Wszystkie słuchawki przeprowadzają testy na różnych kartach w raporcie samokontroli BT Classic lub BT LE Audio.
  • Słuchawki obsługujące tylko tryb SinglePoint (SP) umożliwiają:
    • Karta Generic_test.
  • Słuchawki obsługujące tryb MP:
    • Karta Generic_test.
    • Karta Multipoint_only.
  • Słuchawki MP, które można przełączyć w tryb SP, obsługują:
    • Karta Generic_test z wyłączonym MP.
    • Karta Generic_test z włączonym MP.
    • Karta Multipoint_only z włączonym połączeniem wielopunktowym.

Wypełnianie raportu dotyczącego przerwy i samotestu

  • Utwórz kopię raportów samosprawdzeń BT Classic lub BT LE Audio.
  • Uruchom wszystkie przypadki testowe co najmniej 2 razy.

  • Testy powinny być wykonywane w takiej formie:

Klasyczny z A2DP + HFP

  • Urządzenie B będzie głównym urządzeniem testowym.
    • Wpisz szczegóły urządzenia B w polach „Telefon” i „System operacyjny” u góry szablonu.

Przykładowy przypadek testowy:

  • Telefony do testowania:

    • Urządzenie 1: Samsung (Android 13)
    • Urządzenie 2: Pixel (Android 12 lub 13) i inne.

  • Wykonane testy:

    • Uruchomienie 1. Urządzenie A=Samsung S10+ (12), urządzenie B=Pixel 7 Pro (13) kolumna D: telefon=Pixel 7 Pro, system operacyjny=Android 13
    • Bieg 2. Urządzenie A=Pixel 7 Pro (13), urządzenie B=Pixel 6(12) kolumna E: telefon=Pixel 6, system operacyjny=Android 12

Przykład wypełnionego testu w szablonie testu samodzielnego:

Ten obraz pokazuje wyniki przykładowego testu

BLE z LE Audio

  1. Urządzenie A=Android V (15) + urządzenie B=Android T (13)
  2. Urządzenie A=Android T (13) + urządzenie B=Android V (15)
  3. Urządzenie A=Android T (13) + urządzenie B=Android S (12)
  4. Urządzenie A=Android T (15) + urządzenie B=Android V (15)
  5. Urządzenie B będzie głównym urządzeniem testowym.
    • Wpisz szczegóły urządzenia B w polach „Telefon” i „System operacyjny” u góry szablonu.

Przykładowy przypadek testowy:

  • Telefony do testowania:

    • Urządzenie 1: Samsung (Android 13)
    • Urządzenie 2: Pixel (Android 15) i inne.

  • Wykonane testy:

    • [LEA+BT]: Device A= Pixel 8 (15), Device B=Pixel 7 pro (13) column D: Phone=Pixel 7 pro, OS=Android 13
    • [BT+LEA]: Urządzenie A=Pixel 7 (13), urządzenie B=Pixel 8 (Android 15) kolumnaE: telefon=Pixel 8, system operacyjny=Android 15
    • [BT+BT]: urządzenie A=Pixel 7 Pro (13), urządzenie B=Samsung S10+ (12) kolumnaE: telefon=Samsung S10+, system operacyjny=Android 12
    • [LEA+LEA]: Device A=Pixel 8 (15), Device B=Pixel 8(15) column E: Phone=Pixel 8, OS=Android 15

Przykład wypełnionego testu w szablonie testu samodzielnego:

Ten obraz pokazuje wyniki przykładowego testu

Zdarzenia audio:

  • 4 typy testowanych zdarzeń audio i zalecane aplikacje do testowania:

    1. Połączenie:
      1. Wbudowana aplikacja telefoniczna.
    2. VoIP: dowolna aplikacja VoIP, np.:
      1. Aplikacja do testowania przełącznika dźwięku.
      2. Facebook Messenger.
      3. Linia.
      4. WhatsApp.
      5. Google Meet.
      6. Google Meet.
    3. Multimedia: dowolny odtwarzacz dźwięku, na przykład:
      1. Aplikacja do testowania przełącznika dźwięku.
      2. YouTube Music.
      3. Apple Music.
      4. Spotify.
      5. Podcastach Google
    4. Gra:
      1. Aplikacja do testowania przełącznika dźwięku.

Informacje debugowania:

  • Powiadomienia są włączane po dołączeniu do grupy fp-sass-partner-test. Oto przykłady:

    • Powiadomienie o najnowszym stanie:

    Rysunek 1. Pokazuje on komunikat „Ostatnie powiadomienie o stanie”.

    • Brak powiadomienia o przełączeniu:

    Rysunek 2. Pokazuje on komunikat „Brak powiadomienia o przełączeniu”.

    • Powiadomienie o opóźnieniu przełączenia:

    Rysunek 3. Ten obrazek pokazuje komunikat „Powiadomienie o opóźnieniu przełączenia”.

Pomiar opóźnienia

  • Istnieją 2 rodzaje opóźnienia przełączania:
    1. Łączenie profilu Bluetooth z niepołączonym urządzeniem Seeker
      • Obejmuje to wszystkie przypadki dotyczące trybu SinglePoint i niektóre przypadki dotyczące trybu Multipoint, w których urządzenie sterujące (urządzenie B) jest odłączone.
    2. Przełączanie aktywnego połączonego Seekera.
      • Obejmuje to niektóre przypadki MP, w których docelowe urządzenie Seeker (urządzenie B) jest już połączone.
  • Informacje o czasie oczekiwania można pobrać na 2 sposoby:
    1. Całą latencję można wyodrębnić za pomocą polecenia adb.
      • Szczegółowe informacje znajdziesz w sekcji Czas oczekiwania na zrzut.
      • To polecenie może podać i zapisać opóźnienie po zakończeniu co najmniej jednego przypadku testowego.
    2. Używając aplikacji do testowania przełącznika dźwięku.
      • Aplikacja działająca na urządzeniu docelowym Seekera po przełączeniu wyświetli opóźnienie.
      • Jeśli nie nastąpiła zmiana, aplikacja wyświetli przyczynę „brak zmiany”.

Aplikacja testowa przełącznika dźwięku:

  • Użycie aplikacji do wywołania zdarzeń VoIP/Media/Gry podczas testu samodzielnego uprości konfigurację testu i zmniejszy opóźnienie Seekera.
    • Najnowszą wersję możesz pobrać tutaj.
    • Test VoIP w przypadku LE Audio wymaga ręcznego włączenia zasady: > adb root > adb shell settings put global hidden_api_policy 1 > adb reboot
  • Instalacja aplikacji:
    • Skopiuj plik APK na telefon testowy i otwórz go.
    • Możesz też użyć polecenia adb install audio_test_app.apk.
  • Jeśli zobaczysz okno z prośbą o dostęp do powiadomień:
    1. kliknij „OK”.
    2. Na liście aplikacji wybierz „Test FP SASS”.
    3. Zezwalaj na dostęp do powiadomień.

Omówienie aplikacji:

Ilustracja przedstawiająca przykładową uruchomioną aplikację

  • Dostawca docelowy

    • Po kliknięciu tego przycisku wyświetli się lista sparowanych urządzeń Bluetooth. Wybierz ten, który chcesz przetestować.
    • Przyciski „Połącz” i „Odłącz” działają tak samo jak w szczegółach urządzenia w ustawieniach Bluetooth.

  • Bieżący stan

    • To pole zawiera ostatni stan połączenia, który Seeker otrzymał od dostawcy za pomocą reklamy BLE lub strumienia zdarzeń.
    • Tutaj wyświetlają się też powiadomienia o debugowaniu przełącznika dźwięku.

  • Typ poszukiwacza

    • Ta opcja umożliwia przełączanie urządzenia między strumieniami audio.

Typ dźwięku

Klasyczny z A2DP + HFP

  • VoIP
    • Wybranie tego trybu spowoduje zmianę trybu audio na AudioManager.MODE_IN_COMMUNICATION i wywołanie AudioManager.startBluetoothSco, a następnie odtwarzanie dźwięku z użyciem USAGE_VOICE_COMMUNICATION.
    • Typ strumienia to STREAM_VOICE_CALL.
    • Stan połączenia dostawcy powinien zmienić się na CONNECTED_HFP w ciągu 5 sekund.
  • Media
    • Wybranie tego trybu spowoduje odtwarzanie dźwięku obsługującego AVRCP. Typ użycia dźwięku: USAGE_MEDIA.
    • Stan połączenia dostawcy powinien się zmienić na CONNECTED_A2DP_WITH_AVRCP w ciągu 5 sekund.
    • Po rozpoczęciu lub zatrzymaniu stan połączenia może na krótko zmienić się na CONNECTED_A2DP_ONLY.
  • Gra
    • Wybranie tego trybu powoduje odtworzenie dźwięku, który nie obsługuje protokołu AVRCP. Typ użycia dźwięku: USAGE_GAME.
    • Stan połączenia dostawcy powinien zmienić się na CONNECTED_A2DP_ONLYw ciągu 5 sekund.

BLE z LE Audio

  • VoIP

    • Wybranie tego trybu spowoduje zmianę trybu audio na AudioManager.MODE_IN_COMMUNICATION i odtwarzanie dźwięku z USAGE_VOICE_COMMUNICATION.
    • Typ strumienia to STREAM_VOICE_CALL.
    • Stan połączenia dostawcy powinien zmienić się na CONNECTED_LE_AUDIO_CALLw ciągu 5 sekund.

  • Media

    • Po wybraniu tego trybu dźwięk zostanie odtworzony z typem strumienia STREAM_MUSIC. Typ wykorzystania dźwięku: USAGE_MEDIA.
    • Stan połączenia dostawcy powinien się zmienić na CONNECTED_LE_AUDIO_MEDIA_WITH_CONTROL w ciągu 5 sekund.
    • Po uruchomieniu lub zatrzymaniu stan połączenia może na chwilę zmienić się na CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL.

  • Gra

    • Wybranie tego trybu powoduje odtwarzanie dźwięku, nad którym użytkownik nie ma bezpośredniej kontroli. Typ wykorzystania dźwięku: USAGE_GAME.
    • Stan połączenia dostawcy powinien się zmienić na CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL w ciągu 5 sekund.

  • Przyciski Odtwórz i Zatrzymaj

    • Przyciski PLAY i STOP uruchamiają lub zatrzymują dźwięk.

  • Wynik przełączenia

    • To pole wyświetla aktywne opóźnienie usługi Connect and Switch. Wyświetla też przyczynę odrzucenia przełączenia, jeśli zostało wyzwolone zdarzenie audio, ale przełączenie nie nastąpiło.
    • Opóźnienie jest mierzone w milisekundach (ms).
    • Ogólnie opóźnienie jest mierzone od początku działania przełącznika dźwięku do otrzymania powiadomienia o połączeniu profilu BT lub o przełączeniu wielopunktowym.
    • Przełączenia wywoływane przez dostawcę mierzą opóźnienie od momentu rozpoczęcia dźwięku.

Czas oczekiwania na zrzut

  • Poniższe polecenie umożliwia użytkownikowi rejestrowanie pomiarów opóźnień podczas wykonywania testów ręcznych:adb shell dumpsys activity service com.google.android.gms/.nearby.discovery.service.DiscoveryService
    • Pomiary opóźnienia są widoczne w sekcji NearbyDeviceManagerSwitchHistory:
            NearbyDeviceManager
              Nearby Sass device count: 1
                Sass device - address:XX:XX:XX:XX:XX:XX, name:Googler's Pixel Buds, accountKey:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, modelId:6edaf7
                  SwitchHistory
                    15:30:21:166 - 15:30:25:201, latency 3035ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
                    15:34:58:568 - 15:34:58:568, latency 0ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, HFP
                    15:36:26:615 - 15:36:31:603, latency 1988ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
                    15:37:56:108 - 15:37:56:250, latency 142ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, A2DP"
  • Każde przełączanie, którego GmsCore nie może zmierzyć (np. aktywne przełączanie w przypadku HFP), zostanie zarejestrowane jako opóźnienie 0 ms.

Informacje o wzorach logów:

Przykłady logów z testu opóźnienia

Znane problemy:

Oto znane błędy związane z Seekerem:

  1. Nieprawidłowe przełączanie dźwięku w grze.
    • Podczas grania na telefonach Samsung stan połączenia będzie ustawiony na CONNECTED_A2DP_WITH_AVRCP, a nie CONNECTED_A2DP_ONLY.
    • Niektóre gry (np. Candy Crush) mogą odtwarzać muzykę w tle i wywoływać nowe zdarzenie audio bez udziału użytkownika. Połączone telefony mogą ciągle przełączać dźwięk na każdym telefonie, na którym otwierana jest gra.