Przenoszenie istniejącej aplikacji na Androida na Vuzix LX1

Streszczenie

Vuzix LX1 – tworzenie aplikacji na Androida na to urządzenie można rozpocząć od aplikacji biznesowej, którą Twój zespół już utrzymuje. LX1 działa na zmodyfikowanym systemie Android 15, a Vuzix dokumentuje obsługę aplikacji z minimalnym poziomem API Androida 35 lub niższym. Wykorzystaj ponownie logikę biznesową i połączenia z systemami firmowymi, a następnie dostosuj układ ekranu, nawigację i zależności od urządzenia. Udana instalacja to dopiero pierwszy sprawdzian.

Ten przewodnik po przenoszeniu omawia układ dla wyświetlacza monokularnego, nawigację przyciskami oraz to, co przestaje działać. Programiści otworzą istniejący projekt Android Studio, podłączą prawdziwe LX1, zainstalują wersję testową, usprawnią interfejs i przygotują podpisane wydanie biznesowe. Już na wczesnym etapie zaplanuj działanie bez usług Google i przetestuj całą ścieżkę pracownika, w tym logowanie, skanowanie i powrót do pracy po utracie Wi-Fi.

Informacje przydatne przy planowaniu sprzętu znajdziesz na stronie produktu Vuzix LX1 w VR Expert.

Ilustracja koncepcyjna, nie zrzut ekranu urządzenia.

Wprowadzenie

Urządzenie Vuzix LX1 to samodzielny komputer ubieralny z Androidem przeznaczony do zadań magazynowych, przemysłowych i terenowych. Wyświetlacz monokularny to ekran oglądany jednym okiem. Pełnokolorowy wyświetlacz OLED pokazuje treści aplikacji obok normalnego pola widzenia pracownika; jest to wyświetlacz nieprzezierny (occluded), co oznacza, że sam ekran nie jest przezroczysty. Użytkownicy mogą nosić go przed dowolnym okiem.

Vuzix LX1 w warstwie oprogramowania korzysta ze znanych narzędzi Androida oraz opcjonalnych bibliotek Vuzix do obsługi głosu, skanowania kodów kreskowych i komponentów interfejsu. Przenoszenie (porting) oznacza dostosowanie istniejącego oprogramowania do innego urządzenia. W przypadku aplikacji do kompletacji zamówień w magazynie mogłoby to oznaczać zachowanie wyszukiwania zamówień i aktualizacji stanów magazynowych przy jednoczesnym zastąpieniu gęstego ekranu telefonu jedną instrukcją, jednym potwierdzeniem i czytelną ścieżką obsługi wyjątków. Są to zalecenia projektowe, a nie zmierzone wyniki testów LX1.

Oprogramowanie i wersje Vuzix LX1 – najważniejsze fakty

Instalacja i zarządzanie:

• USB przez ADB lub Vuzix View
• Vuzix App Store
• Opcje MDM od wielu partnerów.

• System operacyjny: Zmodyfikowany Android 15; poziom API 35. Minimalny SDK musi wynosić 35 lub mniej.
• Wyświetlacz: Pełnokolorowy OLED 980 × 550; orientacja pozioma lub odwrócona pozioma dla każdego z oczu.
• Sprzęt: Qualcomm QCS4490, 6 GB RAM i 128 GB pamięci masowej.
• Sterowanie: Łącznie cztery przyciski sterujące; trzy przyciski nawigacyjne obsługują krótkie i długie naciśnięcia; do tego sterowanie głosowe.
• Usługi Google: Brak Sklepu Google Play i pełnej obsługi GMS. Nie zakładaj, że zależności z telefonu będą działać.
• Opublikowana bazowa wersja firmware'u: Vuzix podaje wersję v15.2.0, wydaną 12-08-2026, z aktualizacjami Speech SDK 1.98.0 i Barcode SDK 2.0.0.

