Android-kioskin asennus: Mitä tehdä, kun laitteen omistaja lukitsee sinut pois asetuksista

A10,1 tuuman Android-tabletti oli määritetty kioskitarkoituksiin ADB:n, mukautetun käynnistimen ja laitteen omistajan avulla. Uudelleenkäynnistyksen jälkeen sovellus käynnistyi odotetusti, mutta laite ei enää päässyt normaaliin Android-asetusliittymään.

Tämä aiheutti yleisen haasteen kioskien käyttöönotossa: kun järjestelmän navigointi ja laitteen hallintatoiminnot on rajoitettu, miten tabletin voi palauttaa lisätestaukseen? Ja jos sovelluksen täytyy avata Wi-Fi tai muita järjestelmätoimintoja, mitkä Android-intentit voidaan edelleen käyttää?

Asiakas käytti ensin ADB-komentoja järjestelmän käyttöliittymän toiminnan muuttamiseen:

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

Sovellus asetettiin oletus-kotinäytöksi, jonka jälkeen sovellus määritettiin Device Owner mahdollistaa vaaditut laitteen hallintatoiminnot.

Käynnistämisen jälkeen Android-kioskitabletti siirtyi automaattisesti sovellukseen odotetusti. Asiakas ei kuitenkaan enää voinut poistua sovelluksen pääruudulta päästäkseen Android-asetuksiin tai muihin järjestelmätoimintoihin. Sovellukseen rakennetut Asetukset- ja Wi-Fi-painikkeet eivät myöskään enää avanneet vastaavia järjestelmäsivuja.

Välitön kysymys ei ollut pelkästään, miten poistua sovelluksesta. Asiakkaan tarve oli luotettava tapa palauttaa Android-tabletti lisätestaukseen ja hän halusi myös ymmärtää, mitä järjestelmä-Intentejä hänen sovelluksensa voisi käyttää.

Miksi Android-tabletista tuli vaikeasti käytettävä

Ongelma johtui useista laitteen ohjaustasoista, jotka oli otettu käyttöön samanaikaisesti.

Mukautettu käynnistin määritteli, mikä sovellus näkyi kotoruutuna, kun taas laitteen omistaja antoi sovellukselle paljon laajemman hallintavallan laitteen käytäntöihin. Androidin erityislaiteasiakirjat tukevat tätä konfiguraatiotyyppiä kioski- ja hallittujen laitteiden käyttöön, mukaan lukien oletuskotosovelluksen ohjaaminen ja pääsyn rajoittaminen järjestelmätoimintoihin.

ADB-komennot lisäsivät toisen kerroksen muuttamalla järjestelmän käyttöliittymän käyttäytymistä. Nämä erityiset asetukset riippuvat laitteesta tai firmwaresta eikä niitä ole yleisiä Androidin API:ta, joten niiden tarkka vaikutus riippuu siitä, kuinka tabletin firmware toteuttaa ne.

Tämä tarkoittaa, että Android-tabletti, jota käytetään kioskilaitteena voi vaikeutua palauttaa, kun käynnistin, laitteen omistajan asetukset, järjestelmän käyttöliittymän rajoitukset ja sovelluksen navigointi muutetaan kaikki yhtä aikaa.

Sovelluksen Asetukset- tai Wi-Fi-painikkeen toimimattomuus ei välttämättä tarkoita, että Intent on itse asiassa virheellinen. Kohdeasetusten toiminto saattaa olla käytettävissä vain rajoitetusti tai muuten saavuttamattomissa nykyisen laitteen määrittelyn alla. Android suosittelee myös tarkistamaan, voidaanko Intent ratkaista ennen sen käynnistämistä.

Palautuspolut lukitulle Android-kioskitabletille

Jos sovellus on jo määritetty laitelomistajaksi, ohjelmallisesta palautuksesta tulisi harkita ensisijaisesti.

