Lokalizacja Wi-Fi: w zakresie z RTT

Możesz użyć funkcji lokalizacji Wi-Fi dostępnej w Interfejs API Wi-Fi RTT (Round-Trip-Time) mierzyć odległość do pobliskich punktów dostępu Wi-Fi i peera, które obsługują RTT; Urządzenia z Wi-Fi Aware.

Jeśli zmierzono odległość do co najmniej 3 punktów dostępu, możesz użyć algorytmu wielobocznego, aby oszacować pozycję urządzenia, która najlepiej pasuje do tych pomiarów. Wynik jest zwykle dokładny do 1–2 metrów.

Taka dokładność pozwala na tworzenie szczegółowych usług wykorzystujących lokalizację, takich jak jako nawigacji wewnątrz budynków, szczegółowe sterowanie głosem (na przykład „Włącz to „światła”) i informacji opartych na lokalizacji (np. „Czy są dostępne danego produktu?”).

Urządzenie wysyłające żądanie nie musi łączyć się z punktami dostępu, aby przeprowadzać pomiary w odległości za pomocą RTT Wi-Fi. Ze względu na ochronę prywatności tylko urządzenie wysyłające żądanie może określić odległość do punktu dostępu. Punkty dostępu nie mają dostępu do tych informacji. W przypadku aplikacji działających na pierwszym planie operacje RTT Wi-Fi są nieograniczone, ale w przypadku aplikacji działających w tle są ograniczone.

RTT Wi-Fi i powiązane funkcje dokładnego pomiaru czasu (FTM) są standardem IEEE 802.11-2016. RTT w Wi-Fi wymaga dokładnej godziny pomiar dostarczony przez FTM, ponieważ oblicza odległość między dwoma urządzeń, mierząc czas potrzebny pakietowi na pokonanie tych urządzeń i mnożąc ten czas przez prędkość światła.

W Androidzie 15 (poziom interfejsu API 35) wprowadzono obsługę technologii IEEE 802.11az niezwiązanych z regułami (NTB).

Różnice we wdrożeniu w zależności od wersji Androida

Wi-Fi RTT zostało wprowadzone w Androidzie 9 (poziom API 28). Jeśli używasz tego protokołu do określania pozycji urządzenia za pomocą wielobocznej lokalizacji na urządzeniach z Androidem 9, musisz mieć w aplikacji dostęp do zdefiniowanych wcześniej danych o lokalizacji punktów dostępu (AP). To od Ciebie zależy, jak te dane będą przechowywane i pobierane.

Na urządzeniach z Androidem 10 (poziom interfejsu API 29) lub nowszym dane o lokalizacji AP mogą być reprezentowane jako obiekty ResponderLocation, które obejmują szerokość geograficzną, długość geograficzną i wysokość. Punkty dostępu RTT obsługujące sieć Wi-Fi, obsługują informacje o konfiguracji lokalizacji i raporty o obliczaniu lokalizacji (dane LCI/LCR), protokół zwróci obiekt ResponderLocation podczas proces określania zakresu.

Ta funkcja pozwala aplikacjom wysyłać zapytania do punktów dostępu, aby bezpośrednio prosić ich o podanie pozycji bez konieczności zapisywania tych informacji z wyprzedzeniem. Dzięki temu aplikacja może znajdować punkty dostępu i określać ich pozycję, nawet jeśli punkty te nie były wcześniej znane, na przykład gdy użytkownik wchodzi do nowego budynku.

Obsługa zakresu IEEE 802.11az NTB jest dostępna na urządzeniach z Androidem 15 (poziom interfejsu API 35) i wyższy. Oznacza to, że jeśli urządzenie obsługuje standard IEEE 802.11az, Tryb inicjatora NTB (oznaczony znakiem WifiRttManager.CHARACTERISTICS_KEY_BOOLEAN_NTB_INITIATOR), aplikacja może znajdować punkty AP z obsługą IEEE 802.11mc i IEEE 802.11az żądania zakresu. Rozszerzyliśmy interfejs API RangingResult, aby dostarczać informacje o minimalnej i maksymalnej wartości, jaka może być używana w przedziale między wybierając zakres pomiarów, pozostawiając dokładny odstęp czasu w aplikacji.

Wymagania