Firmware (oprogramowanie układowe) to zainstalowane oprogramowanie systemowe urządzenia. Opublikowane wydanie jest punktem odniesienia, a nie dowodem, że każde urządzenie w firmie ma tę kompilację. Zapisz zainstalowaną kompilację podczas kolejnych kroków.

Krok 1. Otwórz projekt istniejącej aplikacji biznesowej

Android Studio to środowisko programistyczne służące do edycji, kompilowania i debugowania aplikacji na Androida. Gradle to system kompilacji, który zamienia projekt w pakiet gotowy do instalacji.

· Otwórz projekt źródłowy. Uruchom Android Studio, wybierz Open i wskaż folder zawierający plik settings.gradle lub settings.gradle.kts. Poczekaj na zakończenie synchronizacji Gradle. Jeśli masz tylko plik APK, uzyskaj od jego właściciela projekt źródłowy i zgodę na modyfikację.

· Znajdź odpowiednie pliki. W panelu Project po lewej stronie wybierz widok Android. Otwórz app > manifests > AndroidManifest.xml oraz Gradle Scripts > build.gradle.kts (Module :app) lub jego odpowiednik build.gradle.

· Wybierz jedno zadanie pracownika. Zacznij od kompletnego procesu biznesowego, takiego jak otwarcie zadania kompletacji, zeskanowanie artykułu i potwierdzenie ilości. Podczas dostosowywania ekranów zachowaj bez zmian integrację z backendem i reguły walidacji.

Krok 2. Przygotuj LX1 i sieć firmową

SSID to nazwa sieci Wi-Fi. Użyj urządzenia testowego i zatwierdzonej przez dział IT sieci, która ma dostęp do firmowych systemów testowych.

· Zapisz zainstalowany system. Na LX1 otwórz Settings i znajdź informacje o urządzeniu lub sekcję About. Zapisz wyświetlaną tam wersję Androida i kompilację; nazwy menu mogą się różnić w zależności od firmware'u. Porównaj kompilację z informacjami o wydaniach publikowanymi przez Vuzix.

· Wygeneruj kod Wi-Fi. Na komputerze otwórz stronę vuzix.com/wifiQR. Wprowadź dane zatwierdzonej sieci w polach na stronie i wygeneruj kod QR. Według Vuzix generowanie odbywa się lokalnie w przeglądarce. W przypadku sieci firmowej z certyfikatami lub specjalnym uwierzytelnianiem poproś dział IT o użycie obsługiwanej przez niego metody konfiguracji.

· Połącz się z siecią. W launcherze LX1 otwórz Camera, wybierz skaner, skieruj go na kod i wybierz Join. Możesz też otworzyć Settings > Network & Internet > Wi-Fi, włączyć Wi-Fi, wybrać sieć i wpisać hasło.

Krok 3. Połącz Android Studio z LX1

ADB (Android Debug Bridge) to narzędzie, które pozwala komputerowi programisty instalować aplikacje i odczytywać diagnostykę urządzenia. APK to pakiet instalacyjny aplikacji na Androida.

· Zainstaluj narzędzia na komputerze. W Android Studio otwórz Tools > SDK Manager. Wybierz SDK Tools, zaznacz Android SDK Platform-Tools i kliknij Apply. Zanotuj ścieżkę Android SDK Location widoczną w tym oknie; ADB znajduje się w jej folderze platform-tools.

· Włącz połączenie z LX1. Na okularach otwórz Settings > Connected Devices > Allow ADB i włącz tę opcję. Podłącz kabel USB obsługujący transmisję danych. Jeśli urządzenie nie jest widoczne, włącz również przesyłanie plików przez USB w Connected Devices, zgodnie z instrukcją Vuzix. Przestrzegaj wymagań dotyczących zasilania USB dla LX1; opisana procedura kopiowania plików przewiduje odłączenie baterii i użycie portu USB-C lub portu USB 3.1 o wysokiej mocy w komputerze.

