Urządzenie Bluetooth Low Energy (BLE)

Implementacja usługi Szybkie parowanie Google (GFPS) dla urządzeń BLE jest zgodna ze specyfikacją Bluetooth Core w wersji 4.2 lub nowszej.

Ten dodatek do specyfikacji Szybkiego parowania umożliwi obsługę w GFPS urządzeń korzystających tylko z protokołu Low Energy (LE) i urządzeń Low Energy Audio (LEA).

Poziomy zgodności

Słowa kluczowe „shall”, „must”, „will”, „should”, „may” i „can” wymienione w specyfikacji są wyjaśnione poniżej:

Okres obowiązywania Opis
shall is required to – służy do określania wymagań.
musi służy do wyrażania:
naturalnej konsekwencji wcześniej podanego wymogu
LUB
niepodważalnego stwierdzenia faktu (które jest zawsze prawdziwe niezależnie od okoliczności).
będzie it is true that – używane tylko w przypadku stwierdzeń faktów.
powinny zaleca się – używane do wskazania, że spośród kilku możliwości jedna jest zalecana jako szczególnie odpowiednia, ale nie jest wymagana.
może ma pozwolenie na – używane do zezwalania na opcje.
możemy może – używane do powiązania stwierdzenia w sposób przyczynowy.

Key-based Pairing Characteristic

Wiadomość od osoby poszukującej do dostawcy

Surowe żądanie type 0x00 w charakterystyce parowania opartego na kluczu używa bitu 4 do wskazania, czy urządzenie wyszukujące obsługuje specyfikację urządzenia BLE, a bitu 5 do wskazania, czy urządzenie wyszukujące obsługuje LE Audio.

Oktet Typ danych Opis Wartość Obowiązkowe?
0 uint8 Typ komunikatu 0x00 = Prośba o sparowanie na podstawie klucza Obowiązkowe
1 uint8 Flagi
  • Bit 0 (MSB): wycofany i ignorowany przez Seeker.
  • Bit 1: 1, jeśli urządzenie wysyłające żąda, aby urządzenie odbierające zainicjowało parowanie, a to żądanie zawiera adres BR/EDR urządzenia wysyłającego. W przeciwnym razie zwraca 0.
  • Bit 2: 1, jeśli osoba wysyłająca prośbę żąda, aby dostawca powiadomił o istniejącej nazwie. W przeciwnym razie zwraca 0.
  • Bit 3: 1, jeśli dotyczy to wstecznego zapisu klucza konta. W przeciwnym razie zwraca 0.
  • Bit 4: 1, jeśli lokalizator obsługuje specyfikację urządzenia BLE. W przeciwnym razie zwraca 0.
  • Bit 5: 1, jeśli urządzenie wyszukujące obsługuje LE Audio. W przeciwnym razie zwraca 0.
  • Bity 6–7 są zarezerwowane do użycia w przyszłości i należy je ignorować.
 różni się Obowiązkowe
2 - 7 uint48 Możesz:
  • Obecny adres BLE dostawcy
  • Adres tożsamości dostawcy
 różni się Obowiązkowe
8–13 uint48 Adres BR/EDR urządzenia wyszukującego różni się Występuje tylko wtedy, gdy ustawiony jest bit 1 lub 3 flagi.
n - 15 Wartość losowa (sól) różni się Obowiązkowe

Wiadomość od usługodawcy do klienta

Gdy bit 4 żądania jest ustawiony, nowy komunikat odpowiedzi type 0x02 dla charakterystyki parowania opartego na kluczu może być używany do udostępniania dodatkowych opcji łączenia urządzeniu wyszukującemu.

Oktet Typ danych Opis Wartość
0 uint8 Typ komunikatu 0x02 = Rozszerzona odpowiedź na parowanie oparte na kluczu
1 uint8 Flagi
  • Bit 0 (MSB): 1, jeśli dostawca jest urządzeniem tylko LE, 0 w innych przypadkach. Jeśli bit 0 ma wartość 1, wyszukiwarka założy, że bit 1 ma wartość 1.
  • Bit 1: 1, jeśli dostawca preferuje łączenie LE, w przeciwnym razie 0.
  • Bit 2: 1, jeśli typ drugiego adresu to Losowy, 0, jeśli Publiczny.
  • Bity 3–7 są zarezerwowane do użycia w przyszłości i należy je ignorować.
 różni się