Androidin DevicePolicyManager tarjoaa laitehallintafunktiot, joita laitelomistaja voi käyttää. Android-version ja sovelluksen määrittelyn mukaan laitelomistajasovellus voi käyttää sopivaa laitteen tyhjennysmekanismia palauttaakseen tabletin puhtaaseen tilaan testaukseen. wipeData() on vakiintunut API käyttäjän tietojen tyhjentämiseen, kun taas uudemmat Android-versiot tarjoavat lisäominaisuuksia laitteen tyhjentämiseen.

Vanhentunut clearDeviceOwnerApp() menetelmää ei tulisi käsitellä yleisen tuotantopalautusmenetelmänä. Android dokumentoi sen testaukseen suunnattuna API:nä ja suosittelee tehdasasetusten palautusta normaalina tavoin poistaa Device Owner -suhteesta.

ADB tarjoaa myös laiteluokkien hallintakomentoja, mutta niillä on rajoituksia. Esimerkiksi adb shell dpm remove-active-admin ei ole yleinen menetelmä Device Ownerin poistamiseen; Androidin ADB-dokumentaatio määrittelee vaatimuksia, kuten sovelluksen testOnly ilmoituksen.

Jos ohjelmistopohjainen palautus ei ole saatavilla, koska sovellus ei pysty suorittamaan vaadittua toimintoa, jäljelle jää laitteellinen tehdasasetusten palautus tai Android Recovery -menettely .

Tarkka painonappiyhdistelmä ei saa olettaa toiselta Android-tauluttimelta. Palautustoiminnon käyttäytyminen määräytyy tauluttimen firmwaren ja laitteiston toteutuksen perusteella. Mukautetussa Android-tauluttimen projektissa asianmukainen palautusmenettely on siksi vahvistettava todelliselle mallille ja firmwarelle ennen käyttöönottoa.

Tällaisen tyypin Android-kioskitabletti , määritelty palautusmenetelmä on erityisen hyödyllinen integraatiotestaamisessa, koska järjestelmätasoiset asetukset voivat tarkoituksellisesti poistaa normaalin käyttäjän navigoinnin.

Asetusten tarkoituksien ja järjestelmätoimintojen testaaminen Android-taulutietokoneella

Asiakkaan toinen kysymys oli, voisiko sovellus käynnistää suoraan järjestelmätoimintoja, kuten Asetukset ja Wi-Fi.

Android tarjoaa näille toiminnoille standardiset asetusten toiminnot. Esimerkiksi:

Toiminto	Standardi Android-intentti
Pääasetukset	Settings.ACTION_SETTINGS
Wi-Fi-asetukset	Settings.ACTION_WIFI_SETTINGS
Tilakokoonpano	Settings.ACTION_WIRELESS_SETTINGS
Bluetooth-asetukset	Settings.ACTION_BLUETOOTH_SETTINGS
Näytön asetukset	Settings.ACTION_DISPLAY_SETTINGS
Sijaintiasetukset	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Ääniasetukset	Settings.ACTION_SOUND_SETTINGS
Turvallisuusasetukset	Settings.ACTION_SECURITY_SETTINGS
Sovellusasetukset	Settings.ACTION_APPLICATION_SETTINGS
Tietyn sovelluksen asetukset	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Nämä ovat standardi-Android-asetustoimintoja eivätkä ole tietyn Android-tabletin valmistajan erityisiä käyttöliittymiä . Kuitenkin Intentin olemassaolo ei takaa, että se avautuisi onnistuneesti kaikilla laitteilla tai kaikissa kioskitilanteissa. Android suosittelee tarkistettavan Intentia metodilla resolveActivity() ennen sen käynnistämistä.

Järjestelmään integroidun Android-tabletin tapauksessa Intent-testaus tulisi suorittaa todellisella käytössä olevalla firmwarella ja Android-versiolla. Testin tulee varmistaa paitsi Intentin olemassaolo myös vastaavan Activityn saavutettavuus laitteen omistajan, käynnistimen ja järjestelmän käyttöliittymän rajoitusten soveltamisen jälkeen.

