Paghahanda ng Android Kiosk: Ano ang Dapat Gawin Kapag Pinagkaitan Ka ng Device Owner sa Settings

Isang 10.1-pulgadang Android tablet ay na-configure para sa kiosk gamit ang ADB, isang pasadyang launcher at Device Owner. Pagkatapos ng reboot, ang aplikasyon ay nagsimulang tumakbo tulad ng inaasahan, ngunit ang device ay hindi na makakapasok sa karaniwang Android Settings interface.

Ito ay nagdulot ng karaniwang hamon sa kiosk deployment: kapag ang system navigation at device-management controls ay na-restrict na, paano ma-recover ang tablet para sa karagdagang pagsusuri? At kung ang aplikasyon ay kailangang buksan ang Wi-Fi o iba pang system functions, alin sa mga Android Intents ang maaari pa ring gamitin?

Una, ginamit ng customer ang mga ADB command para baguhin ang system UI behavior:

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

Ang aplikasyon ay itinakda bilang default na Home screen, kasunod ng pag-configure ng aplikasyon bilang Device Owner upang paganahin ang mga kinakailangang pagpapatakbo ng device.

Pagkatapos ng reboot, ang Android kiosk tablet ay pumasok nang awtomatiko sa aplikasyon ayon sa inaasahan. Gayunpaman, hindi na makakalabas ang customer sa pangunahing screen ng aplikasyon upang ma-access ang Android Settings o iba pang mga system function. Ang mga button para sa Settings at Wi-Fi na nakaimplimenta sa loob ng aplikasyon ay tumigil din sa pagbukas ng kaukulang system pages.

Ang agad na tanong ay hindi lamang kung paano lumabas sa aplikasyon. Kailangan ng customer ng isang maaasahang paraan upang ma-recover ang Android tablet para sa karagdagang pagsusuri at nais ding maintindihan kung aling system Intents ang maaaring gamitin ng kanilang aplikasyon.

Bakit Naging Mahirap Ma-access ang Android Tablet

Ang problema ay nagmula sa ilang antas ng device control na ipinapatupad nang sabay-sabay.

Ang pasadyang launcher ang nagsasabi kung aling aplikasyon ang lalabas bilang Home screen, samantalang ang Device Owner ay nagbigay ng mas malawak na kontrol sa aplikasyon sa patakaran ng device. Ang dokumentasyon ng Android para sa dedikadong device ay sumusuporta sa ganitong uri ng pag-configure para sa mga kiosk at managed-device deployment, kabilang ang pagkontrol sa default na Home application at paglilimita sa access sa mga system function.

Ang mga utos ng ADB ay nagdagdag ng isa pang layer sa pamamagitan ng pagbabago sa pag-uugali ng system UI. Ang mga partikular na setting na ito ay nakasalalay sa device o firmware, hindi sa universal na Android API, kaya ang eksaktong epekto nito ay nakasalalay sa paraan kung paano ipinatutupad ng firmware ng tablet ang mga ito.

Ito ay nangangahulugan na isang Android tablet na ginagamit bilang kiosk device maaaring maging mahirap i-recover kapag ang launcher, Device Owner configuration, mga restriksyon sa system UI, at navigation ng aplikasyon ay lahat na binago nang sabay-sabay.

Ang katotohanan na ang mga Pagsasaayos o ang pindutan ng Wi-Fi ng aplikasyon ay hindi na gumagana ay hindi nangangahulugan kailangan na na mali ang Intent mismo. Maaaring hindi magagamit, limitado, o hindi ma-access sa kasalukuyang konpigurasyon ng device ang target na Settings Activity. Inirerekomenda rin ng Android na suriin kung ang isang Intent ay maaaring i-resolve bago subukang i-launch ito.

Mga Alternatibong Paraan para sa Nakakandadong Android Kiosk Tablet

Kung ang aplikasyon ay nakakonpigurang Device Owner na, dapat unang isaalang-alang ang software-based na pagbawi.