· Sprawdź autoryzację. Otwórz kartę Terminal w Android Studio. Uruchom adb devices z folderu platform-tools lub dodaj ten folder do zmiennej PATH komputera, czyli listy lokalizacji, w których wyszukiwane są polecenia. Jeśli na LX1 pojawi się monit o autoryzację debugowania, zaakceptuj go. Urządzenie powinno być widoczne na liście ze statusem device.

adb devices adb shell getprop ro.build.version.release adb shell getprop ro.build.version.sdk adb shell getprop ro.build.display.id adb shell wm size adb shell wm density adb shell getprop ro.product.cpu.abilist

Uruchamiaj te polecenia, gdy podłączone jest wyłącznie testowe LX1. Przy kilku urządzeniach wstaw -s SERIAL po adb, używając numeru seryjnego zwróconego przez adb devices. Gęstość (density) przelicza fizyczne piksele na jednostki układu Androida. ABI oznacza format procesora używany przez biblioteki natywne; porównaj zgłoszoną listę z bibliotekami .so dołączonymi do Twojego APK.

Zanotuj zgłoszoną gęstość; LX1 powinno zgłaszać 240 dpi (hdpi), co potwierdza polecenie adb shell wm density. Przeliczaj według wzoru dp = piksele x 160 / dpi: przy 240 dpi wyświetlacz 980 x 550 pikseli daje przestrzeń projektową około 653 x 367 dp. Projektuj układy tak, aby mieściły się w tym obszarze, a nie w surowych wymiarach w pikselach.

Krok 4. Zainstaluj niezmienioną wersję bazową i znajdź błędy

Logcat to panel Android Studio wyświetlający komunikaty aplikacji i urządzenia. Wersja bazowa (baseline) to oryginalna kompilacja, z którą porównuje się późniejsze zmiany.

· Uruchom istniejącą aplikację. Na górnym pasku narzędzi Android Studio wybierz konfigurację uruchomieniową aplikacji, a w selektorze urządzeń – podłączone LX1. Kliknij Run. Po otwarciu aplikacji spróbuj wykonać zadanie pracownika wybrane w kroku 1. Android Studio samo zainstaluje kompilację deweloperską.

· Zarejestruj błędy. Otwórz View > Tool Windows > Logcat, wybierz LX1 i przefiltruj komunikaty według pakietu aplikacji. Przed wprowadzaniem zmian zapisz awarie, nieosiągalne elementy sterujące, obcięty tekst, problemy z logowaniem i nieobsługiwane usługi.

· W razie potrzeby zainstaluj dostarczony testowy plik APK. W Terminalu użyj poniższego polecenia z rzeczywistą ścieżką do APK. Opcja -r aktualizuje zainstalowaną aplikację z zachowaniem danych, pod warunkiem że pakiet i certyfikat podpisu są zgodne. Nie odinstalowuj aplikacji przechowującej niezsynchronizowaną pracę tylko po to, by obejść błąd podpisu.

adb install -r "/absolute/path/to/business-app.apk"

Vuzix View to aplikacja komputerowa, która wyświetla lustrzany obraz okularów i może instalować pliki APK. Alternatywnie pobierz ją z Vuzix Support, włącz Allow ADB, podłącz LX1, wybierz je na liście podłączonych urządzeń, naciśnij View i przeciągnij APK na lustrzany interfejs. Do testów użyteczności używaj fizycznych przycisków, nawet jeśli obsługa z komputera pomaga przy debugowaniu.

Krok 5. Zaprojektuj układ dla wyświetlacza monokularnego

dp to jednostka Androida określająca rozmiar elementów układu; sp to jednostka dla tekstu, która uwzględnia ustawienia rozmiaru tekstu. Activity to ekran aplikacji na Androida, a manifest deklaruje komponenty i uprawnienia aplikacji.

· Popraw orientację. Wróć do app > manifests > AndroidManifest.xml. Znajdź każdą Activity używaną przez pracowników. Usuń wymuszoną orientację pionową. Jeśli potrzebne jest ograniczenie do orientacji poziomej, użyj w tej Activity wartości sensorLandscape, aby interfejs mógł się obracać dla każdego z oczu. Zachowaj pozostałe atrybuty i filtry intencji.

