Nastavení Android Kiosk: Co dělat, když vás majitel zařízení uzamkne mimo nastavení
A10,1palcový tablet se systémem Android byl nakonfigurován pro použití v režimu kiosku pomocí ADB, vlastního spouštěče a funkce Device Owner. Po restartu se aplikace spustila podle očekávání, avšak zařízení již nemohlo přistupovat k běžnému rozhraní nastavení systému Android.
To vyvolalo běžnou výzvu při nasazování kiosků: jak lze zařízení obnovit pro další testování, pokud byly omezeny systémové navigační funkce a ovládací prvky správy zařízení? A pokud aplikace potřebuje otevřít Wi-Fi nebo jiné systémové funkce, které Android Intents lze stále použít?
Zákazník nejprve použil příkazy ADB ke změně chování systémového uživatelského rozhraní:
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
Aplikace byla poté nastavena jako výchozí úvodní obrazovka a následně byla aplikace nakonfigurována jako Device Owner povolit požadované funkce správy zařízení.
Po restartování se Android kiosk tablet automaticky spustil aplikaci podle očekávání. Zákazník však již nemohl opustit hlavní obrazovku aplikace, aby získal přístup k nastavení systému Android nebo jiným systémovým funkcím. Tlačítka Nastavení a Wi-Fi integrovaná do aplikace také přestala otevírat odpovídající systémové stránky.
Okamžitou otázkou nebylo pouze, jak aplikaci ukončit. Zákazník potřeboval spolehlivý způsob, jak obnovit Androidová tableta pro další testování a zároveň chtěl pochopit, které systémové Intenty může jeho aplikace využívat.
Proč se Android tablet stal obtížně přístupným
Problém vznikl současným použitím několika vrstev řízení zařízení.
Vlastní spouštěč určoval, která aplikace se zobrazí jako úvodní obrazovka, zatímco vlastník zařízení poskytoval aplikaci mnohem širší kontrolu nad zásadami zařízení. Dokumentace k Androidu pro specializovaná zařízení podporuje tento typ konfigurace pro nasazení v režimu kiosku a spravovaných zařízení, včetně řízení výchozí úvodní aplikace a omezení přístupu ke systémovým funkcím.
Příkazy ADB přidaly další vrstvu změnou chování systémového uživatelského rozhraní. Tyto konkrétní nastavení závisí na zařízení nebo firmwaru, nikoli na univerzálních rozhraních API systému Android, takže jejich přesný účinek závisí na tom, jak je dané nastavení implementováno ve firmwaru tabletu.
To znamená, že Android tablet používaný jako kiosk může být obtížné obnovit, pokud jsou současně změněny spouštěč, konfigurace vlastníka zařízení, omezení systémového uživatelského rozhraní a navigace v aplikaci.
Skutečnost, že tlačítko Nastavení nebo Wi-Fi v aplikaci již nefunguje, nutně neznamená, že je samotný Intent nesprávný. Cílová aktivita Nastavení může být nedostupná, omezená nebo jinak nepřístupná za dané konfigurace zařízení. Android také doporučuje zkontrolovat, zda lze Intent vyřešit, ještě než se pokusíte jej spustit.