• Sprzęt urządzenia wysyłającego żądanie pomiaru zasięgu musi być zgodny ze standardem FTM 802.11-2016 lub standardem 802.11az (pomiary zasięgu bez wyzwalacza).
• Urządzenie przesyłające żądanie określania zakresu musi mieć Androida 9 (poziom interfejsu API) 28) lub nowsze. Określanie zakresu bez wyzwalacza w standardzie IEEE 802.11az jest włączone na urządzeniach z Androidem 15 (poziom interfejsu API 35) lub nowszym.
• Urządzenie przesyłające żądanie określania zakresu musi mieć włączone usługi lokalizacyjne i włączone skanowanie Wi-Fi (w sekcji Ustawienia > Lokalizacja).
• Jeśli aplikacja wysyłająca żądanie określania zakresu jest kierowana Androida 13 (poziom API 33) lub nowszego, musi mieć NEARBY_WIFI_DEVICES uprawnienia. Jeśli taka aplikacja jest kierowana na starszą wersję Androida, musi mają ACCESS_FINE_LOCATION
• Aplikacja musi wysyłać zapytania do różnych punktów dostępu, gdy jest widoczna lub działa jako usługa na pierwszym planie. Aplikacja nie może uzyskać dostępu do informacji o lokalizacji z .
• Punkt dostępu musi stosować standard IEEE 802.11-2016 FTM lub standard IEEE 802.11az (określanie zasięgu bez użycia wyzwalacza).

Konfiguracja

Aby skonfigurować aplikację do korzystania z RTT Wi-Fi, wykonaj te czynności.

1. Poproś o uprawnienia

W pliku manifestu aplikacji poproś o te uprawnienia:

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
<!-- If your app targets Android 13 (API level 33)
     or higher, you must declare the NEARBY_WIFI_DEVICES permission. -->
<uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"
                 <!-- If your app derives location information from Wi-Fi APIs,
                      don't include the "usesPermissionFlags" attribute. -->
                 android:usesPermissionFlags="neverForLocation" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
                 <!-- If any feature in your app relies on precise location
                      information, don't include the "maxSdkVersion"
                      attribute. -->
                 android:maxSdkVersion="32" />

Uprawnienia NEARBY_WIFI_DEVICES i ACCESS_FINE_LOCATION są niebezpieczne, dlatego musisz prosić o nie w czasie działania za każdym razem, gdy użytkownik chce wykonać operację skanowania RTT. Jeśli użytkownik nie przyznał jeszcze uprawnień, aplikacja będzie musiała o nie poprosić. Więcej informacji o uprawnieniach czasu działania, zobacz Poproś o uprawnienia aplikacji.

Uwaga: jeśli podczas operacji pomiaru odległości zostanie cofnięte niezbędne uprawnienie, operacja zostanie przerwana, a niepowodzenie zostanie zgłoszone.

2. Sprawdź, czy urządzenie obsługuje Wi-Fi RTT

Aby sprawdzić, czy urządzenie obsługuje RTT w sieci Wi-Fi, użyj Interfejs API PackageManager:

Kotlin

context.packageManager.hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)

Java

context.getPackageManager().hasSystemFeature(PackageManager.FEATURE_WIFI_RTT);

3. Sprawdzanie, czy dostępna jest funkcja RTT Wi-Fi

Funkcja RTT Wi-Fi może być dostępna na urządzeniu, ale może być wyłączona, ponieważ użytkownik wyłączył Wi-Fi. W zależności od możliwości sprzętowych i oprogramowania niektóre urządzenia mogą nie obsługiwać Wi-Fi RTT, jeśli są używane w nich funkcje SoftAP lub tetheringu. Aby sprawdzić, czy tryb RTT przez Wi-Fi jest dostępny, zadzwoń pod numer isAvailable().

Dostępność Wi-Fi RTT może się zmienić w dowolnym momencie. Aplikacja powinna zarejestrować BroadcastReceiver aby otrzymać ACTION_WIFI_RTT_STATE_CHANGED, który jest wysyłany w przypadku zmiany dostępności. Gdy aplikacja otrzyma intencję przesyłania strumieniowego, powinna sprawdzić aktualny stan dostępności i odpowiednio dostosować swoje działanie.

Na przykład:

Kotlin

val filter = IntentFilter(WifiRttManager.ACTION_WIFI_RTT_STATE_CHANGED)
val myReceiver = object: BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (wifiRttManager.isAvailable) {
            …
        } else {
            …
        }
    }
}
context.registerReceiver(myReceiver, filter)

Java

IntentFilter filter =
    new IntentFilter(WifiRttManager.ACTION_WIFI_RTT_STATE_CHANGED);
