Configuración del quiosco Android: qué hacer cuando el propietario del dispositivo le impide acceder a la configuración

Atableta Android de 10,1 pulgadas se configuró para uso en quiosco con ADB, un lanzador personalizado y Propietario del dispositivo. Tras reiniciar, la aplicación se inició según lo previsto, pero el dispositivo ya no pudo acceder a la interfaz normal de Ajustes de Android.

Esto generó un desafío habitual en la implementación de quioscos: una vez que se han restringido la navegación del sistema y los controles de administración del dispositivo, ¿cómo se puede recuperar la tableta para pruebas adicionales? Y si la aplicación necesita abrir Wi-Fi u otras funciones del sistema, ¿qué Intents de Android siguen estando disponibles?

El cliente utilizó primero comandos ADB para modificar el comportamiento de la interfaz de usuario del sistema:

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

A continuación, se estableció la aplicación como pantalla de inicio predeterminada y luego se configuró como Propietario del dispositivo activar las funciones requeridas de gestión de dispositivos.

Tras reiniciar, la Tablet Android en modo quiosco entró automáticamente en la aplicación según lo previsto. Sin embargo, el cliente ya no podía salir de la pantalla principal de la aplicación para acceder a Ajustes de Android u otras funciones del sistema. Asimismo, los botones de Ajustes y Wi-Fi integrados en la aplicación dejaron de abrir las páginas correspondientes del sistema.

La pregunta inmediata no era simplemente cómo salir de la aplicación. El cliente necesitaba un método fiable para recuperar la Tableta Android para realizar pruebas adicionales y también deseaba comprender qué Intents del sistema podía utilizar su aplicación.

Por qué la tablet Android se volvió difícil de acceder

El problema surgió porque se aplicaron simultáneamente varias capas de control del dispositivo.

El lanzador personalizado determinaba qué aplicación aparecía como pantalla de inicio, mientras que el propietario del dispositivo otorgaba a la aplicación un control mucho más amplio sobre la política del dispositivo. La documentación oficial de Android para dispositivos dedicados respalda este tipo de configuración en despliegues de quioscos y dispositivos gestionados, incluido el control de la aplicación predeterminada de inicio y la restricción del acceso a funciones del sistema.

Los comandos ADB añadían otra capa al modificar el comportamiento de la interfaz de usuario del sistema. Estas configuraciones concretas dependen del dispositivo o del firmware, y no son API universales de Android; por tanto, su efecto exacto depende de cómo el firmware de la tableta las implemente.

Esto significa que un Tablet Android utilizada como dispositivo de quiosco puede resultar difícil de recuperar cuando se modifican simultáneamente el lanzador, la configuración de propietario del dispositivo, las restricciones de la interfaz de usuario del sistema y la navegación de la aplicación.

El hecho de que los botones «Ajustes» o «Wi-Fi» de la aplicación ya no funcionen no implica necesariamente que la intención (Intent) en sí sea incorrecta. La actividad de ajustes (Settings Activity) de destino puede estar indisponible, restringida u otra forma inaccesible bajo la configuración actual del dispositivo. Android también recomienda comprobar si una intención puede resolverse antes de intentar iniciarla.

Rutas de recuperación para una tablet Android en modo quiosco bloqueada

Si la aplicación ya está configurada como propietaria del dispositivo (Device Owner), primero debe considerarse la recuperación basada en software.

El sistema Android DevicePolicyManager ofrece funciones de gestión de dispositivos que pueden utilizarse mediante una aplicación propietaria del dispositivo (Device Owner). Dependiendo de la versión de Android y de la configuración de la aplicación, una aplicación propietaria del dispositivo puede emplear el mecanismo de borrado adecuado para restablecer la tablet a un estado limpio destinado a pruebas. wipeData() es la API establecida para borrar los datos del usuario, mientras que las versiones más recientes de Android ofrecen funcionalidades adicionales de borrado de dispositivos.

La obsoleta clearDeviceOwnerApp() el método no debe considerarse un método general de recuperación de producción. Android lo documenta como una API orientada a pruebas y recomienda el restablecimiento de fábrica como la forma habitual de eliminar una relación de propietario del dispositivo.

ADB también ofrece comandos de gestión de directivas para dispositivos, pero estos tienen restricciones. Por ejemplo, adb shell dpm remove-active-admin no es un método universal para eliminar un propietario del dispositivo; la documentación oficial de ADB de Android especifica requisitos como la declaración testOnly de la aplicación.

Si la recuperación mediante software no está disponible porque la aplicación no puede ejecutar la operación requerida, el camino restante es un restablecimiento de fábrica por hardware o el procedimiento de recuperación de Android .

No debe asumirse la combinación exacta de botones a partir de otro modelo de tableta Android. El comportamiento de recuperación depende de la implementación del firmware y del hardware de la tableta. Por tanto, en un proyecto de tableta Android personalizada, el procedimiento de recuperación adecuado debe confirmarse previamente para el modelo y el firmware reales antes de su despliegue.

Para este tipo de Tablet Android en modo quiosco , tener un método definido de recuperación es especialmente útil durante las pruebas de integración porque la configuración a nivel de sistema puede eliminar intencionalmente la navegación normal del usuario.

