Android-kioskopsætning: Hvad du skal gøre, når enhedens ejer har låst dig ude af indstillingerne

A10,1-toms Android-tablet ble konfigureret til kioskbrug med ADB, en brugerdefineret startprogram og Device Owner. Efter genstart blev programmet startet som forventet, men enheden kunne ikke længere få adgang til den normale Android-indstillingsgrænseflade.

Dette skabte en almindelig udfordring ved kioskinstallation: Når systemnavigationen og enhedsstyringskontrollerne er begrænset, hvordan kan tabletten så gendannes til yderligere test? Og hvis programmet skal åbne Wi-Fi eller andre systemfunktioner, hvilke Android-intents kan så stadig bruges?

Kunden brugte først ADB-kommandoer til at ændre system-UI-opførslen:

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 blev derefter indstillet som standardstartskærm, efterfulgt af konfiguration af programmet som Device Owner aktivere de påkrævede enhedsstyringsfunktioner.

Efter genstarten gik Android-kiosk-tabletten automatisk ind i programmet som forventet. Kunden kunne dog ikke længere forlade programmets hovedskærm for at få adgang til Android-indstillingerne eller andre systemfunktioner. Indstillinger- og Wi-Fi-knapperne, der er integreret i programmet, åbnede også ikke længere de tilsvarende systemside.

Det umiddelbare spørgsmål handlede ikke kun om, hvordan man forlader programmet. Kunden havde brug for en pålidelig metode til at gendanne Android-tablet til yderligere test samt ønskede at forstå, hvilke systemintents der kunne bruges af deres program.

Hvorfor Android-tabletten blev svær at få adgang til

Problemet opstod på grund af flere lag af enhedsstyring, der blev anvendt samtidigt.

Den brugerdefinerede startprogram bestemte, hvilken applikation der blev vist som startsiden, mens Device Owner gav applikationen langt bredere kontrol over enhedspolitikken. Androids dokumentation til dedikerede enheder understøtter denne konfigurationstype til kiosk- og administrerede enhedsinstallationer, herunder kontrol af standardstartsiden og begrænsning af adgangen til systemfunktioner.

ADB-kommandoerne tilføjede en ekstra lag ved at ændre systemets brugergrænsefladeadfærd. Disse specifikke indstillinger afhænger af enheden eller firmwaren i stedet for universelle Android-API'er, så deres præcise virkning afhænger af, hvordan tablet-firmwaren implementerer dem.

Dette betyder, at en Android-tablet, der bruges som kiosk-enhed kan blive svær at gendanne, når startprogrammet, Device Owner-konfigurationen, begrænsningerne for systemets brugergrænseflade og applikationsnavigationen alle ændres samtidigt.

Det faktum, at appens indstillings- eller Wi-Fi-knap ikke længere virker, betyder ikke nødvendigvis, at Intenten i sig selv er forkert. Den målrettede indstillingsaktivitet kan være utilgængelig, begrænset eller på anden måde utilgængelig under den aktuelle enhedskonfiguration. Android anbefaler også at kontrollere, om en Intent kan løses, før man forsøger at starte den.

Gendannelsesveje til en låst Android-kiosk-tablet

Hvis appen allerede er konfigureret som enhedsejer, bør softwarebaseret gendannelse overvejes først.

Androids DevicePolicyManager udbyder enhedsstyringsfunktioner, som kan bruges af en enhedsejer. Afhængigt af Android-versionen og appens konfiguration kan en enhedsejer-app bruge den passende enheds-sletningsmekanisme for at nulstille tabletten til en ren tilstand til testformål. wipeData() er den etablerede API til sletning af brugerdatabestande, mens nyere Android-versioner tilbyder yderligere funktionalitet til enhedssletning.

Den afskaffede clearDeviceOwnerApp() metoden bør ikke behandles som en generel produktionsgenvindingsmetode. Android dokumenterer den som en API, der er rettet mod test, og anbefaler fabriksnulstilling som den normale måde at fjerne en enhedsadministratorrelation på.

ADB giver også kommandoer til styring af enhedspolitikker, men disse har begrænsninger. For eksempel adb shell dpm remove-active-admin er ikke en universel metode til at fjerne en enhedsadministrator; Androids ADB-dokumentation specificerer krav såsom applikationens testOnly erklæring.

Hvis softwarebaseret genvinding ikke er tilgængelig, fordi applikationen ikke kan udføre den påkrævede handling, er den resterende mulighed en hardwarebaseret fabriksnulstilling eller en Android-genvindingsprocedure .

Den præcise knapkombination bør ikke antages ud fra en anden Android-tabletmodel. Genvindingsadfærd bestemmes af tabletens firmware og hardwareimplementation. For et tilpasset Android-tabletprojekt bør den korrekte genvindingsprocedure derfor bekræftes for den faktiske model og firmware før implementering.

For denne type Android-kiosk-tabletten , og en defineret genoprettelsesmetode er især nyttig under integrationstest, fordi systemniveauets konfiguration bevidst kan fjerne almindelig brugernavigation.

