Konfiguracja trybu kioskowego systemu Android: co zrobić, gdy właściciel urządzenia zablokuje dostęp do ustawień

A10,1-calowy tablet z systemem Android został skonfigurowany do użytku w trybie kiosku przy użyciu ADB, niestandardowego programu uruchamiającego oraz funkcji „Właściciel urządzenia”. Po ponownym uruchomieniu aplikacja została uruchomiona zgodnie z oczekiwaniami, lecz urządzenie nie mogło już uzyskać dostępu do standardowego interfejsu ustawień systemu Android.

Powstał w ten sposób typowy problem wdrożeniowy kiosków: gdy nawigacja systemowa i kontrole zarządzania urządzeniem zostały ograniczone, jak odzyskać tablet do dalszych testów? A jeśli aplikacja musi otworzyć połączenie Wi-Fi lub inne funkcje systemowe, które intencje Androida pozostają nadal dostępne?

Klient najpierw użył poleceń ADB do modyfikacji zachowania interfejsu użytkownika systemu:

adb shell settings put system hide_navbar 1

adb shell settings put system statusbar_disp 1

adb shell settings put system swipe_show_nav_bar 0

adb shell settings put system power_button_show 0

Następnie aplikację ustawiono jako domyślny ekran główny, a po tym skonfigurowano ją jako Właściciela urządzenia włączyć wymagane funkcje zarządzania urządzeniem.

Po ponownym uruchomieniu Tablet kioskowy z systemem Android automatycznie uruchomił aplikację zgodnie z oczekiwaniami. Jednak klient nie mógł już opuścić głównej strony aplikacji, aby uzyskać dostęp do ustawień systemu Android lub innych funkcji systemowych. Przyciski Ustawienia i Sieć Wi-Fi wbudowane w aplikację również przestały otwierać odpowiednie strony systemowe.

Natychmiastowym pytaniem nie było jedynie, jak opuścić aplikację. Klient potrzebował niezawodnej metody przywrócenia Tablet z systemem Android do dalszego testowania oraz chciał zrozumieć, które intencje systemowe mogą być wykorzystywane przez jego aplikację.

Dlaczego tablet z systemem Android stał się trudny w obsłudze

Problem wynikał z jednoczesnego zastosowania kilku warstw kontroli urządzenia.

Niestandardowy program uruchamiający określał, która aplikacja pojawiała się jako ekran główny, podczas gdy funkcja właściciela urządzenia zapewniała tej aplikacji znacznie szerszą kontrolę nad zasadami działania urządzenia. Dokumentacja systemu Android dotycząca urządzeń dedykowanych wspiera ten typ konfiguracji w przypadku wdrożeń kioskowych i zarządzanych urządzeń, w tym kontroli domyślnej aplikacji głównej oraz ograniczania dostępu do funkcji systemowych.

Polecenia ADB dodały kolejną warstwę, zmieniając zachowanie interfejsu użytkownika systemu. Te konkretne ustawienia zależą od konkretnego urządzenia lub oprogramowania sprzętowego, a nie od uniwersalnych interfejsów API systemu Android, więc ich dokładny wpływ zależy od tego, jak oprogramowanie sprzętowe tabletu je implementuje.

Oznacza to, że Tablet z systemem Android używany jako urządzenie kioskowe może stać się trudny do przywrócenia, gdy razem zmienione zostaną program uruchamiający, konfiguracja właściciela urządzenia, ograniczenia interfejsu użytkownika systemu oraz nawigacja w aplikacji.

To, że przycisk Ustawienia lub Wi-Fi w aplikacji przestał działać, nie oznacza koniecznie, że sam Intent jest niepoprawny. Docelowa aktywność Ustawień może być niedostępna, ograniczona lub w inny sposób niedostępna przy bieżącej konfiguracji urządzenia. Android zaleca również sprawdzenie, czy Intent można rozwiązać, zanim spróbuje się go uruchomić.

Ścieżki odzyskiwania dla zablokowanej tabletowej kiosku Android

Jeśli aplikacja jest już skonfigurowana jako właściciel urządzenia, najpierw należy rozważyć odzyskiwanie oparte na oprogramowaniu.