2 uint8 Liczba adresów dostawcy
(w bieżącej wersji liczba ta wynosi 1 lub 2, ponieważ jeśli liczba jest większa lub równa 3, musimy zmienić tryb szyfrowania blokowego na AES-CTR)		 różni się
3–8 lub
3–14
  • Pierwszy adres powinien być adresem tożsamości urządzenia głównego i umożliwiać parowanie, jeśli preferowane jest parowanie BR/EDR.
  • Drugi adres powinien być adresem, który można powiązać z urządzeniem dodatkowym, jeśli jest ono dostępne.
 różni się
9–15 lub 15 Wartość losowa (sól) różni się

Dostawca, który obsługuje specyfikację urządzenia BLE, powinien odczytać bity 4 i 5, aby poznać możliwości osoby szukającej.

  • Gdy bit 4 ma wartość 0, dostawca ignoruje bit 5 i odpowiada w formacie type 0x01.
  • Gdy bit 4 ma wartość 1,
    • W przypadku dostawcy obsługującego tylko LE powinien on odpowiedzieć symbolem type 0x02, aby wskazać preferencje dotyczące łączenia LE.
    • W przypadku dostawcy w trybie podwójnym może on odpowiedzieć wartością type 0x02, aby wskazać preferencje dotyczące łączenia BR/EDR lub LE.
  • W przypadku urządzeń LE Audio (LEA) w trybie podwójnym zobacz Przykład: parowanie z urządzeniem LEA w trybie podwójnym.

Charakterystyka PSM (Protocol Service Multiplexor) strumienia wiadomości

Aby obsługiwać strumień wiadomości na urządzeniach BLE, szybkie parowanie będzie tworzyć i utrzymywać kanał BLE L2CAP do wysyłania i odbierania wiadomości. Szybkie parowanie Serwer L2CAP musi implementować sterowanie przepływem oparte na kredytach LE.

Ta cecha umożliwia urządzeniu wyszukującemu odczytanie wartości PSM, a następnie nawiązanie bezpiecznego połączenia L2CAP na podstawie tej wartości.

Charakterystyka usługi szybkiego parowania Zaszyfrowane Uprawnienia UUID
PSM strumienia wiadomości Tak Odczyt FE2C1239-8366-4814-8EB0-01DE32100BEA
Oktet Typ danych Opis Wartość
0 uint8 Stan
  • 0x00 = Nieznany. FP Seeker podejmie kilka prób
  • 0x01 = Gotowe do połączenia
  • 0x02 = Niedostępne. FP Seeker nie użyje tym razem tego komponentu do połączenia.
 różni się
1–2 uint16 Wartość PSM musi mieścić się w zakresie od 0x80 do 0xFF. różni się

Uwaga: w przypadku TWS są 2 komponenty: podstawowy i dodatkowy. W określonych warunkach role tych komponentów są wymienne. Załóżmy, że A jest komponentem głównym , a B – komponentem pomocniczym. Z powodu wyczerpania baterii w komponencie A komponent B musi przejąć rolę komponentu głównego. Ten scenariusz nazywa się role switch.

Po role switch, jeśli dostawca nie może obsłużyć strumienia wiadomości Szybkiego parowania, powinien aktywnie rozłączyć istniejące połączenie L2CAP. Wyszukiwarka Szybkiego parowania może następnie ponownie nawiązać połączenie strumienia wiadomości L2CAP z nowym komponentem podstawowym.

Dodatkowa cecha klucza dostępu

Ma to na celu zapewnienie ochrony przed atakami typu MITM w przypadku dodatkowych komponentów.

Ochrona przed atakami typu MITM w przypadku fałszywych użytkowników CSIS

Szybkie parowanie wymaga ochrony przed atakami typu MITM w ramach procedury parowania. CSIS nie zapewnia ochrony przed atakami typu „man-in-the-middle”, więc obecna konstrukcja FP dla wielu komponentów musi zostać rozszerzona, aby zapewnić ochronę przed takimi atakami w przypadku dodatkowych komponentów.

Definicja cechy

Charakterystyka usługi szybkiego parowania Zaszyfrowane Uprawnienie UUID
Dodatkowy klucz dostępu Tak Odczyt,zapis,powiadomienie FE2C123A-8366-4814-8EB0-01DE32100BEA

Wiadomości

Format wiadomości jest stosowany do operacji odczytu, zapisu i powiadamiania.

Format zaszyfrowanych danych

Zaszyfrowane dane są przesyłane za pomocą połączenia GATT Szybkiego parowania.

