Launcher personalizado frente a modo quiosco y MDM: ¿qué capa necesita?

La respuesta corta

Estos tres términos describen distintas capas de una misma arquitectura, no productos que compitan entre sí. Un launcher personalizado cambia la interfaz de usuario: la pantalla de inicio que ve la persona y cómo se desplaza por el dispositivo. El modo quiosco restringe el dispositivo a una tarea o a un conjunto definido de aplicaciones mediante lock task, en un equipo cuyo controlador de políticas del dispositivo (DPC) está establecido como device owner. El MDM o EMM es la capa de políticas de flota: inscribe dispositivos, envía y modifica políticas, distribuye aplicaciones e informa del cumplimiento. Debajo de las tres hay una cuarta capa: la integración con el OEM a nivel de sistema, a la que se llega mediante OEMConfig, las API de administración del fabricante o trabajo de firmware, y donde residen los controles que la API pública de políticas no expone. La mayoría de los programas utilizan varias capas a la vez, así que la pregunta útil no es cuál elegir, sino a qué capa pertenece cada requisito concreto y si esa capa puede imponerlo o solo mostrarlo. De inmediato surge una segunda pregunta, que se responde más abajo en esta página: si la configuración resultante se escribe en el dispositivo una sola vez durante la preparación o se mantiene bajo gestión remota continua durante toda la vida útil de la flota.

Cuatro capas de control, no tres productos

Los requisitos llegan en forma de frases: «solo debe ejecutar nuestra aplicación», «tiene que parecerse a nuestro producto», «necesitaremos cambiar la lista de aplicaciones permitidas más adelante», «los usuarios no deben poder abrir los ajustes». Cada una de esas frases pertenece a una capa distinta, y el modo de fallo habitual en los proyectos de dispositivos es situar un requisito en una capa que no puede imponerlo. La capa de experiencia es el launcher: lo que muestra la pantalla y adónde llevan los toques. La capa de restricción de tareas es lock task: a qué aplicación queda fijado el dispositivo y qué elementos de la interfaz del sistema siguen siendo accesibles. La capa de políticas de flota es el DPC y la plataforma de gestión que hay detrás: inscripción, restricciones de usuario, distribución de aplicaciones, comandos remotos e informes. La capa de sistema es todo lo que el OEM expone más allá de la superficie de políticas estándar: marcos de escáner y de reasignación de teclas, control silencioso de las actualizaciones de firmware, permisos privilegiados para aplicaciones y persistencia tras un restablecimiento. Determinar qué control corresponde a Android Enterprise, al EMM, al OEM o a un launcher es justamente para lo que sirve la Matriz de dependencias OEM/MDM, y decidir si conviene recurrir siquiera a la capa de sistema es el tema de MDM frente a ROM Android personalizada. El orden importa: la capa más ligera capaz de imponer un requisito suele ser la correcta, porque cada escalón adicional cuesta tiempo de validación, reduce la lista de dispositivos candidatos y añade factores que activan una revalidación.

• Capa de experiencia — launcher personalizado: lo que ve el usuario y cómo navega
• Capa de restricción de tareas — lock task / quiosco: en qué aplicación se mantiene el dispositivo
• Capa de políticas de flota — DPC como device owner más la consola del EMM: qué se permite y qué cambia
• Capa de sistema — integración con el OEM, OEMConfig o firmware: controles que la API pública de políticas no expone

Qué cambia un launcher personalizado

Un launcher personalizado sustituye la aplicación de inicio predeterminada para rediseñar la superficie en la que aterriza el usuario: los iconos de aplicaciones visibles, la navegación entre ellos, la identidad de marca y el primer punto de entrada al contenido. Es una capa de experiencia: controla el aspecto y la sensación del dispositivo, no lo que técnicamente tiene permitido hacer. Con una configuración de device owner, el DPC puede establecer el launcher como gestor preferente persistente del intent de inicio, de modo que se aplica durante el aprovisionamiento en lugar de dejar la elección al usuario, y en el primer arranque no aparece ningún cuadro de selección. Ese único detalle es lo que separa un launcher desplegable de otro que el usuario puede abandonar. Un launcher también puede aportar valor operativo legítimo más allá de la marca: una lista de comprobación al iniciar el turno, un único botón de acción grande para uso con guantes, una franja de estado que muestre la sincronización o la salud de la batería, o un idioma predeterminado acorde con la sede y no con la cuenta. Lo que un launcher no puede hacer es impedir nada. Presenta un conjunto menor de opciones; no elimina las que hay debajo. Toda restricción que deba resistir a un usuario decidido —o simplemente curioso— tiene que expresarse en la capa de políticas y confirmarse después en la muestra, en lugar de darse por hecha a partir de una captura de pantalla.