Android's DevicePolicyManager ay nagbibigay ng mga function sa pamamahala ng device na maaaring gamitin ng isang Device Owner. Depende sa bersyon ng Android at sa konpigurasyon ng aplikasyon, ang isang Device Owner application ay maaaring gamitin ang angkop na mekanismo ng device wipe upang ibalik ang tablet sa malinis na estado para sa pagsusuri. wipeData() ay ang itinatag na API para sa pag-wipe ng user data, samantalang ang mga bagong bersyon ng Android ay nagbibigay ng karagdagang functionality para sa device wipe.

Ang lumang clearDeviceOwnerApp() ang paraan ay hindi dapat ituring na pangkalahatang pamamaraan para sa pagbawi ng produksyon. Ipinapaliwanag ng dokumentasyon ng Android na ito ay isang API na nakatuon sa pagsusulit at inirerekomenda ang factory reset bilang karaniwang paraan upang alisin ang relasyon ng Device Owner.

Ang ADB ay nagbibigay din ng mga utos para sa pamamahala ng device-policy, ngunit may mga restriksyon ang mga ito. Halimbawa, adb shell dpm remove-active-admin ay hindi isang pangkalahatang paraan para alisin ang Device Owner; tinutukoy ng dokumentasyon ng Android ADB ang mga kinakailangan tulad ng testOnly na deklarasyon ng aplikasyon.

Kung ang pagbawi ng software ay hindi magagamit dahil hindi maisasagawa ng aplikasyon ang kailangang operasyon, ang natitirang daan ay ang hardware factory reset o proseso ng Android Recovery .

Hindi dapat ipagpalagay ang eksaktong kombinasyon ng mga pindutan mula sa ibang modelo ng tablet na Android. Ang pag-uugali ng recovery ay nakasalalay sa firmware at implementasyon ng hardware ng tablet. Kaya para sa isang proyektong customized na tablet na Android, dapat kumpirmahin ang angkop na proseso ng recovery para sa aktwal na modelo at firmware bago ang deployment.

Para sa uri ng Android kiosk tablet , ang pagkakaroon ng isang tinukoy na paraan ng pagbawi ay lalo pang kapaki-pakinabang sa panahon ng pagsusuri ng integrasyon dahil ang konpigurasyon sa antas ng sistema ay maaaring sinadyang tanggalin ang karaniwang nabigasyon ng gumagamit.

Pagsusuri ng mga Intents ng Mga Setting at mga Pampasystem na Function sa isang Android Tablet

Ang ikalawang tanong ng customer ay kung ang aplikasyon ay maaaring direktang buksan ang mga pampasystem na function tulad ng Settings at Wi-Fi.

Ang Android ay nagbibigay ng mga pamantayang aksyon para sa Settings para sa mga function na ito. Halimbawa:

Tungkulin	Pamantayang Android Intent
Pangunahing Settings	Settings.ACTION_SETTINGS
Mga Setting ng Wi-Fi	Settings.ACTION_WIFI_SETTINGS
Mga setting ng wireless	Settings.ACTION_WIRELESS_SETTINGS
Mga Kaganapan ng Bluetooth	Settings.ACTION_BLUETOOTH_SETTINGS
Mga Setting ng Display	Settings.ACTION_DISPLAY_SETTINGS
Mga Kaganapan ng Lokasyon	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Mga Kaganapan ng Tunog	Settings.ACTION_SOUND_SETTINGS
Mga Kaganapan ng Seguridad	Settings.ACTION_SECURITY_SETTINGS
Mga Kaganapan ng Aplikasyon	Settings.ACTION_APPLICATION_SETTINGS
Mga Setting ng Tiyanay na App	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Ang mga ito ay karaniwang mga aksyon ng Android Settings, hindi mga interface na partikular sa isang Tagagawa ng Android tablet . Gayunpaman, ang pagkakaroon ng isang Intent ay hindi nangangahulugan na bukas ito nang matagumpay sa bawat device o sa anumang kiosk configuration. Inirerekomenda ng Android na suriin ang Intent gamit ang resolveActivity() bago ito ipaandar.