<activity android:name=".PickingActivity" android:screenOrientation="sensorLandscape" />

· Uprość ekran zadania. Otwórz app > res > layout i wybierz plik XML bieżącego ekranu pracownika. W aplikacji opartej na Compose otwórz zamiast tego plik Kotlin zawierający ten ekran. Compose to zestaw narzędzi Androida do tworzenia interfejsów w języku Kotlin. Wyświetlaj bieżącą lokalizację, artykuł, ilość i następną czynność. Długie tabele i szczegółowe ustawienia przenieś na osobny ekran.

· Dopasuj rozmiary do rzeczywistego okna. Użyj wymiarów i gęstości z kroku 3. Udokumentowana rozdzielczość 980 × 550 to piksele fizyczne, a nie płótno projektowe o szerokości 980 dp. Zacznij od czytelnego tekstu, wyraźnego kontrastu i niewielkiej liczby elementów sterujących; oceniaj efekt, mając urządzenie na sobie.

· Chroń widoczną zawartość. Wcięcia (insets) to obszary zajmowane przez paski systemowe lub inne elementy ekranu. Jeśli kierujesz aplikację na API 35, zapoznaj się z regułami wyświetlania od krawędzi do krawędzi (edge-to-edge) w Androidzie 15 i w razie potrzeby zastosuj wcięcia, aby przyciski i instrukcje pozostały widoczne. Oprócz ekranu głównego przetestuj okna dialogowe, klawiatury i monity o uprawnienia.

Ilustracja koncepcyjna, nie zrzut ekranu urządzenia.

Krok 6. Zapewnij dostęp do każdej czynności za pomocą przycisków

Fokus to widoczne zaznaczenie wskazujące, który element sterujący zareaguje na Select. KeyEvent to komunikat Androida opisujący naciśnięcie przycisku. Przyciski nawigacyjne LX1 wysyłają następujące udokumentowane zdarzenia.

Przedni:

• Krótkie naciśnięcie: W prawo lub następny niższy element sterujący; DPAD_RIGHT
• Długie naciśnięcie: Menu kontekstowe; MENU

Środkowy:

• Krótkie naciśnięcie: W lewo lub poprzedni wyższy element sterujący; DPAD_LEFT
• Długie naciśnięcie: Ekran główny; HOME

Tylny:

• Krótkie naciśnięcie: Wybór elementu z fokusem; DPAD_CENTER
• Długie naciśnięcie: Wstecz; BACK

· Zdefiniuj ścieżkę fokusu. W pliku XML układu ekranu ustaw interaktywne elementy sterujące jako focusable i określ nextFocusLeft oraz nextFocusRight. Nawet formularz pionowy potrzebuje tych ścieżek, ponieważ krótkie naciśnięcia przycisków nawigacyjnych LX1 wysyłają zdarzenia w lewo i w prawo. Nie zostawiaj w ścieżce etykiet ani kontenerów dekoracyjnych.

· Dodaj widoczny stan zaznaczenia. Utwórz plik app > res > drawable > lx1_action_background.xml i wklej poniższy selektor. Selektor to zasób, który zmienia wygląd w zależności od stanu elementu sterującego. W tym przykładzie użyto obrysu, dzięki czemu fokus jest widoczny bez polegania wyłącznie na kolorze.

<selector xmlns:android="http://schemas.android.com/apk/res/android"> <item android:state_focused="true"> <shape> <solid android:color="#12354A" /> <stroke android:width="3dp" android:color="#FFFFFF" /> <corners android:radius="6dp" /> </shape> </item> <item> <shape> <solid android:color="#242424" /> <corners android:radius="6dp" /> </shape> </item> </selector>

