Android-kioskinställning: Vad du ska göra när enhetsägaren låser dig ute från inställningarna

A10,1-tums Android-tablet konfigurerades för kioskdrift med ADB, en anpassad startsida och enhetsägare. Efter omstart startade programmet som förväntat, men enheten kunde inte längre komma åt den normala Android-inställningsgränssnittet.

Detta skapade en vanlig utmaning vid kioskdistribution: När systemnavigationen och enhetsstyrningskontrollerna har begränsats, hur kan tabletten återställas för vidare testning? Och om programmet behöver öppna Wi-Fi eller andra systemfunktioner, vilka Android-intents kan fortfarande användas?

Kunden använde först ADB-kommandon för att ändra systemgränssnittets beteende:

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

Programmet ställdes sedan in som standardstartsida, följt av konfiguration av programmet som Enhetsägare aktivera de nödvändiga funktionerna för enhetsstyrning.

Efter omstarten gick Android-kiosktabellen automatiskt in i applikationen som förväntat. Kunden kunde dock inte längre lämna applikationens huvudskärm för att komma åt Android-inställningar eller andra systemfunktioner. Inställningar- och Wi-Fi-knapparna som var integrerade i applikationen slutade också att öppna motsvarande system sidor.

Den omedelbara frågan var inte bara hur man avslutar applikationen. Kunden behövde en pålitlig metod för att återställa Android-tablet för vidare testning och ville även förstå vilka systemintents som deras applikation kunde använda.

Varför Android-tabellen blev svår att komma åt

Problemet uppstod på grund av flera lager av enhetskontroll som tillämpades samtidigt.

Startprogrammet anpassades för att avgöra vilken applikation som visas som startsida, medan Device Owner gav applikationen mycket större kontroll över enhetsprinciper. Androids dokumentation för specialanvända enheter stödjer den här typen av konfiguration för kiosk- och hanterade enhetsdistributioner, inklusive kontroll av standardstartsapplikationen och begränsning av åtkomst till systemfunktioner.

ADB-kommandona lade till en ytterligare nivå genom att ändra systemgränssnittets beteende. Dessa specifika inställningar är beroende av enheten eller firmwaren snarare än universella Android-API:er, så deras exakta effekt beror på hur tabletens firmware implementerar dem.

Detta innebär att en Android-tablet som används som kioskenhet kan bli svår att återställa när startprogrammet, Device Owner-konfigurationen, begränsningarna för systemgränssnittet och applikationsnavigationen alla ändras samtidigt.

Att inställningsknappen eller Wi-Fi-knappen i appen inte längre fungerar innebär inte nödvändigtvis att Intenten i sig är felaktig. Målets inställningsaktivitet kan vara otillgänglig, begränsad eller på annat sätt oåtkomlig under den aktuella enhetskonfigurationen. Android rekommenderar också att du kontrollerar om en Intent kan lösas innan du försöker starta den.

Återställningsvägar för en låst Android-kiosktablet

Om appen redan är konfigurerad som enhetsägare bör programbaserad återställning övervägas först.

Androids DevicePolicyManager tillhandahåller enhetshanteringsfunktioner som kan användas av en enhetsägare. Beroende på Android-versionen och appens konfiguration kan en enhetsägarapp använda den lämpliga enhetsraderingsmekanismen för att återställa tabletten till ett rent tillfälle för testning. wipeData() är den etablerade API:n för radering av användardata, medan nyare Android-versioner erbjuder ytterligare funktioner för enhetsradering.

Den föråldrade clearDeviceOwnerApp() metoden bör inte behandlas som en allmän produktionsåterställningsmetod. Android dokumenterar den som en API avsedd för testning och rekommenderar fabriksåterställning som det normala sättet att ta bort en Device Owner-relation.

ADB tillhandahåller även kommandon för hantering av enhetsprinciper, men dessa har begränsningar. Till exempel adb shell dpm remove-active-admin är inte en universell metod för att ta bort en Device Owner; Androids ADB-dokumentation specificerar krav såsom applikationens testOnly deklaration.

Om programvaruåterställning inte är tillgänglig eftersom applikationen inte kan utföra den krävda åtgärden är den återstående vägen en hårdvarubaserad fabriksåterställning eller en Android Recovery-procedur .

Den exakta knappkombinationen bör inte antas utifrån en annan Android-tabletmodell. Återställningsbeteendet bestäms av tabletens firmware och hårdvaruimplementation. För ett anpassat Android-tabletprojekt bör därför den lämpliga återställningsproceduren verifieras för den faktiska modellen och firmwaren innan distribution.

För denna typ av Android-kiosktabellen , att ha en definierad återställningsmetod är särskilt användbart under integrationsprovning eftersom systemnivåkonfiguration kan avsiktligt ta bort normal användarnavigation.

Testa inställningsavsedda funktioner och systemfunktioner på en Android-tablet

