Настройка на Android киоск: Какво да направите, когато собственикът на устройството ви блокира достъпа до настройките
A10,1-инчов андроид таблет беше конфигуриран за употреба в киоск чрез ADB, персонализиран стартер и собственик на устройството. След рестартиране приложението се стартира както се очакваше, но устройството вече не можеше да достъпва нормалния интерфейс на Android Настройки.
Това създаде обичайна предизвикателство при разполагане на киоск: след като навигацията в системата и контролите за управление на устройството са ограничени, как може таблетът да бъде възстановен за по-нататъшно тестване? И ако приложението има нужда да отвори Wi-Fi или други системни функции, кои Android Intent-и все още могат да се използват?
Клиентът първо използва команди ADB за промяна на поведението на потребителския интерфейс на системата:
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
След това приложението беше зададено като подразбиращ се начален екран, а след това беше конфигурирано като Собственик на устройството за активиране на необходимите функции за управление на устройството.
След рестартиране Android киоск таблет автоматично влезе в приложението, както се очакваше. Обаче клиентът вече не можеше да напусне главния екран на приложението, за да получи достъп до Android настройки или други системни функции. Бутоните за настройки и Wi-Fi, вградени в приложението, също престанаха да отварят съответните системни страници.
Незабавният въпрос не беше просто как да излезем от приложението. Клиентът имаше нужда от надежден начин да възстанови Таблет с Android за допълнително тестване и също искаше да разбере кои системни намерения (Intents) могат да се използват от неговото приложение.
Защо Android таблетът стана труден за достъп
Проблемът възникна поради прилагането едновременно на няколко слоя контрол върху устройството.
Потребителският стартер определяше кое приложение се появява като начален екран, докато притежателят на устройството предоставяше на приложението много по-широк контрол върху политиката за устройството. Документацията на Android за специализирани устройства поддържа този тип конфигурация за развертания на киоскови и управляеми устройства, включително контрол върху подразбиращото се начално приложение и ограничаване на достъпа до системни функции.
Командите ADB добавяха още един слой, като променяха поведението на системния потребителски интерфейс. Тези конкретни настройки зависят от устройството или фърмуера, а не от универсалните API на Android, така че техният точен ефект зависи от начина, по който фърмуерът на таблета ги реализира.
Това означава, че един Android таблет, използван като киосково устройство може да стане труден за възстановяване, когато стартерът, конфигурацията на притежателя на устройството, ограниченията върху системния потребителски интерфейс и навигацията в приложението се променят едновременно.
Фактът, че бутонът „Настройки“ или бутонът за Wi-Fi в приложението вече не работи, не означава задължително, че самият Intent е неправилен. Целевата дейност (Activity) „Настройки“ може да е недостъпна, ограничена или по друг начин недостъпна при текущата конфигурация на устройството. Android също препоръчва да се провери дали Intent може да бъде разрешен, преди да се опитате да го стартирате.