• Una pantalla de inicio con identidad de marca y un conjunto seleccionado de iconos de aplicaciones
• Navegación y un punto de entrada al contenido diseñados en torno al flujo de trabajo
• Establecido como gestor de inicio predeterminado por el DPC durante el aprovisionamiento, no elegido por el usuario
• Solo experiencia e identidad de marca: por sí solo no constituye un límite de control

Qué controlan realmente el modo quiosco y lock task

El modo quiosco es el nombre operativo de lock task, una capacidad del framework que concede un device owner o, en usuarios y perfiles afiliados a partir de Android 9, un profile owner, aunque el hardware dedicado propiedad de la empresa se aprovisiona normalmente como device owner de todos modos. El DPC incluye en la lista de permitidas los paquetes autorizados a entrar en lock task, y el dispositivo queda retenido dentro de esa aplicación, ya sea porque la propia aplicación activa el modo o porque la plataforma de gestión aplica una configuración de quiosco en su nombre; Google documenta el mecanismo en modo lock task para dispositivos dedicados. Junto con la fijación en sí, la política decide qué funciones de lock task siguen disponibles: los botones de inicio y de vista general, el panel de notificaciones, el menú de acciones globales, el bloqueo de pantalla y la información del sistema en la barra de estado. Un quiosco de una sola aplicación encaja con un dispositivo que hace una única cosa; una configuración de varias aplicaciones presenta una superficie de inicio administrada sobre un conjunto definido de aplicaciones aprobadas, lo que la Android Management API expresa como un tipo de instalación de quiosco o como un launcher de quiosco administrado, según la forma requerida. Conviene señalar dos límites desde el principio. Lock task bloquea las actividades de paquetes ajenos a la lista de permitidas, pero no vigila lo que ocurre dentro de una aplicación permitida, de modo que una vista web incrustada, un visor de documentos o una pantalla de ayuda pueden seguir exponiendo una navegación que la política no pretendía; y si se permite un gestor del sistema, como el selector de documentos, para que el flujo de trabajo funcione, todo lo que ese gestor alcance pasa a ser accesible también. Además, lock task es una propiedad del modo administrado en el que está inscrito el dispositivo: el modo en sí es una decisión aparte, tratada en dispositivos Android dedicados frente a totalmente administrados. Estas restricciones son configurables para MDM/EMM y siguen sujetas a validación técnica en el hardware y la compilación elegidos.

• Quiosco de una sola aplicación para un dispositivo dedicado a una única tarea
• Quiosco de varias aplicaciones para un conjunto definido de aplicaciones aprobadas tras una superficie de inicio administrada
• Las funciones de lock task deciden qué elementos de la interfaz del sistema siguen siendo accesibles
• Los intents lanzados desde dentro de una aplicación permitida son la ruta de salida habitual que hay que probar

Qué aporta la capa de políticas de flota