Kundens andra fråga var om applikationen kunde starta systemfunktioner direkt, till exempel Inställningar och Wi-Fi.

Android tillhandahåller standardinställningsåtgärder för dessa funktioner. Till exempel:

Funktion	Standard-Android-avsedd funktion
Huvudinställningar	Settings.ACTION_SETTINGS
Wi-Fi-inställningar	Settings.ACTION_WIFI_SETTINGS
Trådlösa inställningar	Inställningar.ACTION_WIRELESS_SETTINGS
Bluetooth-inställningar	Inställningar.ACTION_BLUETOOTH_SETTINGS
Visningsinställningar	Inställningar.ACTION_DISPLAY_SETTINGS
Platsinställningar	Inställningar.ACTION_LOCATION_SOURCE_SETTINGS
Ljudinställningar	Inställningar.ACTION_SOUND_SETTINGS
Säkerhetsinställningar	Inställningar.ACTION_SECURITY_SETTINGS
Applikationsinställningar	Inställningar.ACTION_APPLICATION_SETTINGS
Specifika applikationsinställningar	Inställningar.ACTION_APPLICATION_DETAILS_SETTINGS

 

Detta är standardåtgärder för Android-inställningar snarare än gränssnitt som är specifika för en viss Android-tabletillverkare . Existensen av en Intent garanterar dock inte att den kommer att öppnas framgångsrikt på varje enhet eller under varje kiosk-konfiguration. Android rekommenderar att du kontrollerar Intenten med resolveActivity() innan du startar den.

För en systemintegrerad Android-tablet bör Intent-testning därför utföras på den faktiska firmwaren och Android-versionen som används för distribution. Testet bör verifiera inte bara om Intenten finns, utan också om motsvarande Activity kan nås efter att begränsningar för Device Owner, startsida och systemgränssnitt har tillämpats.

Om du arbetar med en Android-kiosktavla eller ett systemintegrationsprojekt och behöver hjälp med Device Owner-återställning, Settings-intents eller relaterade konfigurationsproblem, kontakta oss gärna med din tablets modell och Android-version. Vi kan diskutera de tekniska stödalternativ och anpassningsmöjligheter som finns tillgängliga.

 

Samma princip gäller för andra systemfunktioner. En standard-Android-API kan finnas, men den faktiska funktionen hos en anpassad tablå beror på dess Android-version, firmwarekonfiguration och enhetshanteringspolicyer.

Vad gäller väckningsförfrågningar?

Kundens fråga om ”väckningsförfrågningar” skiljer sig något från att starta en inställningssida.

Intent.ACTION_SCREEN_ON representerar en systembroadcast som indikerar att skärmen blivit interaktiv. Det är en skyddad systembroadcast, så en applikation bör inte behandla den som en vanlig Intent som den enkelt kan skicka för att väcka tablån.

Om kravet är att väcka skärmen, hålla skärmen vaken eller styra skärm-på-beteendet , den lämpliga mekanismen beror på de exakta kraven för tillämpningen. Android tillhandahåller strömhanterings- och fönster/aktivitets-API:er för dessa scenarier, inklusive PowerManager och wake-lock-funktioner där det är lämpligt.

Den här skillnaden är viktig vid utveckling av appar för en Android-kiosktabellen . ”Starta en systemfunktion” och ”kontrollera enhetens strömläge” är olika systemåtgärder och bör hanteras via olika API:er.

Teknisk support för integrering av Android-tabletter

Detta fall visar också varför kioskdistribution kan kräva mer än den grundläggande hårdvarukonfigurationen för en Android-tablett.

När en tablet integreras i en dedikerad applikation, ett POS-system, en kiosk, ett industriellt system eller annan hanterad enhet kan programvarukonfigurationen omfatta startsidan, Device Owner, systemgränssnittet, applikationstillstånd, inställningsintenter och återställningsbeteende samtidigt.

För projekt som kräver anpassad Android-tablett konfigurationer bör dessa krav utvärderas tillsammans med hårdvaran och Android-systemkonfigurationen snarare än behandlas som separata frågor under den slutliga testningen.

Den lämpliga lösningen beror på Android-versionen, tabletens firmware, applikationskonfigurationen och de funktioner som systemintegratören behöver kontrollera. Teknisk dokumentation kan också förberedas kring de tillgängliga systemgränssnitten, de stödda Intents, behörigheterna och enhetsspecifika begränsningarna.

Om du testar en Android-tablet för kioskdistribution eller systemintegration och stöter på liknande problem med Device Owner, anpassade startsidor, kioskläge, Inställningar-Intents, begränsningar av systemanvändargränssnittet eller enhetsåterställning snälla kontakta oss för teknisk support .

Du kan ange din tablets modell, Android-version, distributionskonfiguration och den specifika funktion som du försöker implementera. Vi kan sedan diskutera de tillgängliga Anpassningarna av Android-tabletter och den tekniska supporten alternativ för ditt projekt.