· Podłącz dwie czynności. W istniejącym układzie ekranu umieść te przyciski w jego kontenerze. To przykład oparty na Views; jeśli aplikacja korzysta z Compose, zachowaj obecną architekturę Compose. Dostosuj identyfikatory i teksty do swojego procesu. Poniższy kod XML wymaga zasobu drawable utworzonego powyżej.

<Button android:id="@+id/confirmButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:focusable="true" android:nextFocusLeft="@id/exceptionButton" android:nextFocusRight="@id/exceptionButton" android:background="@drawable/lx1_action_background" android:backgroundTint="@null" android:textColor="#FFFFFF" android:text="Confirm quantity"> <requestFocus /> </Button> <Button android:id="@+id/exceptionButton" android:layout_width="match_parent" android:layout_height="wrap_content" android:focusable="true" android:nextFocusLeft="@id/confirmButton" android:nextFocusRight="@id/confirmButton" android:background="@drawable/lx1_action_background" android:backgroundTint="@null" android:textColor="#FFFFFF" android:text="Report shortage" />

· Użyj istniejących procedur obsługi biznesowej. W Activity, po setContentView, połącz te przyciski z istniejącymi funkcjami potwierdzania i zgłaszania braków za pomocą setOnClickListener. Nie przechwytuj wszystkich zdarzeń klawiszy: standardowe przyciski z fokusem potrafią obsłużyć wybór. Po zamknięciu okna dialogowego lub zmianie zadania przywróć fokus na odpowiednią czynność.

// In your Activity, after setContentView: findViewById<Button>(R.id.confirmButton).setOnClickListener { confirmQuantity() // Your existing validated business action } findViewById<Button>(R.id.exceptionButton).setOnClickListener { reportShortage() // Your existing exception workflow }

Zaimportuj android.widget.Button. Zastąp obie nazwy funkcji rzeczywistymi procedurami obsługi z Twojego projektu; nie są to dostarczane API Androida.

· Sprawdź całą ścieżkę. Ponownie uruchom aplikację na LX1. Używając wyłącznie przycisków nawigacyjnych, zaloguj się, dotrzyj do każdej czynności, wybierz ją i wróć za pomocą Back. Powtórz to po otwarciu okna dialogowego i po przełożeniu urządzenia na drugie oko. W Compose zaimplementuj równoważne ścieżki fokusu za pomocą focusRequester i focusProperties.

Krok 7. Usuń zależności telefoniczne, których LX1 nie spełni

GMS (Google Mobile Services) to zastrzeżone usługi Google dla Androida. API to interfejs programistyczny służący do korzystania z danej funkcji. microG to zgodna implementacja niektórych interfejsów usług Google; jej obecność nie gwarantuje pełnej obsługi usług Google.

· Przeprowadź audyt zależności. Otwórz blok dependencies modułu oraz ewentualny katalog wersji libs.versions.toml. Wyszukaj com.google.android.gms, Firebase, logowanie przez Google, mapy, licencjonowanie i uczenie maszynowe dostarczane przez usługi. Przetestuj każdą zależność używaną w procesie pracownika. Vuzix podaje, że LX1 nie obsługuje pełnego GMS, choć w opisie firmware'u v15.2.0 wymieniono aktualizację microG GmsCore.

· W razie potrzeby zastąp wymagane integracje. Korzystaj z obsługiwanej w firmie metody logowania, interfejsów API serwera i zarządzanej konfiguracji. Aktualny przegląd Vuzix dotyczący programowania na LX1 nadal zaleca używanie biblioteki Google Play Services Client Library w wersji 9.8.0 lub starszej w przypadku Cloud Messaging i Maps. Traktuj to jako uwagę historyczną (usługa Google Cloud Messaging została wycofana w 2018 roku i wyłączona w 2019 roku), a nie jako aktualne rozwiązanie dla firm; poproś Vuzix i właściciela zależności o potwierdzenie konkretnego interfejsu.