Възстановяване на заключен таблет за Android-киоск
Ако приложението вече е конфигурирано като собственик на устройството (Device Owner), първо трябва да се разгледа софтуерното възстановяване.
Android DevicePolicyManager предоставя функции за управление на устройството, които могат да се използват от собственик на устройството (Device Owner). В зависимост от версията на Android и конфигурацията на приложението, приложението, което е собственик на устройството, може да използва подходящия механизъм за изтриване на устройството, за да върне таблета в чисто състояние за тестване. wipeData() е установеният API за изтриване на потребителски данни, докато по-новите версии на Android предоставят допълнителни възможности за изтриване на устройството.
Застарелият clearDeviceOwnerApp() методът не трябва да се счита за обща методика за възстановяване на производствения процес. В документацията на Android той е описан като API, предназначен за тестване, и се препоръчва извършването на фабричен ресет като нормален начин за премахване на връзката Device Owner.
ADB освен това предоставя команди за управление на политики за устройства, но те имат ограничения. Например: adb shell dpm remove-active-admin не е универсален метод за премахване на Device Owner; в документацията на Android за ADB са посочени изисквания, като например декларацията за приложението testOnly .
Ако софтуерното възстановяване е недостъпно, защото приложението не може да изпълни необходимата операция, оставащият вариант е хардуерен фабричен ресет или процедура за възстановяване на Android .
Точната комбинация от бутони не трябва да се предполага въз основа на друга моделна версия на Android планшет. Поведението при възстановяване се определя от прошивката и хардуерната реализация на планшета. Следователно, за проект с персонализиран Android планшет трябва да се потвърди подходящата процедура за възстановяване за конкретния модел и прошивка преди разграждане.
За този тип Android киоск таблет , като има дефиниран метод за възстановяване, е особено полезно по време на интеграционно тестване, тъй като конфигурацията на системно ниво може нарочно да премахне нормалната навигация за потребителите.
Тестване на намеренията за настройки и системни функции на Android таблет
Вторият въпрос на клиента беше дали приложението може директно да стартира системни функции като Настройки и Wi-Fi.
Android предоставя стандартни действия за настройки за тези функции. Например:
|
Функция |
Стандартно Android намерение |
|
Основни настройки |
Settings.ACTION_SETTINGS |
|
Настройки за Wi-Fi |
Settings.ACTION_WIFI_SETTINGS |
|
Безжични настройки |
Настройки.ACTION_WIRELESS_SETTINGS |
|
Настройки на Bluetooth |
Настройки.ACTION_BLUETOOTH_SETTINGS |
|
Настройки на дисплея |
Настройки.ACTION_DISPLAY_SETTINGS |
|
Настройки за местоположение |
Настройки.ACTION_LOCATION_SOURCE_SETTINGS |
|
Настройки на звука |
Настройки.ACTION_SOUND_SETTINGS |
|
Настройки за сигурност |
Настройки.ACTION_SECURITY_SETTINGS |
|
Настройки на приложението |
Настройки.ACTION_APPLICATION_SETTINGS |
|
Специфични настройки за приложението |
Настройки.ACTION_APPLICATION_DETAILS_SETTINGS |
Това са стандартни действия за настройки на Android, а не интерфейси, специфични за даден Производител на таблети с Android . Въпреки това наличието на Intent не гарантира, че той ще се отвори успешно на всяко устройство или при всяка конфигурация на киоск. Android препоръчва да се провери Intent с помощта на resolveActivity() преди да бъде стартиран.
За системно интегриран таблет с Android тестовете за Intent следователно трябва да се извършват върху действителната прошивка и версия на Android, използвани за разграждане. Тестът трябва да потвърди не само дали Intent съществува, но и дали съответната Activity може да бъде достигната след прилагане на ограниченията за собственик на устройството, стартера и системния потребителски интерфейс.
Ако работите върху проект за Android киоскова таблетка или системна интеграция и имате нужда от помощ при възстановяване на Device Owner, Settings Intents или свързани конфигурационни проблеми, моля, свържете се с нас, като посочите модела на таблетката и версията на Android. Можем да обсъдим наличната техническа поддръжка и възможностите за персонализация.
Същият принцип се отнася и за други системни функции. Стандартен Android API може да съществува, докато реалното поведение на персонализирана таблетка зависи от нейната версия на Android, конфигурация на фърмуера и политики за управление на устройството.
А какво е с заявките за събуждане?
Въпросът на клиента относно „заявките за събуждане“ малко се различава от стартирането на страница Settings.
Intent.ACTION_SCREEN_ON представлява системно предаване (broadcast), което показва, че екранът е станал интерактивен. Това е защитено системно предаване, затова приложението не бива да го третира като обикновен Intent, който може просто да изпрати, за да събуди таблетката.
Ако изискването е да събуди екрана, да задържи екрана активен или да управлява поведението при включване на екрана , подходящият механизъм зависи от точното изискване за приложение. Android предоставя API-и за управление на енергията и прозорците/дейностите за тези сценарии, включително PowerManager и функционалност за блокиране на събуждането, когато е уместно.
Това различие е важно при разработването на приложения за Android киоск таблет . „Стартиране на системна функция“ и „управление на енергийното състояние на устройството“ са различни системни операции и трябва да се обработват чрез различни API-и.

Техническа поддръжка за интеграция на Android планшет
Този случай също показва защо разгъването на киоск може да изисква повече от основната конфигурация на хардуера на Android планшет.
Когато планшетът се интегрира в специализирано приложение, POS система, киоск, промишлено устройство или друго контролирано устройство, софтуерната конфигурация може едновременно да засяга стартиращото приложение (launcher), собственика на устройството (Device Owner), системния потребителски интерфейс (system UI), разрешенията за приложенията, намеренията за настройки (Settings Intents) и поведението при възстановяване.
За проекти, които изискват персонализиран Android планшет конфигурации – тези изисквания трябва да се оценяват заедно с хардуера и конфигурацията на Android-системата, а не като отделни въпроси по време на окончателното тестване.
Подходящото решение зависи от версията на Android, фърмуерната версия на таблета, конфигурацията на приложението и функциите, които системният интегратор трябва да контролира. Техническата документация също може да бъде подготвена въз основа на наличните системни интерфейси, поддържаните Intent-ове, разрешенията и устройство-специфичните ограничения.
Ако тествате Таблет с Android за разполагане в киоск или системна интеграция и срещнете подобни проблеми с Device Owner, персонализирани стартиращи програми, режим на киоск, Intent-ове за настройки, ограничения за системния потребителски интерфейс или възстановяване на устройството , моля свържете се с нас за техническа поддръжка .
Можете да предоставите модела на вашия таблет, версията на Android, конфигурацията за разполагане и конкретната функция, която се опитвате да реализирате. След това можем да обсъдим наличните Персонализации за Android-таблети и техническа поддръжка опциите за вашия проект.