El MDM o EMM opera a escala de flota. Inscribe dispositivos mediante una vía de aprovisionamiento acordada, aplica restricciones de usuario y perfiles de configuración, distribuye y actualiza aplicaciones, entrega configuración administrada a las aplicaciones que publican una, informa del inventario y del cumplimiento y emite comandos remotos como bloquear, reiniciar o restablecer la contraseña. Mientras que un launcher y una política de quiosco dan forma a un solo dispositivo, la capa de políticas de flota es la que aplica ese estado a cientos de unidades y lo mantiene vigente después. Aquí residen la mayoría de las restricciones firmes, y no en otro sitio: bloquear la instalación desde orígenes desconocidos, desactivar el arranque en modo seguro, impedir un restablecimiento de fábrica iniciado por el usuario, limitar qué ajustes puede cambiar el usuario y controlar el acceso a la depuración. La restricción a nivel de aplicación también suele estar aquí: a un navegador que publique una configuración administrada el EMM puede entregarle una lista de permitidas o de bloqueadas, pero solo para los campos que su desarrollador expuso realmente, y por eso la restricción del navegador es de las primeras cosas que conviene probar en lugar de prometer. La profundidad disponible depende del OEM y de la plataforma, y difiere entre plataformas de gestión: un control documentado para la API no está automáticamente presente en la consola que tiene licenciada ni en la compilación que ha comprado.

• Inscripción mediante una vía de aprovisionamiento acordada y políticas aplicadas en cada conexión del dispositivo
• Restricciones de usuario: orígenes desconocidos, arranque en modo seguro, restablecimiento de fábrica, alcance de los ajustes y depuración
• Distribución de aplicaciones, control de versiones y entrega de configuración administrada
• Inventario, estado de cumplimiento y comandos remotos como bloquear o reiniciar

Qué aporta únicamente la integración a nivel de sistema

Algunos requisitos no se resuelven en ninguna de las tres capas anteriores, porque el control no forma parte de la superficie de políticas estándar de Android Enterprise. Ejemplos típicos son la reasignación de teclas de hardware, el comportamiento del disparador de escáner y RFID, conceder un permiso privilegiado a una aplicación privada, mantener fija una versión de firmware mientras el resto de la flota se actualiza, controlar una base de carga o un bus de periféricos, o conservar una configuración tras un restablecimiento. Estos controles corresponden al OEM y se alcanzan mediante OEMConfig —un esquema de configuración administrada publicado por el fabricante y entregado por un EMM estándar—, mediante un SDK de administración del fabricante utilizado por un agente personalizado, o mediante trabajo de firmware a nivel de plataforma. La consecuencia práctica para un proyecto de dispositivos es que esta capa reduce la lista de dispositivos candidatos antes que ninguna otra: el requisito deja de ser «una tableta Android» y pasa a ser «una tableta Android de un fabricante que exponga este control en esta compilación». También introduce una obligación de mantenimiento, porque los marcos del fabricante se versionan de forma independiente de Android. Trate el trabajo a nivel de sistema como un escalamiento deliberado con un responsable designado, asumido solo cuando un requisito realmente no puede cumplirse por encima de él, y regístrelo como una limitación conocida con un factor que active una revalidación, no como un asunto resuelto.

• OEMConfig: ajustes del fabricante enviados a través de un EMM estándar sin un agente personalizado
• SDK de administración del fabricante: los utiliza un agente personalizado allí donde OEMConfig no llega
• Trabajo de firmware o de plataforma: la opción más pesada y menos portable
• Escale de forma deliberada: esta capa reduce la lista de dispositivos candidatos y añade factores que activan una revalidación

Política estática frente a gestión remota: el segundo eje