· Przejrzyj wymagania sprzętowe. W AndroidManifest.xml sprawdź deklaracje uses-feature i uprawnienia dotyczące ekranu dotykowego, telefonii i lokalizacji. Oznaczaj sprzęt jako opcjonalny tylko wtedy, gdy aplikacja ma działające rozwiązanie zastępcze. Deklaracja nie tworzy brakującego sprzętu. Przetestuj odmowę uprawnień do kamery i mikrofonu bez utraty zadania.

· Dostosuj metody wprowadzania danych do pracy. Zastąp wielokrotne wpisywanie tekstu zatwierdzonym skanowaniem, krótką listą wyboru lub zarządzanymi ustawieniami. W przypadku logowania zachowaj uwierzytelnianie w firmowym systemie tożsamości; sam zeskanowany identyfikator nie powinien autoryzować pracownika.

Krok 8. Dodaj skanowanie kodów kreskowych lub obsługę głosu tylko wtedy, gdy są potrzebne

SDK to zestaw narzędzi zapewniający dostęp do funkcji oprogramowania lub urządzenia. Vuzix Barcode SDK uruchamia wbudowany skaner i zwraca wynik; Vuzix Speech SDK dodaje niestandardowe polecenia głosowe; HUD Resources i HUD ActionMenu udostępniają opcjonalne komponenty interfejsu.

· Wybierz sposób skanowania kodów. Do sporadycznego skanowania przy logowaniu lub konfiguracji zacznij od oficjalnego repozytorium Vuzix Barcode SDK i podlinkowanej w nim dokumentacji Javadoc. Na LX1 używaj interfejsów w wersji 2.0.0 lub nowszej. Starsze tryby osadzony i ciągły z SDK 1.x nie są obsługiwane na LX1. Do ciągłego skanowania w magazynie z własnym podglądem zintegruj API kamery i odpowiedni silnik dekodujący.

· Jeśli używasz ML Kit, dołącz model dekodujący do aplikacji. ML Kit to zestaw narzędzi Google do uczenia maszynowego. Jego model kodów kreskowych można spakować w aplikacji, co pozwala uniknąć pobierania modelu przez Usługi Google Play. W app/build.gradle.kts > dependencies dodaj poniższą udokumentowaną zależność w wersji dołączanej (bundled), a następnie kliknij Sync Now. Nie dodawaj jednocześnie wariantu dołączanego i niedołączanego. Ta zależność nie jest kompletnym skanerem: połącz klatki z kamery i wyniki skanowania, korzystając z oficjalnego przykładu.

implementation("com.google.mlkit:barcode-scanning:17.3.0")

· Dodaj polecenia głosowe dopasowane do zadań. Otwórz Vuzix Support > Developer Resources i postępuj zgodnie z instrukcją Working with the Vuzix Speech SDK. Upewnij się, że wersja biblioteki jest zgodna z firmware'em urządzenia, dodaj jej repozytorium i zależność modułu, zsynchronizuj projekt, a następnie zarejestruj polecenia, takie jak „Confirm quantity” (potwierdź ilość) i „Report shortage” (zgłoś brak), za pomocą udokumentowanego API. Kieruj rozpoznane polecenia do tych samych procedur walidacji co przyciski.

· Przetestuj również kompilację wydaniową. Jeśli dodajesz SDK Vuzix, sprawdź ich aktualne reguły zmniejszania kodu (shrinking) i uruchom podpisaną, zoptymalizowaną kompilację. Starsza dokumentacja zawiera instrukcje dotyczące jcenter i android.enableR8=false; nie wklejaj ich do nowoczesnej konfiguracji kompilacji bez potwierdzenia, że mają zastosowanie. Przetestuj działanie w hałasie, różne języki, zdublowane polecenia i skanowanie niewłaściwego artykułu.

Co przestaje działać po przeniesieniu aplikacji z telefonu z Androidem na LX1

Nie można dotrzeć do elementu sterującego:

• Prawdopodobna przyczyna: Gesty wyłącznie dotykowe lub brak ścieżek fokusu
• Praktyczne rozwiązanie: Zapewnij czynności obsługujące fokus i jawne ścieżki w lewo/w prawo.

