Android-kioskoppsett: Hva du skal gjøre når enhetsadministratoren låser deg ute av innstillingene

A10,1-tommers Android-tablet ble konfigurert for bruk i kioskmodus med ADB, en tilpasset oppstartapplikasjon og enhetsadministrator. Etter omstart ble applikasjonen startet som forventet, men enheten kunne ikke lenger få tilgang til den vanlige Android-innstillingsgrensesnittet.

Dette skapte en vanlig utfordring ved kioskinstallasjoner: når systemnavigasjon og enhetsstyringskontroller er begrenset, hvordan kan tabletten gjenopprettes for videre testing? Og hvis applikasjonen må åpne Wi-Fi eller andre systemfunksjoner, hvilke Android-intents kan fortsatt brukes?

Kunden brukte først ADB-kommandoer for å endre systemets brukergrensesnittoppførsel:

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

Applikasjonen ble deretter satt som standard hjemmeskjerm, etterfulgt av konfigurering av applikasjonen som Enhetsadministrator for å aktivere de nødvendige enhetsstyringsfunksjonene.

Etter omstart gikk Android-kiosk-tabletten automatisk inn i programmet som forventet. Kunden kunne imidlertid ikke lenger forlate hovedskjermen til programmet for å få tilgang til Android-innstillinger eller andre systemfunksjoner. Innstillinger- og Wi-Fi-knappene som var integrert i programmet, sluttet også å åpne de tilsvarende systemsidene.

Det umiddelbare spørsmålet var ikke bare hvordan man skulle gå ut av programmet. Kunden trengte en pålitelig måte å gjenopprette Android tablet for videre testing og ønsket også å forstå hvilke systemintents programmet deres kunne bruke.

Hvorfor Android-tabletten ble vanskelig å få tilgang til

Problemet oppsto på grunn av flere lag med enhetskontroll som ble brukt samtidig.

Startprogrammet som ble brukt bestemte hvilken applikasjon som vises som hjemmeskjerm, mens Device Owner ga applikasjonen mye bredere kontroll over enhetspolicy. Androids dokumentasjon for dedikerte enheter støtter denne typen konfigurasjon for kiosk- og administrerte enhetsinstallasjoner, inkludert kontroll av standardhjemmeapplikasjonen og begrensning av tilgang til systemfunksjoner.

ADB-kommandoene la til et annet lag ved å endre oppførselen til brukergrensesnittet på systemnivå. Disse spesifikke innstillingene er avhengige av enheten eller firmwaren, ikke av universelle Android-API-er, så den nøyaktige virkningen avhenger av hvordan tabletens firmware implementerer dem.

Dette betyr at en Android-tablet som brukes som kiosk-enhet kan bli vanskelig å gjenopprette når startprogrammet, Device Owner-konfigurasjonen, begrensningene for systemets brukergrensesnitt og applikasjonsnavigasjon alle endres samtidig.

At applikasjonens innstillings- eller Wi-Fi-knapp ikke lenger fungerer, betyr ikke nødvendigvis at Intenten i seg selv er feil. Målets innstillingsaktivitet kan være utilgjengelig, begrenset eller på annen måte utilgjengelig under gjeldende enhetskonfigurasjon. Android anbefaler også å sjekke om en Intent kan løses før man prøver å starte den.

Gjenopprettingsmetoder for en låst Android-kiosk-tablet

Hvis applikasjonen allerede er konfigurert som enhetseier, bør programvarebasert gjenoppretting vurderes først.

Androids DevicePolicyManager tilbyr enhetsstyringsfunksjoner som kan brukes av en enhetseier. Avhengig av Android-versjonen og applikasjonens konfigurasjon kan en enhetseierapplikasjon bruke den passende enhetsrensingsmekanismen for å tilbakestille tabletten til en ren tilstand for testing. wipeData() er den etablerte API-en for å slette brukerdata, mens nyere Android-versjoner tilbyr tilleggsfunksjonalitet for enhetsrensing.

Den foreldede clearDeviceOwnerApp() metoden bør ikke behandles som en generell metode for produksjonsgjenoppretting. Android dokumenterer den som en API rettet mot testing og anbefaler fabrikktilbakestilling som den vanlige måten å fjerne en enhetsadministratorrelasjon på.

ADB tilbyr også kommandoer for enhetspolicyadministrasjon, men disse har begrensninger. For eksempel adb shell dpm remove-active-admin er ikke en universell metode for å fjerne en enhetsadministrator; Androids ADB-dokumentasjon spesifiserer krav som applikasjonens testOnly erklæring.

Hvis programvarebasert gjenoppretting ikke er tilgjengelig fordi applikasjonen ikke kan utføre den nødvendige operasjonen, er den gjenværende løsningen en hardwarebasert fabrikktilbakestilling eller en Android-gjenopprettingsprosess .

Den nøyaktige knappkombinasjonen bør ikke antas ut fra et annet Android-tabletmodell. Gjenopprettingsatferden bestemmes av tabletens firmware og hardwareimplementasjon. For et tilpasset Android-tabletprosjekt bør den riktige gjenopprettingsprosedyren derfor bekreftes for den faktiske modellen og firmwaren før distribusjon.

For denne typen Android-kiosk-tabletten , å ha en definert gjenopprettingsmetode er spesielt nyttig under integrasjonstesting, fordi systemnivå-konfigurasjon kan med vilje fjerne normal brukernavigasjon.