Elegir las capas responde a qué se controla. Una segunda pregunta, independiente, decide cómo se mantiene ese control: ¿la política se escribe en el dispositivo una sola vez durante la preparación, o el dispositivo permanece bajo gestión remota continua durante toda su vida útil? Ambos son diseños legítimos, y equivocarse en este supuesto sale caro de una forma que solo se manifiesta meses después de la entrega. Un dispositivo configurado de forma estática lleva consigo el estado aceptado desde el banco de preparación. El aprovisionamiento aplica el launcher, la configuración de lock task, el conjunto de aplicaciones y las restricciones; después, el dispositivo funciona sin una relación de gestión permanente. Nada tiene que conectarse, nada necesita una licencia para seguir funcionando y ninguna consola necesita un administrador. El costo recae en el cambio: una nueva entrada en la lista de permitidas, una aplicación actualizada o un ajuste corregido implican volver a preparar el equipo, una unidad devuelta o una visita a la sede, y ese costo se multiplica por cada unidad en campo. Un dispositivo administrado de forma remota mantiene una relación viva con un tenant de EMM. Las políticas se versionan de forma centralizada y se aplican en la siguiente conexión, las aplicaciones se actualizan en el propio equipo, el cumplimiento es visible y un dispositivo perdido puede bloquearse. El costo recae en la dependencia: el diseño da por supuesta una ruta de red, una suscripción activa y una persona designada que asuma el tenant tras el traspaso. Este último punto es el que más a menudo queda sin asignar. El tenant está vinculado a una identidad empresarial, y alguien tiene que custodiar las credenciales de administrador, renovar las licencias, aprobar aplicaciones y responder cuando un dispositivo deja de cumplir. Si ese responsable no se nombra antes de aprobar el lote, la flota se vuelve inadministrable justo en el momento en que hace falta administrarla. El caso sin conexión merece una respuesta explícita y no un supuesto. Un dispositivo que nunca se conecta no pierde su política: conserva el último estado que aplicó correctamente y sigue funcionando. Lo que pierde es todo cambio posterior: las nuevas políticas, las actualizaciones de aplicaciones, las revocaciones de acceso y los comandos remotos se encolan y nunca llegan, y la consola muestra una marca de última conexión desactualizada que puede confundirse con un dispositivo sano. Los programas con sedes realmente desconectadas suelen acabar en un modelo híbrido: una línea base estática lo bastante sólida como para ser operativamente correcta por sí sola, más una inscripción que añade gestión central allí donde haya conectividad. Ese híbrido debe ser un diseño declarado, con una ventana sin conexión acordada, y no un accidente descubierto durante el primer cambio de políticas.

Por qué un launcher por sí solo no es un límite de control

Un launcher personalizado instalado sin una política de device owner detrás suele poder abandonarse. Un usuario puede llegar a la interfaz original mediante el modo seguro, mediante una ruta de ajustes que cambie la aplicación de inicio predeterminada, mediante un intent lanzado por una aplicación permitida o mediante un restablecimiento de fábrica, porque el launcher pinta una superficie en lugar de eliminar una capacidad. La imposición procede de la capa de device owner y de las API del OEM que esta expone: las restricciones de usuario que bloquean el arranque en modo seguro y los orígenes desconocidos, la configuración de lock task que decide qué parte de la interfaz del sistema sobrevive y la política de restablecimiento que determina si el usuario puede borrar el dispositivo. La imposibilidad de eludir el control es una propiedad de la capa de políticas, no de la pantalla de inicio. Conviene dejar esta distinción escrita en el documento de requisitos con palabras claras, porque «bloqueado» significa algo muy distinto para un diseñador y para un administrador. En la práctica, la formulación honesta es doble: el launcher define la ruta prevista y la capa de políticas cierra las no previstas. Después se prueban ambas, y las que no puedan cerrarse en el hardware elegido se registran como excepciones aceptadas en lugar de omitirse en silencio.

• Un launcher sin política de device owner puede eludirse mediante el modo seguro o una ruta de ajustes
• Un restablecimiento de fábrica normal elimina el device owner y devuelve el dispositivo a la interfaz original
• Las restricciones que se imponen residen en la capa de device owner, restricciones de usuario y API del OEM
• El launcher define la ruta prevista; las políticas cierran las no previstas

Arquitecturas combinadas habituales

En la práctica, las capas se apilan y un número reducido de combinaciones cubre la mayoría de los despliegues. Un launcher más políticas de flota ofrece una superficie con identidad de marca que además se administra y se actualiza de forma centralizada: la forma habitual para un dispositivo de cara al cliente o para personal de campo. Lock task más una aplicación distribuida de forma privada produce un dispositivo dedicado a un único flujo de trabajo, en el que la aplicación fijada absorbe en la práctica el papel del launcher. OEMConfig envía ajustes del fabricante a través del EMM estándar cuando hace falta cambiar un comportamiento del hardware pero un agente personalizado resultaría desproporcionado. Un agente personalizado cierra las brechas que deja la API pública de políticas, a cambio de una obligación de mantenimiento. Y una línea base preparada de forma estática, con o sin inscripción posterior, cubre las flotas que no dispondrán de una ruta de red fiable. Ninguna de estas opciones es un nivel de producto; son combinaciones elegidas requisito a requisito, y un mismo programa puede contener más de una: un solo despliegue suele mezclar una variante totalmente bloqueada para los dispositivos compartidos entre turnos con una configuración más ligera para los supervisores.

