Dispositivos Android dedicados frente a totalmente administrados: ¿cuál es la diferencia?

La respuesta corta

En Android Enterprise, un dispositivo totalmente administrado y un dispositivo dedicado son ambos propiedad de la empresa y se aprovisionan de modo que el controlador de políticas del dispositivo (DPC) quede configurado como device owner (propietario del dispositivo). El modo device owner es lo que importa: la organización controla todo el dispositivo, en lugar de un contenedor de trabajo situado junto al uso personal. La diferencia entre ambos es de intención, no de privilegios. Totalmente administrado describe un dispositivo de uso exclusivamente laboral asignado a una persona concreta, que inicia sesión y trabaja dentro de un conjunto de aplicaciones controladas por la organización. Un dispositivo dedicado —el modo que todavía se conoce ampliamente por su etiqueta anterior COSU, corporate-owned single-use— es ese mismo dispositivo totalmente administrado acotado a una tarea o a un conjunto estricto de tareas, normalmente sin supervisión, compartido o de cara al cliente. Por tanto, un dispositivo dedicado siempre es totalmente administrado; un dispositivo totalmente administrado no siempre es dedicado. El perfil de trabajo es la tercera forma, y es materialmente distinta: allí el DPC actúa como profile owner (propietario del perfil), el control se detiene en el contenedor de trabajo y el lado personal del dispositivo queda fuera de las políticas de la organización. La documentación de la Android Management API de Google los trata como modos de gestión distintos, y la distinción que realmente obliga es la de propiedad: que el dispositivo se aprovisione como device owner o con un perfil de trabajo lo fija la ruta de inscripción y no puede cambiarse después desde una consola. Dentro de device owner, las formas totalmente administrada y dedicada son una cuestión de políticas y no de aprovisionamiento, y por eso los costos de cambio de modo que se describen más adelante en esta guía difieren de forma tan marcada. Esta guía se ciñe a esa terminología para que un modo escrito en una especificación de compra signifique lo mismo para el administrador del EMM, el equipo de la aplicación y quien aprueba y firma el pedido.

Qué significa totalmente administrado

Un dispositivo totalmente administrado es hardware propiedad de la empresa en el que la plataforma de gestión actúa como device owner y la organización define políticas para todo el dispositivo. La imagen habitual es un teléfono o una tableta de trabajo entregados a un empleado: el usuario inicia sesión, accede a un conjunto de aplicaciones laborales publicadas mediante Google Play administrado y comprueba que los ajustes, la red y la instalación de aplicaciones siguen las políticas de la organización y no las preferencias personales. El modo device owner es el alcance estándar más amplio que ofrece Android Enterprise sin tocar el firmware: normalmente abarca la instalación y desinstalación silenciosa de aplicaciones, la concesión de permisos a las aplicaciones administradas, restricciones para agregar cuentas o realizar instalaciones externas, la configuración de Wi-Fi y certificados, la política de actualizaciones del sistema y el bloqueo o borrado remoto. El conjunto exacto de controles disponibles en un terminal concreto depende del OEM, de la versión de Android y del EMM, por lo que describimos estos dispositivos como controlados por políticas y administrados de forma centralizada, y confirmamos los controles concretos en el hardware objetivo en lugar de citar una lista de funciones del menú de una consola.

• Dispositivo propiedad de la empresa, inscrito con el DPC como device owner
• Políticas para todo el dispositivo, no un contenedor de trabajo aparte
• Cuenta de usuario con acceso a aplicaciones laborales controladas por la organización
• Uso personal restringido según las políticas de la organización
• El alcance del control varía según el OEM, la compilación de Android y el EMM; se confirma por modelo

Qué significa dispositivo dedicado

Un dispositivo dedicado es un dispositivo totalmente administrado bloqueado en una finalidad definida, normalmente sin un usuario nominal asociado. El patrón encaja con quioscos, terminales de cara al cliente, dispositivos compartidos entre turnos y herramientas de primera línea que ejecutan una tarea o un conjunto estricto de tareas durante toda la jornada. Como el modo dedicado es un subconjunto del totalmente administrado, hereda el mismo control de device owner y después reduce el entorno de ejecución a su función, normalmente mediante el modo lock task: el DPC declara qué paquetes pueden fijarse y, en las compilaciones compatibles, qué funciones del sistema —como la barra de estado, el botón de inicio, la vista general y las notificaciones— siguen accesibles mientras el dispositivo está bloqueado. La guía de Google sobre dispositivos dedicados y el modo lock task expone lo que ofrece la plataforma; un EMM presenta después algún subconjunto de ello. De ahí se derivan dos consecuencias prácticas. Primera: un dispositivo dedicado suele carecer de usuario, sin ninguna cuenta de Google con sesión iniciada, y las aplicaciones llegan mediante el EMM y no por una descarga iniciada por el usuario. Segunda: la firmeza del bloqueo es una propiedad de la política y del launcher, no del nombre del modo, y por eso el mismo modo puede producir un quiosco estricto de una sola aplicación o un dispositivo de turno flexible con cuatro aplicaciones. Estas configuraciones son configurables para MDM/EMM y quedan restringidas a su uso previsto, con el comportamiento confirmado en el hardware elegido antes de aprobar un lote.