Test af indstillingsintentioner og systemfunktioner på en Android-tablet

Kundens anden spørgsmål var, om applikationen kunne starte systemfunktioner som Indstillinger og Wi-Fi direkte.

Android tilbyder standardindstillingshandlinger til disse funktioner. For eksempel:

Funktion	Standard Android-intention
Hovedindstillinger	Settings.ACTION_SETTINGS
Wi-Fi-indstillinger	Settings.ACTION_WIFI_SETTINGS
Trådløse indstillinger	Settings.ACTION_WIRELESS_SETTINGS
Bluetooth-indstillinger	Settings.ACTION_BLUETOOTH_SETTINGS
Displayindstillinger	Settings.ACTION_DISPLAY_SETTINGS
Placering-indstillinger	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Lydindstillinger	Settings.ACTION_SOUND_SETTINGS
Sikkerhedsindstillinger	Settings.ACTION_SECURITY_SETTINGS
Programindstillinger	Settings.ACTION_APPLICATION_SETTINGS
Specifikke app-indstillinger	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Dette er standard-Android-indstillingshandlinger i stedet for grænseflader, der er specifikke for en bestemt Android-tabletproducent . Imidlertid garanterer eksistensen af en Intent ikke, at den vil åbne korrekt på alle enheder eller under alle kiosk-konfigurationer. Android anbefaler at kontrollere Intenten med resolveActivity() før den startes.

For en systemintegreret Android-tablet skal Intent-test derfor udføres på den faktiske firmware og Android-version, der bruges til implementering. Testen skal verificere ikke kun, om Intenten findes, men også om den tilsvarende Activity kan nås efter, at Device Owner-, startprogram- og system-UI-begrænsninger er blevet anvendt.

Hvis du arbejder med en Android-kiosk-tablet eller et systemintegrationsprojekt og har brug for hjælp til Device Owner-gendannelse, Settings-intents eller relaterede konfigurationsproblemer, bedes du kontakte os med din tabletmodel og Android-version. Vi kan drøfte de tilgængelige tekniske supportmuligheder og tilpasningsmuligheder.

 

Samme princip gælder for andre systemfunktioner. En standard Android-API kan eksistere, mens den faktiske adfærd på en tilpasset tablet afhænger af dens Android-version, firmwarekonfiguration og enhedsstyringspolitikker.

Hvad med vækkeforespørgsler?

Kundens spørgsmål om «vækkeforespørgsler» adskiller sig lidt fra at åbne en indstillings-side.

Intent.ACTION_SCREEN_ON repræsenterer en systembroadcast, der angiver, at skærmen er blevet interaktiv. Det er en beskyttet systembroadcast, så en applikation bør ikke behandle den som en almindelig intent, som den blot kan sende for at vække tabletten.

Hvis kravet er at vække skærmen, holde skærmen vågen eller styre skærm-til-stand-adfærd , den passende mekanisme afhænger af de præcise krav til anvendelsen. Android giver strømstyrings- og vindue/aktivitets-API'er til disse scenarier, herunder PowerManager og wake-lock-funktionalitet, hvor det er relevant.

Denne forskel er vigtig, når der udvikles programmer til en Android-kiosk-tabletten . "Start en systemfunktion" og "kontrolér enhedens strømtilstand" er forskellige systemoperationer og bør håndteres via forskellige API'er.

Teknisk support til integration af Android-tablet

Dette tilfælde viser også, hvorfor kiosk-installation kan kræve mere end den grundlæggende hardwarekonfiguration af en Android-tablet.

Når en tablet integreres i en dedikeret applikation, et POS-system, en kiosk, et industrielt system eller anden administreret enhed, kan softwarekonfigurationen samtidigt omfatte startprogrammet (launcher), enhedsadministrator (Device Owner), systembrugergrænsefladen (system UI), applikationstilladelser, indstillingsintents (Settings Intents) og genoprettelsesadfærd (recovery behavior).

For projekter, der kræver tilpasset Android-tablet konfigurationer skal disse krav vurderes sammen med hardwaren og Android-systemkonfigurationen i stedet for at behandles som separate problemer under den endelige test.

Den passende løsning afhænger af Android-versionen, tabletfirmwaren, applikationskonfigurationen og de funktioner, som systemintegratoren skal kunne styre. Der kan også udarbejdes teknisk dokumentation omkring de tilgængelige systemgrænseflader, understøttede Intents, tilladelser og enhedsspecifikke begrænsninger.

Hvis du tester en Android-tablet til kiosk-installation eller systemintegration og støder på lignende problemer med Device Owner, brugerdefinerede startprogrammer, kiosk-tilstand, indstillings-Intents, begrænsninger for systembrugergrænsefladen eller genopretning af enheden , venligst kontakt os til teknisk support .

Du kan angive din tabletmodel, Android-version, installationskonfiguration og den specifikke funktion, du forsøger at implementere. Vi kan derefter drøfte de tilgængelige Android-tablettilpasninger og tekniske support muligheder for dit projekt.