Tekst lub okna dialogowe są obcięte:

• Prawdopodobna przyczyna: Układ telefoniczny, blokada orientacji pionowej lub brak wcięć
• Praktyczne rozwiązanie: Uprość ekran, obsłuż obie orientacje poziome i zastosuj wcięcia.

Logowanie, mapy lub powiadomienia nie działają:

• Prawdopodobna przyczyna: Zależność zakłada dostępność pełnych usług Google
• Praktyczne rozwiązanie: Sprawdź konkretne API i zastąp nieobsługiwane integracje.

Migracja skanera kończy się niepowodzeniem:

• Prawdopodobna przyczyna: Stary tryb Vuzix SDK 1.x lub zależność od pobierania modelu
• Praktyczne rozwiązanie: Używaj obsługiwanych interfejsów 2.x lub dołączonego silnika.

Instalacja lub ładowanie bibliotek natywnych kończy się niepowodzeniem:

• Prawdopodobna przyczyna: Niezgodny minSdk, klucz podpisu lub natywne ABI
• Praktyczne rozwiązanie: Przeanalizuj błąd instalacji i dopasuj przetestowaną platformę oraz certyfikat.

Praca znika lub się powtarza:

• Prawdopodobna przyczyna: Stan nie zostaje przywrócony lub żądanie jest wysyłane dwukrotnie
• Praktyczne rozwiązanie: Zapisuj trwale oczekującą pracę i stosuj ochronę przed duplikatami po stronie serwera.

Praca w tle zostaje zatrzymana:

• Prawdopodobna przyczyna: Reguły wersji Androida lub opuszczenie aplikacji przez pracownika
• Praktyczne rozwiązanie: Przejrzyj zmiany w działaniu Androida 15 i przetestuj rzeczywiste przejścia cyklu życia.

To ryzyka do przetestowania, a nie twierdzenie, że każda aplikacja zawiedzie. Android 15 zmienia też działanie usług pierwszoplanowych. Usługa pierwszoplanowa (foreground service) to długotrwała operacja aplikacji z widocznym powiadomieniem. Przejrzyj zarówno zmiany w Androidzie dotyczące wszystkich aplikacji, jak i te wynikające z docelowego poziomu API, zwłaszcza w kontekście przesyłania danych, zdalnej pomocy i synchronizacji bez nadzoru.

Krok 9. Przetestuj proces biznesowy na urządzeniu

· Powtórz rzeczywiste zadanie. Przetestuj oba ustawienia względem oczu, przyciski, zatwierdzone polecenia głosowe, formaty kodów kreskowych, monity o uprawnienia i wygasanie sesji. Wyświetlaj lustrzany obraz ekranu w Vuzix View do obserwacji, ale niech pracownik obsługuje prawdziwe okulary.

· Przećwicz odzyskiwanie. Przerwij połączenie Wi-Fi podczas potwierdzania, połącz się ponownie, otwórz ponownie aplikację i sprawdź system firmowy. Oczekujące transakcje powinny przetrwać, a zakończone nie powinny się duplikować. Osobno przetestuj Home i Back, a także ponowne uruchomienie urządzenia i przekazanie zmiany.

· Zmierz wyniki pilotażu. Porównaj czas realizacji, błędy wprowadzania, czas odzyskiwania i liczbę zgłoszeń do wsparcia z obecnym procesem. Przetestuj obciążenie skanowaniem i wideo w warunkach oczekiwanych podczas zmiany. Przedstaw zaobserwowane wyniki, zanim obiecasz poprawę wydajności lub czasu pracy baterii.

Zakres testów: ten artykuł opiera się na oficjalnej dokumentacji, a nie na praktycznej weryfikacji LX1 ani Twojej aplikacji. Przykłady kodu są punktem wyjścia do integracji i wymagają przeglądu pod kątem konkretnego projektu.

