Tworzenie aplikacji na RealWear Navigator 520 bez SDK: jak działa WearHF

Tworzenie aplikacji na RealWear Navigator 520 bez SDK: jak działa WearHF

Streszczenie

RealWear Navigator 520 pozwala tworzyć aplikacje z podstawową interakcją głosową bez osobnego SDK do obsługi mowy. WearHF jest częścią oprogramowania urządzenia. Potrafi przeanalizować ekran Androida, zidentyfikować obsługiwane widoki interaktywne i udostępnić dla nich polecenia głosowe. Standardowy przycisk Androida z etykietą CONTINUE można więc aktywować, mówiąc „CONTINUE”, bez importowania żadnej biblioteki RealWear.

Zacznij od standardowej aplikacji na Androida i przetestuj ją na docelowym firmware Navigatora. WearHF potrafi rozpoznawać obsługiwane elementy sterujące na ekranie bez kodu obsługi mowy po stronie aplikacji. Dodaj dyrektywę widoku w android:contentDescription, gdy element sterujący wymaga alternatywnych fraz lub specjalnego zachowania. Używaj OVERRIDE_COMMANDS tylko wtedy, gdy aplikacja musi przejąć kontrolę nad mechanizmem rozpoznawania mowy i samodzielnie obsługiwać polecenia. Te ścieżki działają różnie, co opisano poniżej.

Ważne: „bez SDK” nie oznacza „bez kodu”. Nadal tworzysz interfejs Androida i logikę biznesową. Aplikacja nie potrzebuje osobnego SDK mowy RealWear do podstawowego sterowania głosowego, ponieważ tę funkcję na poziomie urządzenia zapewnia WearHF.

Kluczowa koncepcja: do podstawowego sterowania głosowego nie otwierasz WearHF, nie instalujesz WearHF ani nie importujesz SDK WearHF. WearHF działa w tle jako część systemu operacyjnego RealWear.

Czym jest RealWear Navigator 520?

Urządzenie RealWear Navigator 520 to wytrzymały, monokularowy komputer typu assisted reality, przeznaczony do pracy na pierwszej linii, takiej jak konserwacja, inspekcje i serwis w terenie. Firmware 2.x RealWear dla modeli Navigator 500/520 opiera się na Androidzie 13, a wydanie serwisowe Ari OS 2.0 z 17-09-2026 (firmware 3.0, build 3.0.3-15 udostępniany urządzeniom z buildem 2.2.3-33) przenosi urządzenie na Androida 16. Plany rozwoju firmware mogą się zmieniać, dlatego traktuj system urządzenia jako ograniczenie wdrożeniowe: zapisuj w macierzy wydań przetestowany build firmware, poziom API Androida, minSdk/targetSdk aplikacji oraz model urządzenia. Nie wyprowadzaj minSdk ani targetSdk wyłącznie z wersji Androida w zestawie nagłownym.

Dla programistów oznacza to, że budujesz i pakujesz zwykłą aplikację na Androida. WearHF działa na urządzeniu i może udostępniać obsługiwane elementy sterujące do obsługi głosowej; nie realizuje jednak Twojego procesu roboczego, nie autoryzuje działań biznesowych ani nie zastępuje walidacji po stronie aplikacji.

Czym jest WearHF?

WearHF to wbudowana usługa RealWear do obsługi mowy i interakcji bez użycia rąk. Interpretuje obsługiwane widoki Androida i dyrektywy ekranowe, a następnie aktywuje widok lub wysyła zdarzenie mowy zgodnie z wybraną metodą integracji. Podstawowa interakcja z widokami nie wymaga osobnej biblioteki mowy RealWear. Osadzone dyrektywy są odczytywane z android:contentDescription; polecenia programowe korzystają z udokumentowanych intencji rozgłoszeniowych (broadcast intents) Androida. Nie myl kliknięcia widoku z nadpisaniem mechanizmu rozpoznawania mowy: nadpisanie przejmuje nad nim kontrolę i może blokować osadzone/skryptowe polecenia aż do przywrócenia.