Oktet Typ danych Opis Wartość
0-15 uint128 Zaszyfrowany dodatkowy blok kluczy dostępu różni się
Format nieprzetworzonych danych

Po odszyfrowaniu zaszyfrowanych danych za pomocą udostępnionego hasła format jest następujący:

Oktet Typ danych Opis Wartość
0 uint8 Typ komunikatu jeden z 
  • 0x00 = Klucz dostępu osoby szukającej
  • 0x01 = Klucz dostępu dostawcy
1-3 uint24 6-cyfrowy klucz dostępu różni się
4-9 uint48 Docelowy adres komponentu wiążącego różni się
10 uint8 Kod stanu, używany tylko w przypadku operacji odczytu. Jedna z tych możliwości:
  • 0x00 = Success
  • 0x01 = Oczekuje. Ponawianie próby wyszukiwania odcisków palców do momentu przekroczenia limitu czasu
  • 0x02 = Niepowodzenie. FP Seeker stop retry
11-15 Wartość losowa (sól) różni się

Główny (pierwszy sparowany komponent) jest pomostem między wyszukiwarką Szybkiego parowania a dodatkowymi komponentami parowania. Charakterystyka powinna być zgodna z tymi wytycznymi:

  • Gdy dostawca otrzyma żądanie zapisu od urządzenia wyszukującego Szybkie parowanie, musi:
    • Ustaw adres komponentu, który jest łączony
    • Wysyłanie klucza dostępu do komponentu, z którym nawiązywane jest połączenie
    • Ustaw kod stanu na Oczekujące, 0x01
  • Gdy przed otrzymaniem klucza dostępu od komponentu, z którym nawiązywane jest połączenie, dostawca otrzyma jakiekolwiek żądanie odczytu, powinien zwrócić komunikat z kodem
    • Klucz dostępu, dowolna wartość
    • Adres komponentu, który ma zostać połączony
    • Kod stanu oczekiwania, 0x01
  • Zanim dostawca wyśle powiadomienie do urządzenia wyszukującego Szybkie parowanie, ustawia wynik żądania odczytu za pomocą
    • Klucz dostępu z komponentu, który jest parowany
    • Adres komponentu, który ma zostać połączony
    • Kod stanu powodzenia, 0x00
  • Jeśli po stronie dostawcy wystąpi nieodwracalny błąd, ustaw wynik
    • Klucz dostępu, dowolna wartość
    • Adres komponentu, który ma zostać połączony
    • Kod stanu błędu, 0x02

Więcej informacji znajdziesz na diagramie MITM 1 i diagramie MITM 2.

Wymagania dotyczące urządzeń LE

LE Advertising

W przypadku trybu wykrywalnego lub niewykrywalnego dostawca będzie używać RPA do reklamowania danych Fast Pair.

Możliwość łączenia

W przypadku urządzeń obsługujących LE urządzenie wyszukujące musi utworzyć powiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania opartego na kluczu Szybkiego parowania dostawca zezwala na powiązanie z RPA i ustawia możliwość wejścia/wyjścia na DisplayYesNo w przypadku weryfikacji kodu dostępu Szybkiego parowania.

Wymagania dotyczące urządzeń organów ścigania

LEA Advertising

W przypadku urządzeń dwutrybowych: w trybie wykrywania dostawca będzie reklamować dane Szybkiego parowania z adresem tożsamości. W przypadku trybu niewykrywalnego dostawca będzie reklamować dane Szybkiego parowania za pomocą RPA. Zdecydowanie zalecamy używanie starszych reklam (BT 4.2), aby zapewnić zgodność wsteczną ze starszymi urządzeniami. Klucz IRK należy zmienić za każdym razem, gdy urządzenie zostanie przywrócone do ustawień fabrycznych.

W przypadku urządzeń niedziałających w trybie podwójnym: W trybie wykrywalnym lub niewykrywalnym dostawca musi używać rozszerzonego reklamowania (BT 5.0) z RPA do reklamowania danych Fast Pair.

Reklama z możliwością połączenia LE zawierająca dane usługi FP musi zawierać identyfikator UUID CAS zgodnie z wymaganiami profilu adaptera Bluetooth (BAP 1.0.1) i profilu Common Audio.

Dostawca może wskazać możliwość LEA, umieszczając identyfikator UUID CAS (0x1853) w danych usługi (typ AD 0x16) lub w 16-bitowych identyfikatorach UUID klasy usługi (typ AD 0x02 lub 0x03), niezależnie od trybu wykrywania.