Testing av innstillingsintensjoner og systemfunksjoner på en Android-tablet

Kundens andre spørsmål var om applikasjonen kunne starte systemfunksjoner som Innstillinger og Wi-Fi direkte.

Android tilbyr standardinnstillingshandlinger for disse funksjonene. For eksempel:

Funksjon	Standard Android-intent
Hovedinnstillinger	Settings.ACTION_SETTINGS
Wi-Fi-innstillinger	Settings.ACTION_WIFI_SETTINGS
Trådløse innstillinger	Settings.ACTION_WIRELESS_SETTINGS
Bluetooth-innstillinger	Settings.ACTION_BLUETOOTH_SETTINGS
Visningsinnstillinger	Settings.ACTION_DISPLAY_SETTINGS
Plasseringsinnstillinger	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Lydinnstillinger	Settings.ACTION_SOUND_SETTINGS
Sikkerhetsinnstillinger	Settings.ACTION_SECURITY_SETTINGS
Applikasjonsinnstillinger	Innstillinger.ACTION_APPLICATION_SETTINGS
Spesifikke app-innstillinger	Innstillinger.ACTION_APPLICATION_DETAILS_SETTINGS

 

Dette er standard-Android-innstillingshandlinger, ikke grensesnitt som er spesifikke for en bestemt Android-tabletprodusent . Imidlertid garanterer eksistensen av en Intent ikke at den vil åpnes vellykket på alle enheter eller under alle kiosk-konfigurasjoner. Android anbefaler å sjekke Intenten med resolveActivity() før den startes.

For en systemintegrert Android-tablet bør Intent-testing derfor utføres på den faktiske firmwaren og Android-versjonen som brukes for distribusjon. Testen bør verifisere ikke bare om Intenten finnes, men også om den tilsvarende aktiviteten kan nås etter at begrensninger knyttet til enhetsadministrator, oppstartprogram og systembrukergrensesnitt er pålagt.

Hvis du jobber med et Android-kiosk-tablet- eller systemintegreringsprosjekt og trenger hjelp med Device Owner-gjenoppretting, Settings Intents eller relaterte konfigurasjonsproblemer, vennligst kontakt oss med modellnummeret på tabletten din og Android-versjonen. Vi kan diskutere tilgjengelig teknisk støtte og tilpasningsmuligheter.

 

Samme prinsipp gjelder for andre systemfunksjoner. En standard Android-API kan eksistere, mens det faktiske oppførselen til en tilpasset tablet avhenger av Android-versjonen, firmwarekonfigurasjonen og enhetsstyringspolitikkene.

Hva med oppvåkningssignaler?

Kundens spørsmål om «oppvåkningssignaler» er litt annerledes enn å starte en innstillings-side.

Intent.ACTION_SCREEN_ON representerer en systemkringkasting som indikerer at skjermen har blitt interaktiv. Det er en beskyttet systemkringkasting, så en applikasjon bør ikke behandle den som en vanlig Intent som den enkelt kan sende for å vekke tabletten.

Hvis kravet er å våkne skjermen, holde skjermen våken eller styre oppførselen til skjermen når den er på , og mekanismen som skal brukes, avhenger av nøyaktige brukskrav. Android tilbyr strømstyrings- og vindu/aktivitets-API-er for disse scenariene, inkludert PowerManager og wake-lock-funksjonalitet der det er hensiktsmessig.

Denne forskjellen er viktig når man utvikler applikasjoner for en Android-kiosk-tabletten . «Start en systemfunksjon» og «kontroller enhetens strømtilstand» er ulike systemoperasjoner og bør håndteres gjennom ulike API-er.

Teknisk støtte for integrasjon av Android-tablet

Dette tilfellet viser også hvorfor kiosk-implementering kan kreve mer enn grunnleggende maskinvarekonfigurasjon for en Android-tablet.

Når en tablet integreres i en dedisert applikasjon, et POS-system, en kiosk, et industrielt system eller en annen administrert enhet, kan programvarekonfigurasjonen samtidig omfatte oppstarter (launcher), enhetsadministrator (Device Owner), systembrukergrensesnitt (system UI), applikasjonsrettigheter, innstillingsintents (Settings Intents) og gjenopprettingsatferd (recovery behavior).

For prosjekter som krever tilpasset Android-tablet konfigurasjoner; disse kravene bør vurderes sammen med maskinvare- og Android-systemkonfigurasjonen, snarere enn å behandles som separate problemer under den endelige testen.

Den passende løsningen avhenger av Android-versjonen, nettbrettets firmware, applikasjonskonfigurasjonen og de funksjonene som systemintegratoren må kontrollere. Teknisk dokumentasjon kan også utarbeides basert på de tilgjengelige systemgrensesnittene, støttede Intents, tillatelser og enhetsspesifikke begrensninger.

Hvis du tester en Android tablet for kiosk-implementering eller systemintegrering og støter på lignende problemer med Device Owner, egendefinerte oppstartprogram, kioskmodus, Innstillinger-Intents, begrensninger for systembrukergrensesnittet eller enhetsgjenoppretting , vær så snill kontakt oss for teknisk støtte .

Du kan oppgi modellnummeret på ditt nettbrett, Android-versjonen, implementeringskonfigurasjonen og den spesifikke funksjonen du prøver å implementere. Vi kan deretter diskutere de tilgjengelige Tilpasningene for Android-nettbrett og den tekniske støtten valgmuligheter for prosjektet ditt.