• Finalidad única o conjunto de tareas estrictamente acotado
• A menudo sin usuario, compartido, sin supervisión o de cara al cliente
• El modo lock task fija los paquetes aprobados y recorta la interfaz del sistema
• Un subconjunto bloqueado del modo totalmente administrado, no un nivel de privilegios aparte

Dónde encaja el perfil de trabajo y por qué el uso personal cambia la respuesta

Los dos modos de propiedad de la empresa se comparan con frecuencia con una tercera postura que no se comporta en absoluto igual. En un dispositivo propiedad del empleado, el perfil de trabajo convierte al DPC en profile owner de un contenedor administrado: dentro viven las aplicaciones, las cuentas y los datos de trabajo, la organización puede borrar ese contenedor y todo lo que queda fuera —el launcher, las aplicaciones personales, la galería de fotos, el comportamiento de restablecimiento de fábrica del dispositivo— sigue siendo del propietario. Es un diseño deliberado, no una carencia que haya que sortear. También significa que una postura de propiedad del empleado no puede ofrecer control sobre todo el dispositivo, no puede fijar el dispositivo en modo quiosco y no puede convertirse en uno sin borrar el hardware. Cuando una ficha de proyecto dice «queremos comportamiento de quiosco, pero el personal también usa los teléfonos de forma personal», ese es el punto en el que hay que cerrar la especificación en lugar de aplazarla. Android Enterprise sí ofrece un dispositivo propiedad de la empresa con perfil de trabajo —el esquema que suele abreviarse como COPE—, en el que el aprovisionamiento sigue pasando por device owner y después se crea un perfil de trabajo encima. A partir de Android 11, el lado personal de ese esquema está protegido de forma intencionada: el administrador no recibe un inventario de las aplicaciones personales y la potestad sobre todo el dispositivo se limita a controles de tipo gestión de activos, como la política de actualizaciones del sistema, los identificadores del dispositivo, la protección contra restablecimiento de fábrica y un subconjunto definido de restricciones. El conjunto exacto depende de la versión de Android y del EMM, y debe contrastarse con lo que quien aprueba cree haber acordado. En los despliegues en los que todo el dispositivo pertenece a la tarea, la respuesta honesta es totalmente administrado o dedicado; cuando los empleados realmente necesitan uso personal en hardware de la empresa, el modo que hay que especificar es el perfil de trabajo propiedad de la empresa, y la conversación sobre la aceptación pasa a girar en torno a qué controles sobreviven al límite de privacidad. Nuestros programas de dispositivos Android administrados y controlados parten de esa decisión en lugar de darla por supuesta.

• Perfil de trabajo en un dispositivo propiedad del empleado: profile owner, solo el contenedor, sin control de todo el dispositivo
• Perfil de trabajo propiedad de la empresa (COPE): aprovisionamiento como device owner y después un perfil de trabajo con el lado personal protegido
• Totalmente administrado y dedicado: hardware de uso exclusivamente laboral, políticas para todo el dispositivo
• No se puede construir un quiosco sobre un perfil de trabajo en un dispositivo propiedad del empleado

Diferencias de políticas y de experiencia de usuario

Los dos modos de propiedad de la empresa divergen sobre todo en lo que experimenta la persona que está delante del dispositivo. Un dispositivo de empleado totalmente administrado suele conservar una pantalla de inicio reconocible y un entorno con varias aplicaciones tras el inicio de sesión del usuario, con los ajustes recortados y no eliminados. Un dispositivo dedicado se apoya en el modo lock task para fijar una sola aplicación o un pequeño launcher administrado, suprimir las salidas y ocultar la mayor parte de la interfaz del sistema, de modo que una persona del público o un operador entre turnos no pueda salirse de la tarea. Que un dispositivo dedicado muestre una aplicación o varias es una decisión de políticas, no una propiedad del modo. La capa que ofrece el bloqueo visible —un launcher administrado, la propia política de quiosco del EMM o el modo lock task gobernado directamente por el DPC— es, de nuevo, una elección aparte, y conviene tomarla de forma explícita: Launcher personalizado, modo quiosco o MDM trata esa decisión de capa en detalle. Tratamos el bloqueo exacto como configurable y sujeto a validación en el dispositivo objetivo, porque el comportamiento de la interfaz del sistema en torno a notificaciones, cuadros de diálogo, avisos de accesibilidad y capas del OEM es donde suelen encontrarse las rutas de salida del quiosco.