W przypadku niewykrywalnych reklam, jeśli w starszych reklamach nie ma wystarczająco dużo miejsca z powodu uwzględnienia danych o baterii i SASS, w odpowiedzi na skanowanie musi być uwzględniony identyfikator UUID CAS.

Możliwość łączenia LEA

Wyszukiwacz musi utworzyć powiązanie z istniejącym połączeniem LE. Po przejściu weryfikacji parowania opartego na kluczu Szybkiego parowania dostawca w trybie podwójnym zezwala na powiązanie z adresem tożsamości i adresem RPA, a dostawca w trybie innym niż podwójny zezwala na powiązanie z adresem RPA i ustawia możliwość wejścia/wyjścia na DisplayYesNo w przypadku weryfikacji kodu dostępu Szybkiego parowania.

Wewnętrzny kanał komunikacji między komponentami

Istniejące połączenie GATT jest utrzymywane w celu zapewnienia ochrony przed atakami typu „man-in-the-middle” w przypadku dodatkowych komponentów. Główny sparowany komponent będzie obsługiwać dostarczanie wiadomości między urządzeniem wyszukującym Szybkie parowanie a pozostałymi komponentami.

Komunikacja wewnętrzna jest wykorzystywana w przypadku Initial Pair i Subsequent Pair.

  • Gdy procedura parowania na podstawie klucza zakończy się na komponencie głównym, komponent główny wyśle wiadomość, aby zmienić możliwości wejścia/wyjścia pozostałych komponentów.
  • Po zakończeniu procesu Szybkiego parowania główny komponent wysyła wiadomość, aby zresetować możliwości wejścia/wyjścia pozostałych komponentów.
  • Podczas wykonywania procedury dodatkowego klucza dostępu główny komponent powinien obsługiwać dostarczanie kluczy dostępu między wyszukującym Szybkiego parowania a pozostałymi komponentami.

Czas zmiany możliwości zamówienia reklamowego

  • Zmiana możliwości wejścia/wyjścia na DisplayYesNo po zakończeniu procedury parowania opartego na kluczu
    • Jeśli urządzenie ma wiele komponentów, wszystkie muszą mieć wartość DisplayYesNo
    • Wyjątkiem, w przypadku którego Dostawca nie może zmienić możliwości IO na DisplayYesNo, jest Retroactive Pair, którego bit 3 żądania parowania opartego na kluczu ma wartość 1. Więcej informacji znajdziesz w sekcji Wiadomość od Wyszukiwarki do Dostawcy.
  • Przywracanie domyślnych ustawień funkcji wejścia/wyjścia
    • Początkowe parowanie
      • Jeśli połączenie LE zostanie przerwane, zakończ sesję Szybkiego parowania.
      • Jeśli po sparowaniu urządzenia głównego w ciągu 15 sekund nie pojawi się dodatkowa prośba o zapisanie klucza dostępu, sesja szybkiego parowania zostanie zakończona.
      • Jeśli po otrzymaniu dodatkowej prośby o zapisanie klucza dostępu komponent, który ma zostać sparowany, nie zostanie sparowany w ciągu 15 sekund, zakończ sesję Szybkiego parowania.
      • Jeśli po połączeniu wszystkich komponentów w ciągu 15 sekund nie pojawi się żądanie zapisu klucza konta, zakończ sesję szybkiego parowania.
      • Po otrzymaniu żądania zapisu klucza konta ustaw limit czasu na 15 sekund, aby zakończyć sesję szybkiego parowania.
    • Kolejne parowanie
      • Jeśli połączenie LE zostanie przerwane, zakończ sesję Szybkiego parowania.
      • Jeśli po powiązaniu urządzenia głównego w ciągu 15 sekund nie pojawi się dodatkowa prośba o zapisanie klucza dostępu, sesja szybkiego parowania zostanie zakończona.
      • Jeśli po otrzymaniu dodatkowej prośby o zapisanie klucza dostępu komponent, który ma zostać sparowany, nie zostanie sparowany w ciągu 15 sekund, zakończ sesję Szybkiego parowania.
      • Po połączeniu wszystkich komponentów zakończ sesję Szybkiego parowania.

Ukryj wskazanie interfejsu

Gdy słuchawki nie są gotowe do sparowania, dostawca powinien użyć type 0b0010, aby ustawić ukrywanie wskaźnika interfejsu danych klucza konta i poinformować urządzenie wyszukujące, aby nie wyświetlało kolejnego interfejsu parowania (patrz Ładunek reklamowy: dane konta Fast Pair).