BroadcastReceiver myReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        if (wifiRttManager.isAvailable()) {
            …
        } else {
            …
        }
    }
};
context.registerReceiver(myReceiver, filter);

Uwaga: przed sprawdzeniem dostępności sprawdź, czy odbiornik transmisji jest zarejestrowany. W przeciwnym razie może się zdarzyć, że aplikacja zacznie uznawać, czy RTT Wi-Fi jest dostępne, ale nie jest powiadamiany o zmianie dostępności.

Więcej informacji znajdziesz w artykule Komunikaty.

Tworzenie żądania pomiaru zasięgu

Prośba o określenie zakresu Utworzono (RangingRequest) przez określenie listy punktów dostępu lub elementów równorzędnych z modułem Wi-Fi Aware, do których jest żądane. W elemencie żądanie pojedynczego zakresu; odległość jest mierzona i zwracana dla wszystkich urządzeń.

Na przykład w żądaniu można użyć funkcji addAccessPoint() aby określić punkt dostępu, do którego będzie mierzona odległość:

Kotlin

val req: RangingRequest = RangingRequest.Builder().run {
    addAccessPoint(ap1ScanResult)
    addAccessPoint(ap2ScanResult)
    build()
}

Java

RangingRequest.Builder builder = new RangingRequest.Builder();
builder.addAccessPoint(ap1ScanResult);
builder.addAccessPoint(ap2ScanResult);

RangingRequest req = builder.build();

Punkt dostępu można zidentyfikować po obiekcie ScanResult, który można uzyskać, wywołując funkcję WifiManager.getScanResults(). Za pomocą addAccessPoints(List<ScanResult>) , aby dodać zbiorczo wiele punktów dostępu.

Obiekty ScanResult mogą zawierać punkty dostępowe obsługujące standard IEEE 802.11mc (is80211mcResponder()) i standard IEEE 802.11az (is80211azNtbResponder()) z obsługą pomiaru zasięgu bez wyzwalania. Urządzenia obsługujące IEEE 802.11az NTB mają wydajność 802.11mc lub standardem 802.11az jest zasięg 802.11az, w zależności od jego możliwości. punkt dostępowy obsługuje jedne i drugie. Urządzenia, które nie obsługują IEEE 802.11az, mają wszystkie wykorzystując protokół IEEE 802.11mc.

Podobnie żądanie określania zakresu może dodać równorzędną sieć Wi-Fi Aware za pomocą adresu MAC lub jego PeerHandle, przy użyciu addWifiAwarePeer(MacAddress peer) i addWifiAwarePeer(PeerHandle peer) metod weryfikacji danych. Aby dowiedzieć się więcej o odkrywaniu równorzędnych sieci Wi-Fi Aware, zobacz dokumentację Wi-Fi Aware.

Zakres żądań

Aplikacja wysyła żądanie pomiaru za pomocą metody WifiRttManager.startRanging(), podając: RangingRequest, aby określić operację, Executor, aby określić kontekst wywołania zwrotnego, oraz RangingResultCallback, aby otrzymać wyniki.

Na przykład:

Kotlin

val mgr = context.getSystemService(Context.WIFI_RTT_RANGING_SERVICE) as WifiRttManager
val request: RangingRequest = myRequest
mgr.startRanging(request, executor, object : RangingResultCallback() {

    override fun onRangingResults(results: List<RangingResult>) { … }

    override fun onRangingFailure(code: Int) { … }
})

Java

WifiRttManager mgr =
      (WifiRttManager) Context.getSystemService(Context.WIFI_RTT_RANGING_SERVICE);

RangingRequest request ...;
mgr.startRanging(request, executor, new RangingResultCallback() {

  @Override
  public void onRangingFailure(int code) { … }

  @Override
  public void onRangingResults(List<RangingResult> results) { … }
});

Operacja pomiaru jest wykonywana asynchronicznie, a jej wyniki są zwracane w jednym z tych wywołań zwrotnych:RangingResultCallback.

• Jeśli cała operacja pomiaru odległości zakończy się niepowodzeniem, wywołanie zwrotne onRangingFailure zostanie wywołane z kodem stanu opisanym w RangingResultCallback. Taki błąd może wystąpić, jeśli usługa nie może wykonać operacji pomiaru odległości w danym momencie – na przykład dlatego, że Wi-Fi jest wyłączone, aplikacja poprosiła o zbyt wiele operacji pomiaru odległości i została ograniczona lub z powodu problemu z uprawnieniami.
• Po zakończeniu operacji określania zakresu funkcja onRangingResults wywołanie zwrotne z listą wyników pasujących do listy żądań – jeden wynik na każde żądanie. Kolejność wyników nie jest muszą się zgadzać z kolejnością żądań. Pamiętaj, że operacja określania zakresu może ale każdy wynik może wskazywać na niepowodzenie danego pomiar skuteczności.