Para sa isang system-integrated na Android tablet, dapat gawin ang pagsubok ng Intent sa aktwal na firmware at bersyon ng Android na gagamitin para sa deployment. Dapat suriin ng pagsusubok hindi lamang kung umiiral ang Intent, kundi pati na rin kung ang katumbas na Activity ay maabot pagkatapos ilagay ang Device Owner, launcher, at mga restriksyon sa system UI.

Kung ikaw ay gumagawa ng isang Android kiosk tablet o system integration project at kailangan mo ng tulong sa Device Owner recovery, Settings Intents, o iba pang kaugnay na configuration issues, mangyaring makipag-ugnayan sa amin kasama ang modelo ng iyong tablet at bersyon ng Android. Puwede naming talakayin ang mga available na technical support at customization options.

 

Ang parehong prinsipyo ay nalalapat sa iba pang system functions. Maaaring umiiral ang isang standard Android API, ngunit ang aktwal na pag-uugali ng isang customized tablet ay nakasalalay sa kanyang bersyon ng Android, firmware configuration, at device-management policies.

Ano ang Tungkol sa Wake Requests?

Ang tanong ng customer tungkol sa “wake requests” ay bahagyang iba sa pagpapagana ng isang Settings page.

Intent.ACTION_SCREEN_ON ay kumakatawan sa isang system broadcast na nagpapahiwatig na ang screen ay naging interactive na. Ito ay isang protektadong system broadcast, kaya hindi dapat ituring ng isang application na ito ay isang karaniwang Intent na maaari nitong simpleng i-send upang gisingin ang tablet.

Kung ang kinakailangan ay gisingin ang screen, panatilihin ang screen na gising, o kontrolin ang screen-on behavior , ang angkop na mekanismo ay nakasalalay sa tiyak na kailangan ng aplikasyon. Ang Android ay nagbibigay ng mga power-management at window/activity API para sa mga ganitong sitwasyon, kabilang ang PowerManager at wake-lock functionality kung kinakailangan.

Mahalaga ang pagkakaiba nito kapag nagpapaunlad ng mga aplikasyon para sa isang Android kiosk tablet . Ang "Pagsimulan ang isang system function" at "kontrolin ang estado ng kuryente ng device" ay magkaibang operasyon ng sistema at dapat pangasiwaan gamit ang magkaibang API.

Suportang Teknikal para sa Pagsasama ng Android Tablet

Nagpapakita rin ang kaso na ito kung bakit maaaring mangailangan ang kiosk deployment ng higit pa sa pangunahing hardware configuration ng isang Android tablet.

Kapag isinasama ang isang tablet sa isang nakatuon na aplikasyon, POS system, kiosk, industrial system o iba pang managed device, maaaring kasali sa software configuration ang launcher, Device Owner, system UI, application permissions, Settings Intents, at recovery behavior nang sabay-sabay.

Para sa mga proyekto na nangangailangan ng customized Android tablet mga konpigurasyon, ang mga kinakailangang ito ay dapat pagsusuriin kasama ang hardware at konpigurasyon ng Android system imbes na tratuhin bilang magkahiwalay na isyu sa panahon ng huling pagsubok.

Ang angkop na solusyon ay nakasalalay sa bersyon ng Android, firmware ng tablet, konpigurasyon ng aplikasyon, at mga function na kailangan kontrolin ng system integrator. Maaari ring ihanda ang teknikal na dokumentasyon batay sa mga available na system interface, suportadong Intents, permissions, at mga limitasyon na partikular sa device.

Kung sinusubukan mo ang isang Android tablet para sa kiosk deployment o system integration at nakakaranas ng katulad na mga isyu sa Device Owner, custom launchers, kiosk mode, Settings Intents, mga restriksyon sa system UI, o device recovery , mangyaring makipag-ugnayan sa Amin para sa teknikal na suporta .

Maaari mong ibigay ang modelo ng iyong tablet, bersyon ng Android, deployment configuration, at ang tiyak na function na sinusubukang i-implement. Pagkatapos ay maaari nating talakayin ang mga available na Android tablet customization at teknikal na suporta mga opsyon para sa iyong proyekto.