Obnovovací cesty pro uzamčený kioskový tablet s operačním systémem Android
Pokud je aplikace již nakonfigurována jako vlastník zařízení, měla by se jako první zvážit softwarová obnova.
Androidův DevicePolicyManager poskytuje funkce správy zařízení, které může využívat vlastník zařízení. V závislosti na verzi Androidu a konfiguraci aplikace může aplikace vlastníka zařízení použít příslušný mechanismus vymazání zařízení, aby tablet vrátila do čistého stavu pro testování. wipeData() je standardní rozhraní API pro vymazání uživatelských dat, zatímco novější verze Androidu poskytují další funkce pro vymazání zařízení.
Zastaralá metoda clearDeviceOwnerApp() tuto metodu nesmíte považovat za obecnou metodu obnovy výroby. Android ji dokumentuje jako rozhraní API zaměřené na testování a doporučuje tovární obnovení jako běžný způsob odstranění vztahu majitele zařízení.
ADB poskytuje také příkazy pro správu zásad zařízení, avšak tyto příkazy mají omezení. Například adb shell dpm remove-active-admin není univerzální metodou pro odstranění majitele zařízení; dokumentace ADB pro Android stanovuje požadavky, jako je deklarace aplikace testOnly .
Pokud není softwarová obnova k dispozici, protože aplikace nemůže provést požadovanou operaci, zbývá jediná možnost – tovární obnovení prostřednictvím hardwaru nebo postup obnovy systému Android .
Přesnou kombinaci tlačítek nesmíte předpokládat na základě jiného modelu tabletu s Androidem. Chování režimu obnovy je určeno firmwarem a hardwarovou implementací konkrétního tabletu. U projektu přizpůsobeného tabletu s Androidem je proto nutné před nasazením potvrdit vhodný postup obnovy pro daný model a firmwar.
Pro tento typ Android kiosk tablet , mít definovanou metodu obnovení je zvláště užitečné během integračního testování, protože konfigurace na úrovni systému může záměrně odstranit běžnou navigaci uživatele.
Testování záměrů nastavení a systémových funkcí na tabletu s Androidem
Druhá otázka zákazníka zněla, zda aplikace dokáže přímo spustit systémové funkce, jako jsou Nastavení a Wi-Fi.
Android poskytuje standardní akce pro nastavení pro tyto funkce. Například:
|
Funkce |
Standardní záměr Androidu |
|
Hlavní nastavení |
Settings.ACTION_SETTINGS |
|
Nastavení Wi-Fi |
Settings.ACTION_WIFI_SETTINGS |
|
Bezdrátová nastavení |
Nastavení.ACTION_WIRELESS_SETTINGS |
|
Nastavení Bluetooth |
Nastavení.ACTION_BLUETOOTH_SETTINGS |
|
Nastavení displeje |
Nastavení.ACTION_DISPLAY_SETTINGS |
|
Nastavení polohy |
Nastavení.ACTION_LOCATION_SOURCE_SETTINGS |
|
Nastavení zvuku |
Nastavení.ACTION_SOUND_SETTINGS |
|
Nastavení zabezpečení |
Nastavení.ACTION_SECURITY_SETTINGS |
|
Nastavení aplikace |
Nastavení.ACTION_APPLICATION_SETTINGS |
|
Konkrétní nastavení aplikace |
Nastavení.ACTION_APPLICATION_DETAILS_SETTINGS |
Jedná se o standardní akce nastavení systému Android, nikoli o rozhraní specifická pro konkrétního Výrobce tabletu s Androidem . Existence záměru (Intent) však nezaručuje, že se úspěšně spustí na každém zařízení nebo za každé konfigurace kiosku. Systém Android doporučuje zkontrolovat záměr pomocí metody resolveActivity() před jeho spuštěním.
U systémově integrovaného tabletu s Androidem by proto mělo být testování záměrů prováděno přímo na firmware a verzi systému Android, které budou použity při nasazení. Test by měl ověřit nejen existenci záměru, ale také to, zda lze po aplikaci omezení v režimu majitele zařízení (Device Owner), spouštěče (launcher) a systémového uživatelského rozhraní (system UI) skutečně dosáhnout odpovídající aktivity.
Pokud pracujete na projektu Android kioskového tabletu nebo systémové integrace a potřebujete pomoc s obnovením režimu Device Owner, úmysly (Intents) pro nastavení nebo souvisejícími konfiguračními problémy, kontaktujte nás prosím s modelem vašeho tabletu a verzí systému Android. Můžeme společně probrat dostupné technické podporové a přizpůsobovací možnosti.
Stejný princip platí i pro jiné systémové funkce. Standardní Android API může existovat, avšak skutečné chování přizpůsobeného tabletu závisí na jeho verzi systému Android, konfiguraci firmwaru a zásadách správy zařízení.
Co se týče požadavků na probuzení?
Zákazníkova otázka týkající se „požadavků na probuzení“ se mírně liší od spuštění stránky Nastavení.
Intent.ACTION_SCREEN_ON reprezentuje systémovou vysílací zprávu (broadcast), která signalizuje, že displej se stal interaktivním. Jedná se o chráněnou systémovou vysílací zprávu, proto aplikace by neměla tento úmysl považovat za běžný Intent, který by mohla jednoduše odeslat za účelem probuzení tabletu.
Pokud je požadavek probudit displej, zabránit jeho usnutí nebo řídit chování při zapínání displeje , vhodný mechanismus závisí na konkrétních požadavcích aplikace. Android poskytuje rozhraní API pro správu napájení a pro okna/aktivity pro tyto scénáře, včetně PowerManager a funkce uzamčení probuzení (wake-lock) tam, kde je to vhodné.
Toto rozlišení je důležité při vývoji aplikací pro Android kiosk tablet . „Spustit systémovou funkci“ a „ovládat stav napájení zařízení“ jsou různé systémové operace a měly by být zpracovávány prostřednictvím různých rozhraní API.

Technická podpora pro integraci tabletu s Androidem
Tento případ také ukazuje, proč nasazení režimu kiosku může vyžadovat více než základní hardwarovou konfiguraci tabletu s Androidem.
Při integraci tabletu do specializované aplikace, systému pro prodejní místa (POS), kiosku, průmyslového systému nebo jiného spravovaného zařízení může softwarová konfigurace zahrnovat spouštěč (launcher), vlastníka zařízení (Device Owner), systémové uživatelské rozhraní (system UI), oprávnění aplikací, úmysly nastavení (Settings Intents) a chování při obnově (recovery behavior) současně.
Pro projekty vyžadující přizpůsobený tablet s Androidem konfigurace – tyto požadavky je třeba vyhodnotit společně s hardwarovou a softwarovou konfigurací systému Android, nikoli jako samostatné problémy během finálního testování.
Příslušné řešení závisí na verzi systému Android, firmwaru tabletu, konfiguraci aplikace a funkcích, které systémový integrátor potřebuje řídit. Technická dokumentace může být také připravena na základě dostupných rozhraní systému, podporovaných Intentů, oprávnění a zařízení-specifických omezení.
Pokud testujete Androidová tableta pro nasazení v režimu kiosku nebo pro systémovou integraci a narazíte na podobné problémy s Vlastníkem zařízení, vlastními spouštěči, režimem kiosku, Intenty nastavení, omezeními uživatelského rozhraní systému nebo obnovou zařízení , prosím kontaktujte nás pro technickou podporu .
Můžete uvést model svého tabletu, verzi systému Android, konfiguraci nasazení a konkrétní funkci, kterou se snažíte implementovat. Poté můžeme diskutovat o dostupných Přizpůsobeních tabletů se systémem Android a technické podpoře možnostech pro váš projekt.