Zinterpretuj wyniki określania zakresu

Każdy z wyników zwróconych przez onRangingResults wywołanie zwrotne jest określane przez RangingResult obiektu. Wykonaj te czynności przy każdym żądaniu.

1. Zidentyfikuj żądanie

Określ żądanie na podstawie informacji podanych podczas tworzenia RangingRequest: najczęściej jest to adres MAC podany w ScanResult identyfikujący dostęp . Adres MAC można uzyskać z wyników pomiaru zasięgu za pomocą metody getMacAddress().

Lista wyników z przedziałem może mieć inną kolejność niż wyniki z grupy porównawczej (dostęp punktów) określonych w prośbie o zakres zakresu, więc należy użyć adresu MAC, identyfikować elementy porównawcze, a nie kolejność wyników.

2. Określanie, czy poszczególne pomiary zakończyły się powodzeniem

Aby sprawdzić, czy pomiar się powiódł, użyj metody getStatus(). Wartość inna niż STATUS_SUCCESS oznacza błąd. Niepowodzenie oznacza, że wszystkie inne pola tego wyniku (z wyjątkiem identyfikatora żądania) są nieprawidłowe, a odpowiednia metoda get* zakończy się błędem z wyjątkiem IllegalStateException.

3. Uzyskaj wyniki dla każdego udanego pomiaru

W przypadku każdego udanego pomiaru (RangingResult) możesz pobrać wyniki odpowiednimi metodami get:

• Odległość w mm i odchylenie standardowe pomiaru:

  getDistanceMm()

  getDistanceStdDevMm()

• RSSI pakietów używanych na potrzeby pomiarów:

  getRssi()

• Czas (w milisekundach) wykonania pomiaru (wskazujący czas od uruchomienia):

  getRangingTimestampMillis()

• Liczba prób pomiarów i liczba pomiarów, które zakończyły się powodzeniem (i na których opierają się pomiary odległości):

  getNumAttemptedMeasurements()

  getNumSuccessfulMeasurements()

• Minimalny i maksymalny czas oczekiwania urządzenia klienckiego w zakresie 11 az NTB pomiary:

  getMinTimeBetweenNtbMeasurementsMicros() oraz getMaxTimeBetweenNtbMeasurementsMicros() zwracają minimalny i maksymalny czas. Jeśli następne żądanie pomiaru zasięgu zostanie wysłane przed upłynięciem minimalnego czasu, interfejs API zwróci wynik pomiaru zasięgu z pamięci podręcznej. Jeśli po upływie maksymalnego czasu żądanie kolejnego pomiaru pomiaru zasięgu zostanie wysłane, interfejs API zakończy nieaktywowaną sesję pomiaru zasięgu i zacznie negocjować nową sesję pomiaru zasięgu ze stacją odpowiadającą. Nie zalecamy żądania nowej sesji pomiaru zasięgu, ponieważ wydłuża to czas pomiaru zasięgu. Aby w pełni korzystać z protokołu 802.11az wydajność określania zakresu bez reguły, aktywuj następne żądanie zakresu między minimalnym a maksymalnym czasem pomiaru określonym w poprzednim Pomiar: RangingResult.

• powtórzenia w polu Long Training Field (LTF) użytkowników, którzy reagują na pytania i inicjatory; użyte we wstępie do wyniku IEEE 802.11az NTB:

  get80211azResponderTxLtfRepetitionsCount()

  get80211azInitiatorTxLtfRepetitionsCount()

• Liczba strumieni czasu transmisji i odbierania w czasie przestrzennym (STS), które inicjator stacja używana do określenia wyniku IEEE 802.11az NTB:

  get80211azNumberOfTxSpatialStreams()

  get80211azNumberOfRxSpatialStreams()

Uwaga: do oszacowania dokładności wyniku NTB w standardzie IEEE 802.11az można użyć zarówno powtórzeń LTF, jak i liczby strumieni czasowych przestrzeni przesyłania i odbierania (STS).

Urządzenia z Androidem, które obsługują WiFi-RTT