Krok 10. Podpisz APK i przygotuj wdrożenie w firmie

Podpisanie aplikacji polega na dołączeniu certyfikatu identyfikującego jej wydawcę. MDM (mobile device management, zarządzanie urządzeniami mobilnymi) pozwala działowi IT centralnie przygotowywać, konfigurować i aktualizować urządzenia firmowe.

· Utwórz pakiet wydaniowy. W Android Studio otwórz Build > Generate Signed Bundle / APK. Wybierz APK, kliknij Next i wybierz moduł aplikacji. Wprowadź zatwierdzoną ścieżkę magazynu kluczy (keystore), alias klucza i hasła. W przypadku aktualizacji użyj dotychczasowej tożsamości podpisu. Wybierz wariant release i folder wyjściowy, a następnie kliknij Create lub Finish – zależnie od wersji Studio.

· Przetestuj podpisany APK. Zainstaluj go na testowym LX1, powtórz podstawowe zadanie, a następnie przetestuj aktualizację z poprzedniej podpisanej kompilacji. Potwierdź zachowanie danych, dostęp do kamery i mikrofonu, skanowanie, obsługę głosu i łączność z serwerem. Sukces kompilacji debugowej nie dowodzi zgodności kompilacji wydaniowej.

· Przekaż projekt działowi IT. Dostarcz plik APK, identyfikator pakietu, kod wersji, obsługiwany firmware, uprawnienia, punkty końcowe sieci i wymagania konfiguracyjne. Vuzix informuje o dostępności MDM od wielu partnerów; potwierdź u swojego dostawcy konkretną obsługę LX1, metodę rejestracji urządzeń i proces instalacji aplikacji prywatnych. Nie zakładaj, że Managed Google Play jest dostępny.

· Wdrażaj etapami. Wdróż aplikację w małej grupie pracowników, przeanalizuj zmierzone wyniki i rozszerzaj wdrożenie dopiero wtedy, gdy ścieżki aktualizacji i odzyskiwania działają. Zachowaj poprzedni podpisany pakiet i określ plan przywracania zgodny z danymi. Wyłącz dostęp deweloperski na urządzeniach produkcyjnych zgodnie z polityką IT.

Korzyści i ograniczenia dla firm

· Korzyści. Ponowne wykorzystanie istniejącej logiki biznesowej na Androida może ograniczyć powielanie pracy programistycznej. Skoncentrowany proces może ułatwić potwierdzanie zamówień, inspekcje i obsługę wyjątków, pozostawiając pracownikom wolne ręce. Zweryfikuj tę korzyść w pilotażu.

· Ograniczenia. Ekrany silnie oparte na dotyku, integracje zależne od Google i założenia dotyczące starych SDK urządzeń mogą wymagać znaczących zmian. Obsługa floty urządzeń, aktualizacje firmware'u i testy wydań pozostają częścią prac wdrożeniowych.

Więcej o platformie znajdziesz w przeglądzie oprogramowania i platformy Vuzix LX1 od VR Expert.

Podsumowanie

Przenoszenie istniejącej aplikacji na Androida na Vuzix LX1 zaczyna się od sprawdzenia zależności od Androida i usług, podłączenia urządzenia testowego i zainstalowania wersji bazowej. Dostosuj układ do wyświetlacza monokularnego, zapewnij dostęp do każdej czynności za pomocą przycisków, dodaj skanowanie lub obsługę głosu tam, gdzie przyniesie to korzyść w pracy, i przetestuj podpisane wydanie przed wdrożeniem zarządzanym. W przypadku firm takie podejście pozwala zachować istniejącą integrację z systemami, a jednocześnie stworzyć proces dopasowany do pracowników korzystających z inteligentnych okularów. Pilotaż z pomiarami pokaże, czy adaptacja ogranicza błędy i oszczędza czas.

Porozmawiaj o pilotażu LX1 i wymaganiach wdrożeniowych z zespołem VR Expert ds. sprzętu dla firm.