• Totalmente administrado: inicio de sesión del usuario, varias aplicaciones y ajustes recortados pero visibles
• Dedicado: el modo lock task fija una aplicación o un launcher reducido
• Los dispositivos dedicados pueden ser de una o de varias aplicaciones según la política
• La capa de entrega del launcher o del quiosco es una decisión independiente del modo

Rutas de inscripción que alcanzan el modo device owner

Los dos modos de propiedad de la empresa se aprovisionan como device owner mediante las mismas rutas de Android Enterprise y se diferencian después por la política que aplica el EMM. Ese es el dato mecánico más útil de esta página: la forma en que el dispositivo sale del asistente de configuración (Setup Wizard) determina si llega a ser device owner, y solo existe una ventana estrecha en la que puede establecerse. En la práctica, la ruta debe ejecutarse en un dispositivo restablecido a valores de fábrica o recién salido de la caja, antes de agregar una cuenta personal y antes de que finalice la configuración inicial; por eso la inscripción es una actividad del banco de preparación y no algo que un usuario de campo haga tras desembalar el equipo en su escritorio. La inscripción zero-touch es la ruta que escala, pero antes que técnica es una condición de la cadena de suministro: los dispositivos elegibles deben comprarse a un revendedor autorizado de zero-touch y registrarse en su cuenta, con una configuración asignada antes del primer encendido. Un código QR presentado en el asistente de configuración es la alternativa manual habitual y la ruta de preparación normal para las distintas fases; el NFC y el identificador DPC escrito en el asistente de configuración siguen siendo válidos en las compilaciones compatibles, pero se adaptan a cantidades pequeñas o a situaciones específicas del OEM. Cada ruta conlleva requisitos previos que fallan en silencio durante la preparación en vez de hacerlo con estrépito durante la definición del alcance: red en la pantalla de bienvenida, la cuenta de revendedor correcta y un dispositivo realmente limpio. La comparación de rutas en métodos de aprovisionamiento de dispositivos Android profundiza en los propios métodos de entrada; la tabla siguiente los analiza desde la perspectiva de qué modos de gestión pueden alcanzar y cómo suelen fallar.

Cuánto cuesta realmente cambiar el modo más adelante

No todo cambio de opinión es caro; la clave está en saber cuáles lo son. Pasar de totalmente administrado a dedicado, o al revés, suele ser un cambio de política: el dispositivo ya es device owner, de modo que restringir una flota con el modo lock task, agregar un launcher administrado o devolver una terminal a una configuración con varias aplicaciones es un envío de políticas y un reinicio de la aplicación, no un regreso al banco de trabajo. Entrar o salir de una postura de perfil de trabajo es un trabajo de otro orden. El modo device owner solo puede establecerse durante la ventana de aprovisionamiento descrita arriba, por lo que un dispositivo con un perfil de trabajo de propiedad personal no puede ascenderse a totalmente administrado: hay que restablecerlo a valores de fábrica y volver a aprovisionarlo por una ruta de device owner. Lo mismo ocurre a la inversa y entre las variantes de propiedad de la empresa: cambiar una flota ya entregada de totalmente administrada a un perfil de trabajo propiedad de la empresa, o al revés, implica un estado limpio por unidad. A escala de programa, el costo no es el restablecimiento en sí, sino la logística que lo rodea: recoger los dispositivos en las sedes, volver a prepararlos, volver a registrar números de serie e IMEI y repetir la aceptación sobre la línea base modificada. Por eso el modo de gestión debe figurar en la especificación de configuración antes de preparar el primer lote, y por eso una muestra de evaluación y una fase piloto de veinte a cien unidades son el lugar adecuado para descubrir que el modo era el equivocado, y no después de que se haya enviado el programa completo. Los programas de este tipo se cotizan a partir de unas 500 unidades, de modo que un error de modo detectado en campo es un fallo que se mide en manipulaciones de dispositivo en toda la flota.

• Totalmente administrado ↔ dedicado: normalmente un cambio de política, sin reinscripción
• Perfil de trabajo → totalmente administrado: restablecimiento de fábrica y reaprovisionamiento, unidad por unidad
• Totalmente administrado ↔ perfil de trabajo propiedad de la empresa: se requiere un estado limpio por unidad
• Volver a preparar en campo cuesta logística, no licencias: decida el modo en la especificación de configuración

Qué le hace al modo un restablecimiento de fábrica