W tabelach poniżej znajdziesz listę niektórych telefonów, punktów dostępu i urządzeń do sprzedaży detalicznej, magazynowania i centrum dystrybucji, które obsługują WiFi-RTT. Nie są one w żaden sposób wyczerpujące. Zachęcamy do skontaktuj się z nami , aby wyświetlić produkty obsługujące RTT.

Punkty dostępu

Producent i model	Data wsparcia
Nest Wifi Pro (Wi-Fi 6E)	Obsługiwane
Przeprowadź obliczenia WILD AP	Obsługiwane
Wi-Fi od Google	Obsługiwane
Router Google Nest Wifi	Obsługiwane
Punkt Google Nest Wi-Fi	Obsługiwane
Aruba AP-635	Obsługiwane
Cisco 9130	Obsługiwane
Cisco 9136	Obsługiwane
Cisco 9166	Obsługiwane
Cisco 9164	Obsługiwane
Aruba AP-505	Obsługiwane
Aruba AP-515	Obsługiwane
Aruba AP-575	Obsługiwane
Aruba AP-518	Obsługiwane
Aruba AP-505H	Obsługiwane
Aruba AP-565	Obsługiwane
Aruba AP-535	Obsługiwane

Telefony

Producent i model	Wersja Androida
Pixel 6	9,0+
Pixel 6 Pro	9,0+
Pixel 5	9.0+
Pixel 5a	9.0+
Pixel 5a (5G)	9.0+
Xiaomi Mi 10 Pro	9,0+
Xiaomi Mi 10	9,0+
Xiaomi Redmi Mi 9T Pro	9,0+
Xiaomi Mi 9T	9,0+
Xiaomi Mi 9	9.0+
Xiaomi Mi Note 10	9.0+
Xiaomi Mi Note 10 Lite	9,0+
Xiaomi Redmi Note 9S	9.0+
Xiaomi Redmi Note 9 Pro	9.0+
Xiaomi Redmi Note 8T	9,0+
Xiaomi Redmi Note 8	9.0+
Xiaomi Redmi K30 Pro	9,0+
Xiaomi Redmi K20 Pro	9.0+
Xiaomi Redmi K20	9.0+
Xiaomi Redmi Note 5 Pro	9.0+
Xiaomi Mi CC9 Pro	9.0+
LG G8X ThinQ	9,0+
LG V50S ThinQ	9.0+
LG V60 ThinQ	9.0+
LG V30	9,0+
Samsung Galaxy Note 10+ 5G	9,0+
Samsung Galaxy S20+ 5G	9.0+
Samsung Galaxy S20+	9,0+
Samsung Galaxy S20 5G	9.0+
Samsung Galaxy S20 Ultra 5G	9.0+
Samsung Galaxy S20	9,0+
Samsung Galaxy Note 10+	9,0+
Samsung Galaxy Note 10 5G	9,0+
Samsung Galaxy Note 10	9.0+
Samsung A9 Pro	9.0+
Google Pixel 4 XL	9.0+
Google Pixel 4	9,0+
Google Pixel 4a	9.0+
Google Pixel 3 XL	9,0+
Google Pixel 3	9.0+
Google Pixel 3a XL	9.0+
Google Pixel 3a	9.0+
Google Pixel 2 XL	9,0+
Google Pixel 2	9,0+
Google Pixel 1 XL	9,0+
Google Pixel 1	9.0+
Poco X2	9,0+
Sharp AQUOS R3 SH-04L	9,0+

Urządzenia do handlu detalicznego, magazynowania i dystrybucyjnego

Producent i model	Wersja Androida
Zebra PS20	10.0 lub nowszy
Zebra TC52/TC52HC	10,0+
Zebra TC57	10,0+
Zebra TC72	10.0 lub nowszy
Zebra TC77	10.0 lub nowszy
Zebra MC93	10.0 lub nowszy
Zebra TC8300	10.0 lub nowszy
Zebra VC8300	10.0 lub nowszy
Zebra EC30	10,0+
Zebra ET51	10,0+
Zebra ET56	10.0 lub nowszy
Zebra L10	10,0+
Zebra CC600/CC6000	10.0 lub nowszy
Zebra MC3300x	10,0+
Zebra MC330x	10,0+
Zebra TC52x	10,0+
Zebra TC57x	10,0+
Zebra EC50 (LAN i HC)	10,0+
Zebra EC55 (WAN)	10.0 lub nowszy
Zebra WT6300	10,0+
Skorpio X5	10,0+