• Launcher más políticas de flota: una superficie con identidad de marca administrada de forma centralizada
• Lock task más una aplicación privada: un dispositivo dedicado a un único flujo de trabajo
• OEMConfig: ajustes del fabricante enviados a través de un EMM estándar
• Agente personalizado: cierra las brechas que la API pública de políticas no cubre
• Línea base estática preparada: un estado aceptado que se mantiene sin conexión de gestión

Matriz de decisión de requisito a capa

Asignar cada requisito a una capa mantiene la configuración proporcionada y vuelve concreta la conversación sobre la aceptación: para cada línea de la tabla hay un mecanismo que la impone y una prueba que demuestra que se cumplió. La tabla es indicativa; la vía de imposición para un modelo, una versión de Android, una plataforma de gestión y una aplicación concretos se define durante la validación y se registra antes de cualquier compromiso, porque un mismo requisito puede recaer en capas distintas según lo que exponga el hardware elegido.

Cómo demostrar cada capa en la muestra con control de versiones

Un mapa de capas es una hipótesis hasta que una muestra lo pone a prueba. La muestra con control de versiones es la unidad que fija el modelo exacto y el SKU regional, la versión de Android y la compilación de firmware, el paquete y la versión de la aplicación, la versión de la política y la vía de aprovisionamiento, de modo que cada afirmación que sigue quede vinculada a algo reproducible y no a una familia de dispositivos. Cada capa produce un tipo distinto de evidencia, y confundirlas es como un proyecto llega al lote con una sorpresa desagradable. Una afirmación referida solo al launcher, probada con honestidad, se ve así: aparece la pantalla de inicio con identidad de marca, los iconos son correctos y, a continuación, un evaluador abre el panel de notificaciones, llega hasta los ajustes, cambia la aplicación de inicio predeterminada, arranca en modo seguro y ejecuta un restablecimiento de fábrica. Si esas rutas conducen a algo que el requisito prohíbe, el requisito nunca estuvo en la capa del launcher: pertenece a las políticas, y la matriz de aceptación registra el mecanismo, no la apariencia. La evidencia de la restricción de tareas es conductual y adversarial por diseño. La muestra no queda demostrada porque la aplicación se abra, sino porque la aplicación permanece abierta tras un reinicio, una llamada entrante, una notificación, la desconexión del cargador, una actualización, una detención forzada y un apagado por batería baja, y porque existe una vía de salida aprobada para supervisores que funciona para el personal sin convertirse en una elusión generalizada. Las pruebas de elusión pertenecen a la matriz de aceptación como escenarios con nombre y con resultado aprobado, reprobado o condicional, porque son las rutas que un usuario real encuentra en la primera quincena: el arranque en modo seguro, el enlace profundo a los ajustes, el menú para compartir, un selector de archivos dentro de una aplicación permitida, los gestores de descargas, una vista web incrustada que sigue un enlace externo, los servicios de accesibilidad, la depuración por USB y el propio restablecimiento de fábrica. La evidencia de las políticas de flota es evidencia de consola más una prueba de cambio: el dispositivo aparece con la identidad y la compilación esperadas, la versión de política aprobada es la que está aplicada, y se publica un cambio de política deliberado y se observa cómo llega al dispositivo dentro de la ventana acordada. La evidencia de la capa de sistema es la más estrecha y la más específica de cada modelo: un control del fabricante funciona en esta compilación o no funciona, y el resultado queda atado a una versión de firmware que puede cambiar. Todo lo que no pueda cerrarse se deja por escrito en lugar de descartarse: la biblioteca de limitaciones conocidas existe para que las rutas de salida residuales, las aprobaciones condicionales y los responsables de cada dependencia sigan siendo visibles para quien aprueba. La estructura de los propios resultados —escenario, comportamiento esperado, comportamiento observado, veredicto y responsable— sigue la matriz de aceptación de muestras. La preparación del lote reproduce después el estado aceptado en lugar de reinventarlo: la misma vía de aprovisionamiento, la misma versión de política y la misma compilación de la aplicación, comprobadas unidad por unidad frente a la muestra de referencia, con una regla de detención cuando una unidad se desvía. Eso es lo que convierte una muestra que funciona en un programa, que normalmente se cotiza a partir de unas 500 unidades, con una fase piloto de veinte a cien dispositivos dentro del programa para confirmar las decisiones de capa en condiciones reales antes de preparar las unidades restantes.