Androida DevicePolicyManager zapewnia funkcje zarządzania urządzeniem, które mogą być wykorzystywane przez właściciela urządzenia. W zależności od wersji systemu Android oraz konfiguracji aplikacji, aplikacja właściciela urządzenia może użyć odpowiedniego mechanizmu czyszczenia urządzenia, aby przywrócić tablet do czystego stanu do celów testowych. wipeData() jest ustanowionym interfejsem API do czyszczenia danych użytkownika, podczas gdy nowsze wersje systemu Android oferują dodatkowe funkcje czyszczenia urządzenia.

Wycofana clearDeviceOwnerApp() metodę nie należy traktować jako ogólną metodę odzyskiwania produkcji. Dokumentacja systemu Android określa ją jako interfejs API przeznaczony do testów i zaleca wykonanie resetu fabrycznego jako standardowy sposób usunięcia relacji właściciela urządzenia.

ADB oferuje również polecenia zarządzania zasadami urządzeń, ale są one ograniczone. Na przykład: adb shell dpm remove-active-admin nie jest uniwersalną metodą usuwania właściciela urządzenia; dokumentacja ADB systemu Android określa wymagania, takie jak deklaracja aplikacji jako testOnly .

Jeśli odzyskiwanie oprogramowania jest niemożliwe, ponieważ aplikacja nie może wykonać wymaganej operacji, jedyną pozostającą opcją jest reset fabryczny sprzętowy lub procedura odzyskiwania systemu Android .

Dokładna kombinacja przycisków nie powinna być zakładana na podstawie innego modelu tabletu z systemem Android. Zachowanie trybu odzyskiwania zależy od oprogramowania układowego (firmware) i realizacji sprzętowej tabletu. W przypadku projektu dostosowanego tabletu z systemem Android odpowiednią procedurę odzyskiwania należy zatem potwierdzić dla konkretnego modelu i oprogramowania układowego przed wdrożeniem.

Dla tego typu Tablet kioskowy z systemem Android , posiadanie zdefiniowanej metody odzyskiwania jest szczególnie przydatne podczas testowania integracyjnego, ponieważ konfiguracja na poziomie systemu może celowo wyłączać standardową nawigację użytkownika.

Testowanie intencji ustawień i funkcji systemowych na tablecie z Androidem

Drugie pytanie klienta dotyczyło możliwości bezpośredniego uruchamiania przez aplikację funkcji systemowych, takich jak Ustawienia i Wi-Fi.

Android udostępnia standardowe akcje ustawień do tych funkcji. Na przykład:

Funkcja	Standardowa intencja Androida
Główne ustawienia	Settings.ACTION_SETTINGS
Ustawienia Wi-Fi	Settings.ACTION_WIFI_SETTINGS
Ustawienia bezprzewodowe	Settings.ACTION_WIRELESS_SETTINGS
Ustawienia Bluetooth	Settings.ACTION_BLUETOOTH_SETTINGS
Ustawienia wyświetlania	Settings.ACTION_DISPLAY_SETTINGS
Ustawienia lokalizacji	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Ustawienia dźwięku	Settings.ACTION_SOUND_SETTINGS
Ustawienia zabezpieczeń	Settings.ACTION_SECURITY_SETTINGS
Ustawienia aplikacji	Settings.ACTION_APPLICATION_SETTINGS
Specyficzne ustawienia aplikacji	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Są to standardowe akcje ustawień systemu Android, a nie interfejsy specyficzne dla konkretnego Producenta tabletów z systemem Android . Jednak istnienie intencji nie gwarantuje, że pomyślnie uruchomi się ona na każdym urządzeniu lub w każdej konfiguracji kiosku. System Android zaleca sprawdzenie intencji za pomocą metody resolveActivity() przed jej uruchomieniem.

W przypadku tabletu z systemem Android zintegrowanego z systemem, testowanie intencji powinno być przeprowadzone na rzeczywistym oprogramowaniu układowym oraz wersji systemu Android używanych do wdrożenia. Test powinien potwierdzić nie tylko istnienie intencji, ale także możliwość osiągnięcia odpowiedniej aktywności po zastosowaniu ograniczeń związanych z właścicielem urządzenia, programem uruchamiającym oraz interfejsem użytkownika systemu.