Pruebas de intenciones de configuración y funciones del sistema en una tableta Android

La segunda pregunta del cliente fue si la aplicación podía iniciar directamente funciones del sistema, como Configuración y Wi-Fi.

Android proporciona acciones estándar de Configuración para estas funciones. Por ejemplo:

Función	Intención estándar de Android
Configuración principal	Settings.ACTION_SETTINGS
Configuración de Wi-Fi	Settings.ACTION_WIFI_SETTINGS
Configuración inalámbrica	Settings.ACTION_WIRELESS_SETTINGS
Ajustes de Bluetooth	Settings.ACTION_BLUETOOTH_SETTINGS
Ajustes de pantalla	Settings.ACTION_DISPLAY_SETTINGS
Ajustes de ubicación	Settings.ACTION_LOCATION_SOURCE_SETTINGS
Ajustes de sonido	Settings.ACTION_SOUND_SETTINGS
Ajustes de seguridad	Settings.ACTION_SECURITY_SETTINGS
Ajustes de aplicaciones	Settings.ACTION_APPLICATION_SETTINGS
Configuración específica de la aplicación	Settings.ACTION_APPLICATION_DETAILS_SETTINGS

 

Estas son acciones estándar de Configuración de Android, no interfaces específicas de un fabricante determinado de tabletas Android Android . Sin embargo, la existencia de un Intent no garantiza que se abra correctamente en todos los dispositivos ni bajo todas las configuraciones de quiosco. Android recomienda comprobar el Intent mediante resolveActivity() antes de iniciarlo.

Por tanto, para una tableta Android integrada en el sistema, las pruebas de Intent deben realizarse en el firmware y la versión de Android reales utilizados para la implementación. La prueba debe verificar no solo si el Intent existe, sino también si la Actividad correspondiente puede accederse tras aplicar las restricciones de Propietario del dispositivo, lanzador e interfaz de usuario del sistema.

Si está trabajando en un proyecto de tablet kiosco Android o de integración de sistemas y necesita ayuda con la recuperación del propietario del dispositivo, las intenciones de Ajustes o problemas relacionados de configuración, póngase en contacto con nosotros indicando el modelo de su tablet y la versión de Android. Podemos analizar las opciones disponibles de soporte técnico y personalización.

 

El mismo principio se aplica a otras funciones del sistema. Puede existir una API estándar de Android, pero el comportamiento real de una tablet personalizada depende de su versión de Android, su configuración de firmware y sus políticas de gestión de dispositivos.

¿Qué ocurre con las solicitudes de activación (wake requests)?

La pregunta del cliente sobre «solicitudes de activación» es ligeramente distinta de la acción de abrir una página de Ajustes.

Intent.ACTION_SCREEN_ON representa una transmisión del sistema que indica que la pantalla ha pasado al estado interactivo. Se trata de una transmisión del sistema protegida, por lo que una aplicación no debe tratarla como una intención ordinaria que pueda enviarse simplemente para activar la tablet.

Si el requisito consiste en activar la pantalla, mantenerla activa o controlar su comportamiento de activación , el mecanismo adecuado depende del requisito exacto de la aplicación. Android proporciona API de gestión de energía y de ventanas/actividades para estos escenarios, incluidas PowerManager y la funcionalidad de bloqueo de activación (wake lock) cuando corresponda.

Esta distinción es importante al desarrollar aplicaciones para una Tablet Android en modo quiosco . «Iniciar una función del sistema» y «controlar el estado de energía del dispositivo» son operaciones del sistema diferentes y deben gestionarse mediante API distintas.

Soporte técnico para la integración de tabletas Android

Este caso también muestra por qué la implementación en modo quiosco puede requerir más que la configuración básica de hardware de una tableta Android.

Cuando una tableta se integra en una aplicación dedicada, un sistema POS, un quiosco, un sistema industrial u otro dispositivo gestionado, la configuración del software puede implicar simultáneamente el lanzador (launcher), el propietario del dispositivo (Device Owner), la interfaz de usuario del sistema, los permisos de la aplicación, las intenciones de configuración (Settings Intents) y el comportamiento de recuperación.

Para proyectos que requieren tableta Android personalizada configuraciones; estos requisitos deben evaluarse junto con la configuración del hardware y del sistema Android, en lugar de tratarlos como problemas independientes durante las pruebas finales.

La solución adecuada depende de la versión de Android, el firmware de la tableta, la configuración de la aplicación y las funciones que el integrador de sistemas necesita controlar. También se puede elaborar documentación técnica basada en las interfaces del sistema disponibles, los Intent compatibles, los permisos y las limitaciones específicas del dispositivo.

Si está probando una Tableta Android para implementación en modo quiosco o integración de sistemas y encuentra problemas similares con Propietario del dispositivo, lanzadores personalizados, modo quiosco, Intent de Ajustes, restricciones de la interfaz de usuario del sistema o recuperación del dispositivo , por favor contáctenos para soporte técnico .

Puede indicarnos el modelo de su tableta, la versión de Android, la configuración de implementación y la función específica que intenta implementar. Luego podremos analizar las opciones disponibles de Personalización de tabletas Android y soporte técnico opciones para su proyecto.