Wymagania dotyczące urządzeń LE Audio

Wymagania dotyczące Bluetootha

Zobacz rekomendacje dotyczące słuchawek z Androidem i LE Audio.

Obsługa CTKD

W przypadku urządzenia dwutrybowego wymagane jest CTKD z LE do BR/EDR, które musi być zgodne z wymaganiami BAP.

Ogłoszenie o celu

Urządzenie peryferyjne powinno używać ukierunkowanego ogłoszenia, aby nawiązać połączenie z sparowanym urządzeniem centralnym. Komunikaty kierowane są zdefiniowane w specyfikacjach BAP i CAP na potrzeby zarządzania połączeniami zgodnie z tabelą 8.4 (s. 48/58) w CAP 1.0.

Obsługa serwera GATT EATT

EATT umożliwia urządzeniu centralnemu wysyłanie równolegle wielu transakcji GATT, gdy urządzenie jest sparowane. W przypadku urządzenia obsługującego CSIP zwiększy się wydajność połączenia profilu, a następnie wkrótce rozpocznie się procedura łączenia CSIP z innymi słuchawkami.

Jeśli dostawca nie jest pojedynczym urządzeniem, ale skoordynowanym zestawem z implementacją CSIP, aby zmniejszyć liczbę wyszukiwań usług i przyspieszyć połączenie, powinien zaimplementować buforowanie GATT zdefiniowane w Bluetooth 5.1.

Wymagania dotyczące Szybkiego parowania

LE Advertising

W przypadku trybu wykrywalnego lub niewykrywalnego, jeśli urządzenie ma wiele komponentów, dane Szybkiego parowania są reklamowane przez komponent główny. Jeśli urządzenie nie jest gotowe do kolejnego parowania, komponent dodatkowy może reklamować dane Szybkiego parowania w przypadku funkcji rozszerzonych. Zobacz Ukrywanie wskazania interfejsu.

Widoczność usługi GATT

Baza danych GATT musi być taka sama dla wszystkich połączeń GATT w transporcie LE. Usługa LE Audio (0x184E) musi być uwzględniona w bazie danych GATT połączenia Szybkiego parowania.

Przykład: parowanie z dostawcą LEA w trybie podwójnym

Scenariusz 1. Wyszukiwarka nie obsługuje LEA

Dostawca musi zapewnić zgodność wsteczną z Wyszukującym, który nie obsługuje LEA.

Komponenty
  • Dostawca: A2DP/HFP/LEA
  • Urządzenie wyszukujące: A2DP/HFP