El modo de gestión no es una propiedad que sobreviva por sí sola a un borrado. Un restablecimiento de fábrica devuelve el hardware a un estado sin aprovisionar, como recién salido de la caja, y que vuelva administrado depende por completo de la ruta por la que se inscribió. Un dispositivo zero-touch es la excepción que hace visible la diferencia: como la asignación reside en la consola de zero-touch asociada al identificador del hardware, a un dispositivo restablecido que alcanza la red durante la configuración inicial se le vuelve a ofrecer su configuración y se reaprovisiona solo. Un dispositivo inscrito mediante código QR, NFC o identificador DPC no tiene esa memoria: tras un restablecimiento es un dispositivo minorista corriente hasta que alguien repite la ruta en un banco de trabajo. Las políticas pueden reducir la probabilidad de un restablecimiento imprevisto: el modo device owner puede impedir que un usuario ejecute un restablecimiento de fábrica desde los ajustes, y la protección contra restablecimiento de fábrica puede exigir después una cuenta aprobada, aunque las combinaciones de teclas de recuperación y las herramientas de servicio del OEM se comportan de forma distinta según el fabricante y deben comprobarse en el modelo exacto en lugar de darse por supuestas. Para un despliegue, esto se convierte en una cuestión de aceptación y no en una curiosidad. La muestra debe restablecerse a propósito y recuperarse, con el estado final esperado registrado y la instrucción de recuperación escrita para quien vaya a custodiar los dispositivos, porque en una flota dedicada la diferencia entre «se restablece y vuelve al quiosco» y «llega a la sede como un teléfono de consumo en blanco» es la diferencia entre un ticket de soporte y un desplazamiento técnico.

• Un restablecimiento elimina device owner; el modo no se almacena en el hardware
• Zero-touch vuelve a ofrecer la configuración en la siguiente configuración inicial si hay red
• Las rutas de QR, NFC e identificador DPC exigen repetirlas en el banco de trabajo
• Las restricciones de restablecimiento y la protección contra restablecimiento de fábrica dependen del OEM y del modelo

Matriz de decisión por caso de uso

Elegir entre los modos se reduce a quién sostiene el dispositivo, qué hace durante toda la jornada y si alguien lo necesita para algo más. Un trabajador de campo que necesita varias aplicaciones laborales, un inicio de sesión y una pantalla de inicio familiar apunta a totalmente administrado; un quiosco, una terminal de inspección, un conjunto para el aula o una terminal minorista compartida apuntan a una configuración dedicada; un dispositivo que además debe admitir uso personal se aleja de ambos y apunta a un perfil de trabajo propiedad de la empresa. Muchos programas ejecutan más de un modo —terminales administradas para el personal junto con dispositivos dedicados para la tarea de cara al público— y eso no penaliza siempre que cada grupo tenga su propio conjunto de políticas, su propia muestra y su propio registro de aceptación. La matriz siguiente es orientativa, no prescriptiva; el modo correcto para su hardware, sus aplicaciones y sus mercados se fija durante la definición del alcance y luego se demuestra en la muestra.

Trasladar el modo a la muestra, la matriz y el lote

Un modo de gestión elegido en una reunión es una opinión; un modo de gestión reproducido en un banco de trabajo es una línea base. En un despliegue, la decisión debe sobrevivir en tres documentos. La muestra con control de versiones demuestra que el modelo exacto, el SKU regional y la compilación de firmware alcanzan el modo previsto desde un estado limpio y por la ruta prevista, y que la política se comporta como se describe una vez allí, incluso tras un reinicio y tras el escenario de restablecimiento acordado. La matriz de aceptación lo registra como filas aprobadas, fallidas o condicionales vinculadas a versiones y no a un dispositivo guardado en el cajón de alguien: modo alcanzado, ruta utilizada, paquetes y funciones de lock task, ajustes permitidos, rutas de salida probadas, estado final tras el restablecimiento y las limitaciones conocidas que siguen abiertas. La preparación del lote reproduce después el estado aceptado unidad por unidad y registra qué se reprodujo —número de serie, IMEI, confirmación de inscripción, versión de la política y la comprobación de calidad frente a la muestra de referencia— con una regla de parada cuando una unidad se desvía. Esa progresión es exactamente la distinción que traza Dispositivos Android preparados para MDM frente a preparados para el despliegue: un dispositivo visible en una consola ha demostrado capacidad de gestión, mientras que un dispositivo aprobado para un lote ha demostrado un estado reproducible. La selección del modo es una de las primeras entradas de esa cadena y una de las más caras de revisar, y por eso corresponde al alcance de personalización del dispositivo antes de pedir el hardware y no después de que llegue. Comparta el dispositivo o el formato objetivo, la aplicación, el EMM, los controles requeridos, los países objetivo y el rango de cantidades, y la revisión de viabilidad identificará qué modo necesita realmente el requisito, qué ruta de inscripción puede admitir la cadena de suministro y qué debe demostrar la muestra antes de aprobar un lote.