Android-kioskopstelling: Wat om te doen as die toestel-eienaar jou buite die instellings sluit
A10,1-duim Android-tablet is vir kiosk-gebruik gekonfigureer met ADB, 'n aangepaste beginprogram en Toestel-eienaar. Na herbegin het die toepassing soos verwag geopen, maar die toestel kon nie meer toegang verkry tot die normale Android-instellingskoppelvlak nie.
Dit het 'n algemene uitdaging by kiosk-implimentering geskep: sodra stelselnavigasie- en toestelbestuurbeheer beperk is, hoe kan die tablet vir verdere toetsing herstel word? En as die toepassing Wi-Fi of ander stelselfunksies moet oopmaak, watter Android-intents kan steeds gebruik word?
Die kliënt het eers ADB-bevele gebruik om die stelsel-UI-gedrag te wysig:
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
Die toepassing is toe as die verstek-tuisbladsy gestel, gevolg deur die konfigurasie van die toepassing as Toestel-eienaar om die vereiste toestelbestuurfunksies te aktiveer.
Na herbegin het die Android-kiosk-tablet outomaties na die toepassing oorgeskakel soos verwag. Die kliënt kon egter nie meer vanaf die hoofskerm van die toepassing verlaat nie om toegang te kry tot Android-instellings of ander stelselfunksies nie. Die Instellings- en WiFi-knoppies wat binne-in die toepassing ingebou is, het ook opgehou om die ooreenstemmende stelselbladsye oop te maak.
Die onmiddellike vraag was nie net hoe om die toepassing te verlaat nie. Die kliënt het 'n betroubare manier nodig gehad om die Android tablet vir verdere toetsing te herstel, en wou ook verstaan watter stelsel-Intents deur hul toepassing gebruik kon word.
Hoekom die Android-tablet moeilik om by te kom geword het
Die probleem het voortgespruit uit verskeie vlakke van toestelbeheer wat gelyktydig toegepas is.
Die aangepaste beginprogramma het bepaal welke toepassing as die Tuis-skerms verskyn het, terwyl Toestel-eienaar die toepassing baie wyer beheer oor toestelbeleid gegee het. Android se dokumentasie vir toegewyde toestelle ondersteun hierdie tipe konfigurasie vir kiosk- en bestuurde-toestel-instellings, insluitend die beheer van die verstek Tuis-toepassing en die beperking van toegang tot stelselfunksies.
Die ADB-bevele het 'n verdere vlak bygevoeg deur die gedrag van die stelsel-UI te verander. Hierdie spesifieke instellings is afhanklik van die toestel of firmeware eerder as universele Android-API's, dus hang hul presiese effek af van hoe die tablet-firmeware dit implementeer.
Dit beteken dat 'n Android-tablet wat as 'n kiosk-toestel gebruik word moeilik kan raak om te herstel wanneer die beginprogramma, Toestel-eienaar-konfigurasie, stelsel-UI-beperkings en toepassingsnavigasie almal gelyktydig verander word.
Die feit dat die toepassing se Instellings- of Wi-Fi-knoppie nie meer werk nie, beteken nie noodwendig dat die Intent self verkeerd is nie. Die teikeninstellingsaktiwiteit kan onbeskikbaar, beperk of op ander maniere ontoeganklik wees onder die huidige toestelkonfigurasie nie. Android stel ook voor dat jy kyk of 'n Intent opgelos kan word voordat jy probeer om dit te begin.
Herstelpaaie vir 'n Gelasde Android-Kiosk-tablet
As die toepassing reeds as Toestel-eienaar gekonfigureer is, moet sagteware-gebaseerde herstel eerstens oorweeg word.
Android se DevicePolicyManager verskaf toestel-bestuurfunksies wat deur 'n Toestel-eienaar gebruik kan word. Afhangende van die Android-weergawe en die toepassing se konfigurasie, kan 'n Toestel-eienaar-toepassing die gepaste toestelveegmeganismes gebruik om die tablet na 'n skoon toestand vir toetsing terug te keer. wipeData() is die gevestigde API vir die veeg van gebruikersdata, terwyl nuwer Android-weergawes addisionele toestel-veegfunksionaliteit verskaf.
Die verouderde clearDeviceOwnerApp() die metode moet nie as 'n algemene produksieherstelmetode behandel word nie. Android dokumenteer dit as 'n toetsgerigte API en beveel 'n fabriekherstel as die normale manier om 'n Toestel-eienaarverhouding te verwyder.
ADB verskaf ook toestelbeleid-bestuurbevele, maar hierdie het beperkings. Byvoorbeeld, adb shell dpm remove-active-admin is nie 'n universele metode vir die verwydering van 'n Toestel-eienaar nie; Android se ADB-dokumentasie spesifiseer vereistes soos die toepassing se testOnly verklaring.
Indien sagtewareherstel nie beskikbaar is nie omdat die toepassing nie die vereiste bewerking kan uitvoer nie, bly die volgende opsie 'n hardewarefabriekherstel of Android-herstelprosedure .
Die presiese knoppie-kombinasie moet nie van 'n ander Android-tabletmodel aanvaar word nie. Herstelgedrag word bepaal deur die tablet se firmware en hardeware-implementering. Vir 'n aangepaste Android-tabletprojek moet die gepaste herstelprosedure dus vir die werklike model en firmware bevestig word voor implementering.
Vir hierdie tipe Android-kiosk-tablet , het 'n gedefinieerde herstelmetode veral nuttig tydens integrasietoetsing omdat stelselvlak-konfigurasie doelbewus normale gebruikersnavigasie kan verwyder.
Toetsing van Instellingsdoeleindes en Stelselfunksies op 'n Android-tablet
Die kliënt se tweede vraag was of die toepassing stelselfunksies soos Instellings en Wi-Fi direk kon begin.
Android verskaf standaardinstellingsaksies vir hierdie funksies. Byvoorbeeld:
|
Funksie |
Standaard Android-doel |
|
Hoofinstellings |
Settings.ACTION_SETTINGS |
|
Wi-Fi-instellings |
Settings.ACTION_WIFI_SETTINGS |
|
Draadlose instellings |
Settings.ACTION_WIRELESS_SETTINGS |
|
Bluetooth-instellings |
Settings.ACTION_BLUETOOTH_SETTINGS |
|
Vertooninstellings |
Settings.ACTION_DISPLAY_SETTINGS |
|
Ligging-instellings |
Settings.ACTION_LOCATION_SOURCE_SETTINGS |
|
Klank-instellings |
Settings.ACTION_SOUND_SETTINGS |
|
Sekuriteit-instellings |
Settings.ACTION_SECURITY_SETTINGS |
|
Toepassinginstellings |
Instellings.ACTION_APPLICATION_SETTINGS |
|
Spesifieke Toepassinginstellings |
Instellings.ACTION_APPLICATION_DETAILS_SETTINGS |
Hierdie is standaard Android-instellingsaksies eerder as koppelvlakke wat spesifiek is vir 'n bepaalde Android-tabletvervaardiger . Die bestaan van 'n Intent verseker egter nie dat dit suksesvol op elke toestel of onder elke kiosk-konfigurasie sal oopgaan nie. Android beveel aan dat die Intent met resolveActivity() gekontroleer word voordat dit gestart word.
Vir 'n stelsel-geïntegreerde Android-tablet moet Intent-toetsing dus op die werklike firmware en Android-weergawe wat vir implementering gebruik word, uitgevoer word. Die toets moet nie net verifieer dat die Intent bestaan nie, maar ook dat die ooreenstemmende Aktiwiteit na toepassing van App-eienaar-, beginprogram- en stelsel-UI-beperkings bereik kan word.
As u op ’n Android-kiosk-tablet of stelselintegrasieprojek werk en hulp benodig met Toestel-eienaarherstel, Instellingsbedoelings (Settings Intents) of verwante konfigurasieprobleme, kontak asseblief ons met u tabletmodel en Android-weergawe. Ons kan die beskikbare tegniese ondersteuning en aanpassingsopsies bespreek.
Dieselfde beginsel geld vir ander stelselfunksies. ’n Standaard-Android-API mag bestaan, terwyl die werklike gedrag van ’n aangepaste tablet afhang van sy Android-weergawe, firmwarekonfigurasie en toestelbestuurbeleid.
Wat van Ontwaakversoeke?
Die kliënt se vraag oor „ontwaakversoeke“ verskil effens van die opening van ’n Instellingsbladsy.
Intent.ACTION_SCREEN_ON vertegenwoordig ’n stelseluitsending wat aandui dat die skerm nou interaktief geword het. Dit is ’n beskermde stelseluitsending, dus moet ’n toepassing dit nie as ’n gewone Bedoeling (Intent) behandel wat dit net kan stuur om die tablet te ontwaak nie.
Indien die vereiste is om die skerm te ontwaak, die skerm wakker te hou of skerm-aan-gedrag te beheer , die toepaslike meganisme hang af van die presiese toepassingsvereiste. Android verskaf kragbestuur- en venster/aktiwiteit-API's vir hierdie gevalle, insluitend PowerManager en waaksluit-funksionaliteit waar toepaslik.
Hierdie verskil is belangrik wanneer toepassings vir ’n Android-kiosk-tablet ontwikkel word. „Laai ’n stelselfunksie op“ en „beheer die toestel se kragtoestand“ is verskillende stelseloperasies en moet deur verskillende API's hanteer word.
Tegniese ondersteuning vir Android-tablet-integrasie
Hierdie geval wys ook hoekom kiosk-deployment meer as net die basiese hardewarekonfigurasie van ’n Android-tablet kan vereis.
Wanneer ’n tablet in ’n toegewyde toepassing, POS-stelsel, kiosk, industriële stelsel of ander bestuurde toestel geïntegreer word, kan die sagtewarekonfigurasie gelyktydig die beginprogram, Toestel-eienaar, stelsel-UI, toepassingsregtelikheid, Instellings-intents en herstelgedrag behels.
Vir projekte wat aangepaste Android-tablette konfigurasies, moet hierdie vereistes saam met die hardeware- en Android-stelselkonfigurasie geëvalueer word eerder as om dit as afsonderlike probleme tydens die finale toetsing te behandel.
Die gepaste oplossing hang af van die Android-weergawe, tablet-firmware, toepassingskonfigurasie en die funksies wat die stelsel-integrasie-verdeler moet beheer. Tegniese dokumentasie kan ook rondom die beskikbare stelselkoppelpunte, ondersteunde Intents, toestemmings en toestel-spesifieke beperkings voorberei word.
As u 'n Android tablet vir kiosk-deployment of stelsel-integrasie toets en soortgelyke probleme ondervind met Toestel-eienaar, pasgemaakte beginprogramme, kiosk-modus, Instellings-Intents, stelsel-UI-beperkings of toestelherstel , tuis neem kontak met ons op vir tegniese ondersteuning .
U kan u tablet-model, Android-weergawe, deployment-konfigurasie en die spesifieke funksie wat u wil implementeer, verskaf. Ons kan dan bespreek watter Android-tablet-aanpassing en tegniese ondersteuning opsies vir u projek.