Oczekiwane zachowanie podczas pierwszego i kolejnego parowania
  • Dostawca reklamuje dane usługi Fast Pair (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
    • Korzystanie z reklam starszego typu
  • Odbiorca otrzymuje reklamę dostawcy z adresem tożsamości na potrzeby wstępnego parowania lub RPA na potrzeby kolejnego parowania.
  • Urządzenie wysyła żądanie parowania opartego na kluczu.
    • Bit flagi 5 w żądaniu parowania opartego na kluczu jest ustawiony na 0.
  • Dostawca wysyła odpowiedź na parowanie oparte na kluczu z adresem publicznym w jednym z tych formatów:
    • Jeśli używany jest typ wiadomości 0x01, adres musi być adresem publicznym.
    • Jeśli używany jest typ wiadomości 0x02
      • Bit 0 musi mieć wartość 0
      • Bit 1 musi mieć wartość 0
      • Adres musi być adresem publicznym.
  • Urządzenie wyszukujące tworzy połączenie z transportem BR/EDR.
    • Możliwość wejścia/wyjścia jest ustawiona na DisplayYesNo w przypadku BR/EDR
  • Urządzenie wyszukujące i urządzenie udostępniające przeprowadzają procedurę weryfikacji klucza dostępu Szybkiego parowania.

Scenariusz 2. Wyszukiwarka obsługuje LEA

Komponenty
  • Dostawca
    • Obsługa A2DP/HFP/LEA
    • Pojedynczy komponent
  • Seeker
    • SupportA2DP/HFP/LEA
Oczekiwane zachowanie podczas pierwszego i kolejnego parowania
  • Dostawca reklamuje dane usługi Fast Pair (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
    • Korzystanie z reklam starszego typu
  • Urządzenie wysyła żądanie parowania opartego na kluczu.
    • Bit flagi 5 w żądaniu parowania opartego na kluczu jest ustawiony na 1.
  • Dostawca wysyła odpowiedź na parowanie oparte na kluczu z typem wiadomości 0x02
    • Bit 0 musi mieć wartość 0
    • Bit 1 musi mieć wartość 1
    • Adres to Adres tożsamości
  • Urządzenie Seeker tworzy powiązanie z istniejącym połączeniem LE w ramach transportu LE.
    • Kierunek CTKD to LE do BR/EDR
    • W przypadku LE funkcja IO jest ustawiona na DisplayYesNo.
  • Urządzenie wyszukujące i urządzenie udostępniające przeprowadzają procedurę weryfikacji klucza dostępu Szybkiego parowania.

Scenariusz 3 – gdy osoba poszukująca pomocy obsługuje LEA i CSIP

Komponenty
  • Dostawca
    • Obsługa A2DP/HFP/LEA
    • Wiele komponentów
      • Główny komponent to BR/EDR/LE
      • Komponent dodatkowy jest dostępny tylko w przypadku LE
  • Seeker
    • Obsługa A2DP/HFP/LEA
Oczekiwane zachowanie podczas pierwszego i kolejnego parowania
  • Główny komponent rozgłasza dane usługi Szybkie parowanie (0xFE2C) z adresem tożsamości (początkowym) lub RPA (kolejnym).
    • Korzystanie z reklam starszego typu
  • Urządzenie wysyła do głównego komponentu prośbę o sparowanie na podstawie klucza.
    • Bit flagi 5 w żądaniu parowania opartego na kluczu jest ustawiony na 1.
  • Główny komponent wysyła odpowiedź na parowanie oparte na kluczu z typem wiadomości 0x02
    • Bit 0 musi mieć wartość 0
    • Bit 1 musi mieć wartość 1
    • Adresy są podane poniżej:
      • Pierwszy adres to adres tożsamości głównego komponentu.
      • Drugi adres to adres, z którym można się połączyć w przypadku komponentu dodatkowego. Komponent dodatkowy używa tego adresu również do reklamowania CSIP.
  • Urządzenie wyszukujące tworzy połączenie z głównym komponentem na istniejącym połączeniu LE.
    • Kierunek CTKD to LE do BR/EDR
    • W przypadku LE funkcja IO jest ustawiona na DisplayYesNo.
  • Wyszukiwarka tworzy połączenie z komponentem dodatkowym, którego adres pochodzi z rozszerzonej odpowiedzi na parowanie oparte na kluczu.
    • Możliwość wejścia/wyjścia musi mieć wartość DisplayYesNo. W przeciwnym razie odrzuć prośbę o sparowanie.
  • Urządzenie wyszukujące i urządzenie udostępniające przeprowadzają procedurę ochrony przed atakami typu MITM w celu sparowania komponentu dodatkowego. Urządzenie udostępniające musi zaimplementować oba scenariusze.
  • Urządzenie wyszukujące czeka na połączenie z komponentem dodatkowym

Schemat sekwencyjny ataku MITM

W tej sesji opisujemy sekwencję procedury ochrony przed atakami typu MITM.

Pobieranie klucza dostępu z komponentu, który jest parowany, za pomocą powiadomienia

Pobieranie klucza dostępu z komponentu, który jest powiązany przez odczyt

Znany problem

FP dla organów ścigania został zoptymalizowany pod kątem Androida V(Androida 15).

Z kolei napotkaliśmy wiele problemów ze słuchawkami, które obsługują LEA, ale nie mają prawidłowej implementacji Szybkiego parowania przez LEA (czyli tylko Szybkie parowanie przez Classic). Na przykład gdy identyfikator RPA dostawcy nie jest generowany przez prawidłowy klucz IRK i nie można rozpoznać adresu. Nie udało nam się przetestować wszystkich konfiguracji słuchawek, ale nasze ograniczone testy wykazały różne problemy, w tym brak wyświetlania powiadomień o baterii słuchawek, brak funkcji przełączania dźwięku (SASS), powszechne problemy z początkowym i kolejnym parowaniem oraz inne.

Z tego powodu zdecydowanie zalecamy partnerom wdrożenie specyfikacji Szybkie parowanie – LEA zarówno w przypadku nowych urządzeń, jak i urządzeń już dostępnych na rynku (za pomocą aktualizacji bezprzewodowych), które obsługują tryb podwójny.