Czego potrzebujesz przed zbudowaniem pierwszej aplikacji

· Navigator 520 z wersją firmware, którą zamierzasz obsługiwać; zapisz jej dokładny build i wersję Androida.

· Komputer z systemem Windows, macOS lub Linux.

· Android Studio z Android SDK i Platform Tools (ADB). Użyj poziomu API Androida wymaganego przez aplikację i zweryfikuj zgodność z firmware obsługiwanym przez RealWear.

· Kabel USB-C do transmisji danych.

· Żadnego SDK RealWear dla pierwszej aplikacji.

· Proces biznesowy do przetestowania, np. przejście do kolejnego kroku inspekcji lub zgłoszenie usterki sprzętu.

Jak zbudować sterowaną głosem aplikację na Androida bez SDK RealWear

Krok 1: Utwórz zwykły projekt Androida

Na potrzeby tego przewodnika zacznij od projektu opartego na Android Views. W Android Studio wybierz szablon Empty Activity oparty na Views (nie szablon przeznaczony wyłącznie dla Compose), a następnie wybierz Javę lub Kotlina. Poniższe przykłady używają Javy. Compose również może współpracować z WearHF w obsługiwanym oprogramowaniu, ale jego semantykę i drzewo ułatwień dostępu należy przetestować na docelowym buildzie.

1. Otwórz Android Studio i wybierz New Project.

2. Wybierz Empty Activity oparty na Views. Jeśli kreator wyświetla pola języka i minimalnego SDK, wybierz Javę i ustaw minSdk na najniższy poziom API Androida, który Twoja aplikacja faktycznie obsługuje; nie kopiuj wartości z tego przykładu bez sprawdzenia zależności i floty urządzeń.

3. Wprowadź dane aplikacji. Ustaw nazwę aplikacji, nazwę pakietu i lokalizację zapisu, a następnie utwórz projekt.

4. Poczekaj, aż projekt się otworzy. Android Studio zakończy synchronizację Gradle i otworzy projekt.

Na razie niczego nie dodawaj: nie szukasz szablonu projektu RealWear. Celem pierwszego buildu jest wykazanie, że standardowa aplikacja na Androida działa na Navigatorze 520.

Krok 2: Dodaj jeden przycisk Androida i połącz go z kodem Java

Najpierw utwórz jeden przycisk. Dodasz jego układ Androida, połączysz akcję kliknięcia w Javie, a następnie przetestujesz go na urządzeniu.

1. W panelu Project w Android Studio otwórz app > res > layout > activity_main.xml. Pełna ścieżka pliku to app/src/main/res/layout/activity_main.xml.

2. W edytorze układu wybierz Code. Zastąp zawartość pliku pełnym kodem XML pokazanym poniżej.

XML: jeden przycisk z poleceniem WearHF

Wklej cały układ do pliku activity_main.xml, a następnie zapisz plik:

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:padding="24dp">

<Button android:id="@+id/continueButton" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="CONTINUE" android:contentDescription="hf_commands:CONTINUE" />

</LinearLayout>

Krótkie wyjaśnienie: `LinearLayout` układa swoją zawartość pionowo. `android:text` to widoczna etykieta przycisku. `android:contentDescription` zawiera dyrektywę WearHF; to pole odczytują również usługi ułatwień dostępu Androida, więc sprawdź, czy element sterujący pozostaje zrozumiały dla użytkowników.

Następnie w panelu Project otwórz app > java > Twój pakiet > MainActivity.java. Pełna ścieżka to app/src/main/java/<your.package.name>/MainActivity.java. Zachowaj wygenerowaną klasę Activity i metodę `onCreate()`.

Jeśli go brakuje, dodaj `import android.widget.Button;` do importów na początku pliku MainActivity.java. Wewnątrz istniejącej metody `onCreate()` wklej te wiersze bezpośrednio po `setContentView(R.layout.activity_main);`:

Button continueButton = findViewById(R.id.continueButton); continueButton.setOnClickListener(v -> openNextStep());

Dodaj tę metodę poniżej `onCreate()`, ale przed końcowym nawiasem klamrowym zamykającym klasę MainActivity:

private void openNextStep() { // Przejdź do kolejnego kroku inspekcji lub zlecenia pracy. }

Jak to dostosować: zmień `android:text` na etykietę pasującą do Twojego procesu. Zmień `hf_commands:CONTINUE` na frazę, którą mają wypowiadać pracownicy, np. `hf_commands:Continue Work, Next Step`. Identyfikator XML `continueButton` musi odpowiadać `R.id.continueButton` w Javie; jeśli go zmienisz, zaktualizuj oba miejsca. Zastąp komentarz w `openNextStep()` nawigacją lub akcją biznesową, której potrzebuje aplikacja. Podstawowe sterowanie głosowe nie wymaga osobnego SDK WearHF ani uprawnienia `RECORD_AUDIO`.

Krok 3: Przygotuj Navigator 520 do programowania na Androida

Komputer deweloperski potrzebuje autoryzacji ADB, aby instalować i debugować aplikację. Użyj kabla USB-C obsługującego transmisję danych; kable służące wyłącznie do ładowania nie zostaną wykryte jako urządzenie ADB.

1. Otwórz Advanced Settings. Na ekranie głównym Navigatora powiedz MY SETTINGS, aby przejść do listy ustawień Androida.

2. Otwórz About Device. Powiedz ABOUT DEVICE, a następnie PAGE DOWN, aż pojawi się Build Number.

3. Włącz Developer Options. Powiedz BUILD NUMBER kilkakrotnie, około siedmiu razy, aż urządzenie potwierdzi włączenie trybu dewelopera.

4. Otwórz Developer Options. Powiedz NAVIGATE BACK, następnie SYSTEM, a potem DEVELOPER OPTIONS.

5. Włącz debugowanie USB. W Developer Options włącz opcję USB debugging.

6. Podłącz kabel USB-C i zatwierdź na urządzeniu monit debugowania RSA. Potwierdź połączenie poleceniem `adb devices`; urządzenie powinno mieć status `device`, a nie `unauthorized`.

Jeśli Android Studio nie wyświetla zestawu nagłownego na liście, uruchom `adb devices`. Jeśli widzisz `unauthorized`, odblokuj zestaw i zatwierdź monit RSA. Aby ponownie zainstalować aplikację z katalogu głównego projektu, użyj `adb install -r app/build/outputs/apk/debug/app-debug.apk`; zmień ścieżkę, jeśli wariant buildu lub nazwa pliku APK są inne. Do analizy awarii i logów aplikacji użyj Logcat w Android Studio lub `adb logcat`.

Debugowanie USB to ustawienie deweloperskie. Wyłącz je po testach laboratoryjnych lub zarządzaj nim zgodnie z polityką bezpieczeństwa urządzeń obowiązującą w organizacji; nie pozostawiaj dostępu deweloperskiego włączonego na urządzeniach floty produkcyjnej.

Krok 4: Uruchom aplikację na Navigatorze 520

1. Wybierz Navigator w Android Studio. Użyj selektora urządzeń na górnym pasku narzędzi i wybierz podłączone urządzenie RealWear.

2. Kliknij Run. Wybierz zielony trójkąt Run lub użyj opcji Run > Run 'app'.

3. Poczekaj na instalację. Android Studio zbuduje plik APK i zainstaluje go na Navigatorze przez ADB.

4. Uruchom zainstalowaną aplikację z launchera aplikacji na urządzeniu lub wykonaj `adb shell monkey -p your.application.id 1` w terminalu deweloperskim. Zastąp `your.application.id` wartością applicationId z pliku kompilacji Gradle modułu aplikacji.

5. Sprawdź, czy przycisk CONTINUE jest widoczny i aktywny.

Krok 5: Przetestuj WearHF bez dodawania żadnego SDK

WearHF już działa na Navigatorze 520. Gdy na ekranie jest tylko przycisk CONTINUE, najpierw przetestuj ten element sterujący:

1. Powiedz CONTINUE i sprawdź, czy standardowy listener kliknięć aplikacji wykona się dokładnie raz.

2. Powiedz SHOW HELP, aby sprawdzić polecenie udostępniane przez WearHF dla tego ekranu. Upewnij się, że wyświetlane jest CONTINUE.

3. Sprawdź wskaźniki WearHF i przetestuj wybór numeryczny, jeśli jest dostępny. Nie polegaj na wskaźniku jako jedynym sposobie identyfikacji działania krytycznego dla bezpieczeństwa.

Opcjonalnie: dodaj drugą akcję po teście CONTINUE

Gdy pierwszy przycisk działa, możesz dodać REPORT ISSUE. W pliku activity_main.xml umieść ten element Button wewnątrz LinearLayout, poniżej CONTINUE i przed </LinearLayout>:

<Button android:id="@+id/reportIssueButton" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="REPORT ISSUE" />

W pliku MainActivity.java dodaj ten listener wewnątrz onCreate(), po listenerze CONTINUE:

Button reportIssueButton = findViewById(R.id.reportIssueButton); reportIssueButton.setOnClickListener(v -> openIssueReport());

Dodaj metodę openIssueReport() poniżej onCreate(), wewnątrz MainActivity. Zastąp komentarz procesem zgłaszania usterek w Twojej aplikacji:

private void openIssueReport() { // Otwórz formularz zgłoszenia usterki sprzętu. }

Ponownie zbuduj i zainstaluj aplikację, a następnie powiedz REPORT ISSUE. Sprawdź, czy otwiera się proces zgłaszania usterki.

Podsumowanie

Tworzenie aplikacji na RealWear Navigator 520 bez dedykowanego SDK dowodzi, że czysty, standardowy kod Androida już teraz obsługuje sterowanie głosem, a wbudowana usługa WearHF przekształca widoczne widoki i dyrektywy contentDescription w intuicyjne elementy sterowania bez użycia rąk. Zespołom technicznym takie podejście pozwala uniknąć rozrastania aplikacji o zewnętrzne biblioteki i złożone silniki mowy, a zarazem utrzymać kluczową logikę biznesową w ramach standardowej architektury Androida. Z perspektywy biznesowej skraca to czas wprowadzenia rozwiązania na rynek i minimalizuje koszty wdrożenia: przedsiębiorstwa mogą bezpośrednio wykorzystać istniejące aplikacje na Androida i kompetencje własnych programistów, uniknąć uzależnienia od zamkniętego SDK i płynnie modernizować procesy pracowników pierwszej linii bez zakłócania swojego stosu oprogramowania.

Na potrzeby pierwszego prototypu dla przedsiębiorstwa zbuduj jeden ekran inspekcji lub konserwacji, sprawdź etykiety widoków i opisy dostępności, a następnie przetestuj aktywację głosową na dokładnie tym firmware Navigatora 520, którego używa flota pilotażowa. Osadzone dyrektywy dodawaj w przypadku konkretnych potrzeb interfejsu, a nadpisania mechanizmu rozpoznawania mowy tylko wtedy, gdy proces wymaga pełnej kontroli nad poleceniami.

João Noronha

Napisane przez

João Noronha

Specjalista ds. XR i treści immersyjnych w VR Expert

João Noronha jest specjalistą ds. XR i treści immersyjnych w VR Expert, z dużym zainteresowaniem technologiami przyszłości i ich praktycznymi zastosowaniami. Skupia się na przekształcaniu złożonych osiągnięć w dziedzinie VR, AR, okularów AI i technologii immersyjnych w jasne, praktyczne treści dla firm i specjalistów odkrywających branżę XR.

Często zadawane pytania

Ten artykuł

Tak. Aplikacja nadal jest aplikacją na Androida, więc programiści tworzą interfejs i logikę biznesową w Javie, Kotlinie, XML Views lub innym obsługiwanym zestawie narzędzi UI dla Androida. Podstawowa interakcja z widokami przez WearHF nie wymaga osobnego SDK mowy RealWear.

Nie w przypadku podstawowych poleceń dla widoków. WearHF jest wbudowany w oprogramowanie RealWear i potrafi tworzyć polecenia na podstawie obsługiwanych widoków Androida. Do niestandardowych zachowań używaj udokumentowanych dyrektyw lub intencji.

Nie otwiera się go jako osobnej aplikacji. WearHF działa w tle jako część oprogramowania Navigatora 520.

W przypadku obsługiwanych klikalnych widoków WearHF może utworzyć polecenie na podstawie tekstu widoku lub opisu zawartości (content description), w zależności od dyrektywy i hierarchii widoków. Przetestuj polecenie udostępniane na rzeczywistym ekranie – widoczna etykieta nie stanowi gwarancji w przypadku każdego niestandardowego widoku.

Powiedz SHOW HELP na Navigatorze 520. RealWear wyświetli polecenia powiązane z tym ekranem.

W aplikacji opartej na Views otwórz plik XML układu (np. app/src/main/res/layout/activity_main.xml) i ustaw atrybut `android:contentDescription` dla widoku. Użyj `hf_commands:Phrase One, Phrase Two` dla wielu fraz oraz `-` między wieloma dyrektywami.

`hf_commands` to dyrektywa WearHF na poziomie widoku. Umieść ją w contentDescription widoku, a po niej frazy oddzielone przecinkami – każda rozpoznana fraza klika ten widok.

Osadzone dyrektywy nie wymagają osobnej biblioteki WearHF. Są to ciągi znaków w atrybucie contentDescription Androida, które interpretuje usługa urządzenia. Ponieważ contentDescription jest używany także przez usługi ułatwień dostępu, zachowaj przydatną etykietę dostępności i przetestuj oba zachowania.

Używaj OVERRIDE_COMMANDS, gdy lista poleceń mechanizmu rozpoznawania mowy musi zostać zastąpiona w czasie działania aplikacji. W przypadku poleceń na poziomie ekranu, które uzupełniają widoki, rozważ `hf_add_commands`. Pamiętaj, że tryb nadpisania tymczasowo blokuje osadzone/skryptowe polecenia i musi zostać przywrócony lub ponownie zarejestrowany w udokumentowanych punktach cyklu życia.

Informacje o wydaniu RealWear Collaborate z maja 2026 r. podają, że WearHF natywnie obsługuje Jetpack Compose. To dowód na obsługę Compose przez platformę, ale nie zastępuje testowania semantyki, niestandardowych komponentów composable, etykiet dostępności i nakładek poleceń we własnej aplikacji. Ten samouczek korzysta z XML Views, aby mapowanie widoków na polecenia było jednoznaczne. Źródło: informacje o wydaniu Collaborate 2.5.1 odnotowują, że WearHF natywnie obsługuje Compose (opublikowano 2026-05-07). Odnoś to twierdzenie wyłącznie do oprogramowania urządzenia zawierającego odpowiednią obsługę i sprawdź działanie na docelowym buildzie.

Opublikowane wydanie firmware 2.2 dla Navigatora 500/520 opiera się na Androidzie 13. Polityka firmware RealWear zakłada plan przeniesienia obsługiwanych urządzeń na system oparty na Androidzie 16 w ciągu 2026 r., ale plan nie jest gwarancją wydania. Przed wyborem compileSdk, targetSdk, minSdk, uprawnień lub zachowania wydania sprawdź aktualne informacje o wydaniu GA i przetestuj dokładnie ten build, którego używa flota.