Jos työskentelet Android-kioskitabletilla tai järjestelmäintegraatioprojektissa ja tarvitset apua laitteen omistajan palauttamiseen, asetusten tarkoituksiin (Settings Intents) tai niihin liittyviin määrittelyongelmiin, ota meihin yhteyttä ilmoittaen tabletin malli ja Android-versio. Voimme keskustella saatavilla olevista teknisistä tukipalveluista ja mukautusvaihtoehdoista.

 

Sama periaate koskee muita järjestelmätoimintoja. Standardi Android-rajapinta voi olla olemassa, mutta muokatun tabletin todellinen toiminta riippuu sen Android-versiosta, firmware-määrittelystä ja laitehallintakäytännöistä.

Entä herätyspyynnöt?

Asiakkaan kysymys ”herätyspyynnöistä” eroaa hieman asetussivun avaamisesta.

Intent.ACTION_SCREEN_ON edustaa järjestelmän laajennettua ilmoitusta (broadcast), joka kertoo, että näyttö on tullut interaktiiviseksi. Kyseessä on suojattu järjestelmän laajennettu ilmoitus, joten sovelluksen ei pitäisi käsitellä sitä tavallisena tarkoituksena (Intent), jonka se voisi yksinkertaisesti lähettää tabletin herättämiseksi.

Jos vaatimus on herättää näyttö, pitää näyttö valmiina tai hallita näytön päälle-oloa , sopiva mekanismi riippuu tarkasta käyttötapaustarpeesta. Android tarjoaa virranhallinta- ja ikkuna/toiminto-ohjelmointirajapintoja näihin tilanteisiin, mukaan lukien PowerManager ja tarvittaessa herätyslukitus-toiminnallisuuden.

Tämä ero on tärkeä kehitettäessä sovelluksia Android-kioskitabletti -laitteelle. "Käynnistä järjestelmätoiminto" ja "hallitse laitteen virran tilaa" ovat eri järjestelmätoimintoja, ja niitä tulee käsitellä eri ohjelmointirajapintojen kautta.

Tekninen tuki Android-tablettien integrointiin

Tämä tapaus osoittaa myös, miksi kioskitoteutus voi vaatia enemmän kuin peruslaitekonfiguraation Android-tabletissa.

Kun tablet-laitetta integroidaan erityissovellukseen, maksupistejärjestelmään (POS), kioskiin, teollisuusjärjestelmään tai muuhun hallittuun laitteeseen, ohjelmistokonfiguraatio voi sisältää samanaikaisesti käynnistimen, laitteen omistajan (Device Owner), järjestelmän käyttöliittymän, sovellusoikeudet, asetusten ohjelmointirajapinnat (Settings Intents) ja palautustoiminnallisuuden.

Projekteihin, joissa vaaditaan mukautettu Android-tabletti konfiguraatiot, nämä vaatimukset tulisi arvioida yhdessä laitteiston ja Android-järjestelmän konfiguraation kanssa eikä käsitellä erillisinä ongelmina lopullisessa testauksessa.

Sopiva ratkaisu riippuu Android-versiosta, tabletin firmwaresta, sovelluksen konfiguraatiosta ja siitä, mitkä toiminnot järjestelmäintegroijan on ohjattava. Tekninen dokumentaatio voidaan myös laatia saatavilla olevien järjestelmärajapintojen, tuettujen Intent-objektien, käyttöoikeuksien ja laitekohtaisten rajoitusten perusteella.

Jos testaat Android-tabletti kioskitoteutukseen tai järjestelmäintegrointiin ja kohtaat samankaltaisia ongelmia Laitteen omistajana, mukautettuina käynnistysohjelmina, kiosk-tilassa, asetusten Intent-objekteilla, järjestelmän käyttöliittymän rajoituksilla tai laitteen palautustoiminnoilla , kiitos ota meihin yhteyttä tekniikkatukea varten .

Voit antaa tabletin mallin, Android-version, käyttöönoton konfiguraation ja tarkemmin sen toiminnon, jonka yrität toteuttaa. Tämän jälkeen voimme keskustella saatavilla olevista Android-tablettien mukauttamisesta ja teknisestä tuesta vaihtoehtoihin projektiasi varten.