Jeśli pracujesz nad projektem tabletu kioskowego z systemem Android lub integracją systemową i potrzebujesz pomocy w zakresie odzyskiwania trybu właściciela urządzenia (Device Owner), intencji ustawień (Settings Intents) lub związanych z tym problemów konfiguracyjnych, skontaktuj się z nami, podając model tabletu oraz wersję systemu Android. Omówimy dostępne opcje wsparcia technicznego i dostosowania.

 

Ta sama zasada dotyczy innych funkcji systemowych. Standardowy interfejs API systemu Android może istnieć, ale rzeczywiste zachowanie niestandardowego tabletu zależy od jego wersji systemu Android, konfiguracji oprogramowania układowego (firmware) oraz zasad zarządzania urządzeniem.

A co z żądaniami aktywacji ekranu (wake requests)?

Pytanie klienta dotyczące „żądań aktywacji ekranu” (wake requests) różni się nieco od uruchamiania strony Ustawienia.

Intent.ACTION_SCREEN_ON reprezentuje emisję systemową informującą, że ekran stał się interaktywny. Jest to chroniona emisja systemowa, więc aplikacja nie powinna traktować jej jako zwykłej intencji (Intent), którą można po prostu wysłać w celu aktywowania tabletu.

Jeśli wymaganiem jest aktywacja ekranu, zapobieganie jego wygaszaniu lub kontrola zachowania związanego z włączaniem ekranu , odpowiedni mechanizm zależy od konkretnych wymagań aplikacji. Android udostępnia interfejsy API zarządzania energią oraz oknami/aktywnościami do takich scenariuszy, w tym PowerManager i funkcjonalność blokady pobudzenia (wake-lock), tam, gdzie jest to stosowne.

Ta różnica ma znaczenie podczas tworzenia aplikacji przeznaczonych dla Tablet kioskowy z systemem Android . „Uruchomienie funkcji systemowej” i „sterowanie stanem zasilania urządzenia” to różne operacje systemowe, które należy obsługiwać za pomocą różnych interfejsów API.

Wsparcie techniczne dla integracji tabletu z systemem Android

Ten przypadek pokazuje również, dlaczego wdrożenie trybu kioskowego może wymagać więcej niż podstawowa konfiguracja sprzętowa tabletu z systemem Android.

Gdy tablet jest integrowany z dedykowaną aplikacją, systemem POS, urządzeniem typu kiosk, systemem przemysłowym lub innym urządzeniem zarządzanym, konfiguracja oprogramowania może obejmować jednoczesne dostosowanie ekranu startowego (launcher), właściciela urządzenia (Device Owner), interfejsu użytkownika systemu (system UI), uprawnień aplikacji, intencji ustawień (Settings Intents) oraz zachowania podczas odzyskiwania (recovery behavior).

Dla projektów wymagających niestandardowy tablet z systemem Android konfiguracje — te wymagania należy oceniać łącznie z konfiguracją sprzętu i systemu Android, a nie traktować jako oddzielne problemy podczas końcowego testowania.

Odpowiednie rozwiązanie zależy od wersji systemu Android, oprogramowania sprzętowego tabletu, konfiguracji aplikacji oraz funkcji, które integrator systemowy musi kontrolować. Dokumentację techniczną można również przygotować na podstawie dostępnych interfejsów systemowych, obsługiwanych intencji (Intents), uprawnień oraz ograniczeń związanych z konkretnym urządzeniem.

Jeśli testujesz Tablet z systemem Android w celu wdrożenia w trybie kiosku lub integracji systemowej i napotykasz podobne problemy z Właścicielem urządzenia (Device Owner), niestandardowymi programami uruchamiania (custom launchers), trybem kiosku (kiosk mode), intencjami ustawień (Settings Intents), ograniczeniami interfejsu użytkownika systemu (system UI restrictions) lub przywracaniem urządzenia (device recovery) , Proszę skontaktuj się z nami w celu uzyskania pomocy technicznej .

Możesz podać model tabletu, wersję systemu Android, konfigurację wdrożenia oraz konkretną funkcję, którą próbujesz zaimplementować. Następnie możemy omówić dostępne Dostosowanie tabletów z systemem Android oraz pomoc techniczną opcjach dostępnych dla Twojego projektu.