Ta strona dotyczy wersji aplikacji Validator z obsługą Audio LE. Aby uzyskać pomoc dotyczącą wersji aplikacji Validator z obsługą Audio Switch, odwiedź stronę aplikacji Validator z obsługą Audio Switch.
Konfiguracja
Aby włączyć testowanie w aplikacji Walidator:
- Upewnij się, że na urządzeniu jest zainstalowana aplikacja GmsCore w wersji 23.37.xx lub nowszej.
- Upewnij się, że Twoje e-maile testowe są częścią grupy testowej partnerów Fast Pair.
- Synchronizacja uprawnień na nowo zarejestrowanych adresów e-mail i telefonów może potrwać od 6 do 24 godzin.
- Logowanie się na powiązanym koncie Google i wylogowywanie z niego może też spowodować natychmiastową synchronizację.
Wymagane urządzenia
Do testowania potrzebne są co najmniej 2 telefony:
- 1 urządzenie z Androidem 15 (U) z obsługą LE Audio (np.Pixel 7).
- Jedno z Androidem 6–13 (M–T), który nie obsługuje LE Audio.
- Urządzenia korzystające tylko z transmisji danych muszą używać tylko jednego z tych telefonów.
Łączenie z profilem LE Audio w Androidzie 15 (V)
Technologia LE Audio nie jest domyślnie włączona w Androidzie 15 (V). Aby go włączyć:
- Otwórz na telefonie stronę „Opcje programisty”.
- Aby włączyć opcje programisty:
- Wybierz Ustawienia > System > Informacje o telefonie > Numer kompilacji.
- 7 razy kliknij „Numer kompilacji”.
- Wyłącz opcję „Disable Bluetooth LE Audio” (Wyłącz Bluetooth LE Audio).
- Włącz opcję „Omijaj listę dozwolonych urządzeń Bluetooth LE Audio”.
- Uruchom ponownie telefon.
Włączanie testów BLE na urządzeniach tylko do przesyłania danych
Aplikacja Validator wyświetli menu testu tylko z danymi, jeśli w konsoli urządzenia wybrano „Połączenie tylko z danymi” (uwaga: ta opcja nie jest dostępna w przypadku wszystkich typów urządzeń). Menu testowe w tym trybie wygląda tak:
Włączanie specyfikacji BLE i testów BT Classic na urządzeniach bez obsługi LE Audio
Aby zobaczyć testy BLE, testerzy muszą przełączyć przełącznik „Enable LE spect test” (Włącz test spectografii LE). Aby wyświetlić testy BT Classic, tester musi potwierdzić, że testowane urządzenie nie obsługuje LE Audio:
Włączanie specyfikacji BLE i testów audio LE na telefonie Pixel z Androidem 14 (U) lub nowszym
Aby zobaczyć testy BLE, testerzy muszą przełączyć przełącznik „Enable LE spect test” (Włącz test spectografii LE). Następnie testerzy muszą zaakceptować pozostałe prompty, aby wyświetlić ekran testu. Aplikacja automatycznie wypełni dostępne testy dla tej konfiguracji, w tym testy LE Audio, jak pokazano poniżej:
Włączanie specyfikacji BLE i testów audio LE na telefonie Pixel z Androidem 13 (T) lub starszym
Aby zobaczyć testy BLE, testerzy muszą przełączyć przełącznik „Enable LE spect test” (Włącz test spectografii LE). Następnie testerzy muszą zaakceptować pozostałe prompty, aby wyświetlić ekran testu. Aplikacja automatycznie wypełni dostępne testy dla tej konfiguracji, w tym testy BT klasyczne, np.:
Włączanie specyfikacji BLE i testów LE Audio na telefonie innym niż Pixel z obsługą LE Audio
Aby zobaczyć testy BLE, testerzy muszą przełączyć przełącznik „Enable LE spect test” (Włącz test spectografii LE). Testerzy muszą poinformować aplikację weryfikującą, czy testowany telefon i urządzenie (seeker) obsługują połączenia z LE Audio. Aplikacja nie może poznać tych informacji w przypadku telefonów innych niż Pixel, ponieważ obsługa funkcji jest kontrolowana przez producenta OEM. Wybranie obsługi LE Audio w wyskakującym okienku spowoduje włączenie testów LE Audio, jak pokazano na ilustracji:
Włączanie specyfikacji BLE i testów LE Audio na telefonie innym niż Pixel z obsługą A2DP i HFP
Aby zobaczyć testy BLE, testerzy muszą przełączyć przełącznik „Enable LE spect test” (Włącz test spectografii LE). Testerzy muszą poinformować aplikację weryfikującą, czy testowany telefon i urządzenie (seeker) obsługują połączenia z LE Audio. Aplikacja nie może poznać tych informacji w przypadku telefonów innych niż Pixel, ponieważ obsługa funkcji jest kontrolowana przez producenta urządzeń OEM. Wybranie w wyskakującym okienku obsługi A2DP + HFP spowoduje włączenie testów BT Classic, jak pokazano na rysunku:
Testy obowiązkowe
W sekcji Testy obowiązkowe znajdziesz informacje o tym, które testy są wymagane w przypadku danej wersji Szybkiego parowania i danego typu urządzenia. Pamiętaj, że tabela zawiera osobne karty dla urządzeń tylko z danymi, telefonów z Androidem 13 lub starszym oraz telefonów z Androidem 14 lub nowszym.
Weryfikacja identyfikatora UUID wspólnej usługi audio
Ten test sprawdza, czy urządzenie z możliwością nawiązywania połączeń LE zawiera identyfikator UUID CAS zgodnie z wymaganiami profilu adaptera Bluetooth (BAP 1.0.1) i wspólnego profilu audio.
Test, który się udał, będzie wyglądał tak:
Weryfikacja adresu w Google Ads
Ten test sprawdza, czy dostawca używa prawidłowego typu adresu (dane usługi Fast Pair (0xFE2C)) podczas reklamowania podczas początkowego parowania (adres tożsamości) i kolejnych prób parowania (RPA).
- Urządzenia, które obsługują CTKD z Classic do LE, powinny reklamować RPA podczas początkowego parowania.
- Wszystkie inne urządzenia obsługujące CTKD z LE do Classic powinny podawać swój adres tożsamości podczas początkowego parowania.
- Wszystkie urządzenia, niezależnie od obsługi CTKD, powinny reklamować swoje RPA podczas kolejnego parowania.
Test, który się udał, będzie wyglądał tak:
Testowanie zmian w trybie specyfikacji BLE
Po włączeniu przełącznika „Enable LE spec tests” (Włącz testy specyfikacji LE) niektóre testy ulegną zmianie. Na przykład testy „Battery Level Update” zmienią się na „Battery Level Update with LE audio connection” i „Battery Level Update with classic profile connection”. Zmodyfikowane testy będą się pojawiać tylko w odpowiednich wersjach Androida.
Każdy test, który wprowadza takie zmiany, musi zostać przetestowany na 2 telefonach, aby zapewnić prawidłowe działanie. Jeden telefon powinien być bez LE Audio, a drugi z LE Audio. W przypadku telefonów Pixel oznacza to przetestowanie na telefonie z Androidem 14 (U) lub nowszym oraz na telefonie z Androidem 13 (T) lub starszym. W przypadku telefonów innych niż Pixel oznacza to przetestowanie telefonu z wdrożonym LE Audio i telefonu z tylko A2D + HFP.
Przykład zmiany:
Jak przesłać wyniki do Konsoli urządzeń
Jak przesłać wyniki
Przycisk „PRZEŚLIJ WYNIK” wyświetli podsumowanie wyników testu, ale nie prześle ich do Google.
Po sprawdzeniu wszystkich wyników kliknij przycisk „Prześlij” u dołu strony wyników, aby przesłać wyniki do Google.
Wyświetlanie przesłanych wyników w Konsoli urządzeń
Zgłoszone wyniki testu znajdziesz w Konsoli funkcji W pobliżu. (dane dotyczące odległości i czasu trwania zostaną usunięte w przypadku testów przełącznika dźwięku). Na przykład:
Rozwiązywanie problemów
Jeśli wszystkie testy się nie powiodły, spróbuj wyłączyć i ponownie włączyć Bluetooth.
Nie otrzymano odpowiedzi KeyBasedPairingResponse
Jeśli parowanie się powiedzie, ale komunikat o błędzie nadal się wyświetla, przyczyną jest prawdopodobnie stara wersja rdzenia GMS. Sprawdź, czy telefon został skonfigurowany zgodnie z opisem w sekcji konfiguracji.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Nieprawidłowy typ odpowiedzi w parowaniu na podstawie klucza
Może to być spowodowane wysłaniem przez dostawcę wiadomości o nieprawidłowym typie. Urządzenie szukające z obsługą LE Audio powinno otrzymać wiadomość typu 2, a w pozostałych przypadkach wiadomość typu 1.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
KeyBasedPairingExtensionResponse Wrong Address Length
Może to być spowodowane wybraniem nieprawidłowego typu obsługi CSIP dla urządzenia LE Audio. Urządzenia obsługujące CSIP i LE Audio powinny mieć adres o długości 2, a w pozostałych przypadkach o długości 1.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Błąd stanu
Zwykle jest to spowodowane niemożnością nawiązania połączenia przez dostawcę (urządzenie). W przypadku urządzeń CSIP muszą wystąpić 2 zdarzenia połączenia.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Odbieranie tylko zdarzenia połączenia z 1 adresu
Dzieje się tak, gdy Seeker otrzyma tylko 1 adres od urządzenia CSIP. Urządzenia z obsługą CSIP powinny zawsze podawać 2 adresy.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Nieotrzymanie identyfikatora UUID
Użytkownik nie otrzymał żadnego identyfikatora UUID.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Nieotrzymano oczekiwanego identyfikatora UUID
W zależności od scenariusza usługa Seeker oczekuje określonego typu identyfikatora UUID. W tabeli poniżej określono, jaką wartość UUID należy podać w każdym z tych przypadków.
| Dostawca obsługuje dźwięk w formacie MP3. | Usługodawca nie obsługuje LE Audio | Dostawca jest urządzeniem tylko do przesyłania danych. | |
|---|---|---|---|
| Wyszukiwarka nie obsługuje BLE | 110B, 1108 lub 111E | 110B, 1108 lub 111E | Nie dotyczy |
| Urządzenie szukające obsługuje BLE | 110B, 1108 lub 111E | 110B, 1108 lub 111E | 1812 |
| Urządzenie szukające obsługuje BLE i LEA | 184E | 110B, 1108 lub 111E | 1812 |
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
Odbieranie tylko prawidłowego identyfikatora UUID z 1 adresu
Dzieje się tak, gdy Seeker otrzyma tylko 1 adres od urządzenia CSIP. Urządzenia obsługujące CSIP powinny zawsze podawać 2 adresy.
Na poniższych zrzutach ekranu widać, jak ten błąd może się objawiać w różnych testach.