• Vincule cada afirmación sobre una capa a una única muestra con control de versiones: modelo, SKU, compilación, aplicación, política y vía de aprovisionamiento
• Pruebe el launcher intentando salir de él: panel de notificaciones, ajustes, cambio de la aplicación de inicio predeterminada, modo seguro y restablecimiento de fábrica
• Registre los escenarios de elusión en la matriz de aceptación con veredictos de aprobado, reprobado o condicional y un responsable designado
• Demuestre las políticas de flota con un cambio real: publique una versión de política y observe cómo llega dentro de la ventana acordada
• Reproduzca, no reinvente: la preparación del lote repite el estado aceptado y se detiene cuando una unidad se desvía

Limitaciones conocidas del modelo de capas

El modelo de capas es una herramienta de planificación, no una garantía, y conviene señalar dónde deja de ser ordenado. En la práctica, las capas no son perfectamente separables: una configuración de lock task puede cambiar el comportamiento de un launcher, una actualización de la aplicación puede desplazar un control de la capa de aplicación a la capa de políticas y una implementación del OEM puede diferir del comportamiento documentado del framework en la misma versión de Android. La disponibilidad depende en todo momento del OEM, la versión de Android, el EMM y el hardware, de modo que un control confirmado en un modelo no queda confirmado en su sucesor.

• La configuración administrada solo expone los campos que publicó el desarrollador de la aplicación; un EMM no puede inventarlos.
• Lock task bloquea los paquetes ajenos a la lista de permitidas, no la navegación dentro de una aplicación permitida; las vistas web y los gestores del sistema autorizados siguen siendo la ruta de salida habitual.
• Un restablecimiento de fábrica estándar elimina el device owner; la persistencia depende de la vía de aprovisionamiento y de un comportamiento del OEM que debe confirmarse en cada modelo.
• Las acciones remotas requieren que el dispositivo reciba y ejecute el comando; las unidades sin conexión o dañadas necesitan una vía de recuperación aparte.
• Las actualizaciones de firmware y de aplicaciones pueden desplazar comportamientos entre capas y deben activar una revalidación en lugar de dar por supuesta la continuidad.
• La documentación de la consola describe la capacidad de la plataforma, no el conjunto de funciones licenciadas en su tenant ni el comportamiento en su compilación exacta.

Decida la capa antes de decidir el dispositivo

El momento más barato para corregir una decisión de capa es antes de elegir el hardware, porque la capa determina la lista de candidatos mucho más que la ficha técnica. Un requisito que se resuelve con las políticas estándar de Android Enterprise mantiene amplia la elección de dispositivo; otro que necesita un marco de administración del fabricante la reduce a un puñado de modelos y añade una obligación de mantenimiento. Traiga la lista de requisitos en lugar de una idea de producto: qué debe ver el usuario, qué se le debe impedir hacer al dispositivo, qué tendrá que cambiar después de la entrega, si la flota tendrá conectividad, quién custodiará el tenant de gestión y el rango de cantidades en discusión. Vantora asigna cada línea a las capas de experiencia, restricción de tareas, políticas de flota y sistema, indica cuáles se imponen y cuáles son apariencia, y registra las limitaciones residuales antes de comprometer nada; la secuencia de puntos de control se describe en cómo funciona un despliegue validado de dispositivos Android, y el trabajo de integración en sí, en Integración de aplicación, MDM y quiosco.