Configuraciones gestionadas en Android: Configurar aplicaciones para trabajadores antes de que las abran

Una incidencia habitual del primer día es esta. Un trabajador abre la aplicación de la empresa, la aplicación pide la dirección de un servidor y nadie en planta la conoce. Alguien de TI escribe entonces la misma URL, el mismo nombre de cuenta o el mismo ajuste en cada dispositivo, y tarde o temprano uno de ellos acaba con una errata.

Android Enterprise dispone de una forma estándar de evitar esto, denominada configuraciones administradas. Se definen los valores de una app una sola vez en la directiva del MDM. Estos llegan a todos los dispositivos incluidos en esa directiva y la app los lee al iniciarse. Cuando un trabajador abre Chrome, el cliente de correo, una app de escaneo o su propia app de línea de negocio, esta ya sabe a dónde conectarse y qué está permitido.

Este tutorial cubre ambos lados de la configuración. Aprenderá a buscar y aplicar configuraciones administradas para apps comunes en el editor de directivas de su MDM. También aprenderá qué solicitar a sus desarrolladores internos para que sus propios APK admitan el mismo mecanismo.

Qué es una configuración administrada y quién define los campos

Una configuración administrada es un conjunto de parámetros clave-valor que una organización envía a una app en un dispositivo Android administrado. La documentación de Android Enterprise de Google describe la cadena de esta manera:

1. El desarrollador de la app define el esquema. En el archivo res/xml/app_restrictions.xml de la app, el desarrollador declara cada ajuste que aceptará la app: su clave, su tipo (string, boolean, integer, choice, multi-select, bundle, etc.), un título y un valor predeterminado.
2. Google Play publica el esquema. Cuando se sube la app a Google Play, Play lee ese archivo. Managed Google Play puede entonces mostrar los campos a las consolas de EMM como un formulario.
3. Su MDM envía los valores. A través de la Android Management API, la entrada de la app en la directiva del dispositivo transmite los valores que usted eligió.
4. La app los lee. En el dispositivo, la app llama a RestrictionsManager.getApplicationRestrictions() y aplica lo que encuentra.

Por lo tanto, el desarrollador de la app decide qué campos existen, no su MDM. Si el desarrollador no publicó una clave para la "URL del servidor", ninguna consola puede preconfigurar la URL del servidor. La consola solo puede rellenar los campos expuestos por el desarrollador.

Nota: Las configuraciones administradas son independientes de las directivas de dispositivo. Una directiva de dispositivo controla el propio Android, por ejemplo la cámara, el USB o el Wi-Fi. Una configuración administrada controla los ajustes dentro de una app específica. Por lo general, se necesitan ambas.

Antes de comenzar

• Los dispositivos están inscritos en su MDM con Android Enterprise (completamente administrados o con perfil de trabajo).
• Las apps que desea configurar están aprobadas en Managed Google Play o son apps privadas que sus desarrolladores publicaron allí.
• Dispone de un dispositivo de prueba inscrito bajo una directiva de prueba, no bajo su directiva de producción.
• Conoce los valores que desea enviar, como nombres de host de servidores, URLs permitidas y formatos de cuenta.

Paso 1: Comprobar si la app admite la configuración administrada

Antes de planificar nada, confirme que la app publica un esquema. Puede comprobarlo en tres lugares:

1. El editor de directivas de su MDM. Añada la app a una directiva de prueba y observe si aparece un formulario de configuración. Si es así, el desarrollador ha publicado un esquema.
2. La documentación corporativa del proveedor. Muchos proveedores publican sus claves. Por ejemplo, Google detalla las directivas empresariales de Chrome, con el soporte de plataforma para cada una, en chromeenterprise.google/policies.
3. El equipo de soporte del proveedor. Pregunte: "¿Su app para Android admite configuraciones administradas de Android Enterprise y qué claves expone?"

Anote cada clave que necesite y su tipo. Los tipos del esquema incluyen string, bool, integer, choice, multi-select, hidden, bundle y bundle_array. Un campo bool espera true o false, no el texto "true", y un campo multi-select espera valores de una lista fija.

Resultado esperado: Para cada app, sabrá si admite configuración administrada y qué campos configurará.

Advertencia: Si una app no tiene esquema, no existe ninguna alternativa dentro del sistema de configuraciones administradas. Sus opciones son pedir al proveedor que añada uno, cambiar de app o mantener un paso de configuración manual documentado para esa app.

Paso 2: Añadir la app a la directiva y abrir su configuración

1. Abra la directiva que cubre los dispositivos de destino. Utilice primero su directiva de prueba.
2. Añada la app desde Managed Google Play si aún no está en la directiva.
3. Abra el formulario de configuración de la app.

En Nomid MDM, la tarjeta de la aplicación en el editor de directivas abre su configuración gestionada. Es el conjunto de ajustes que el desarrollador publica a través de Google Play, mostrado como campos para rellenar. Las propias aplicaciones Android de Nomid leen sus ajustes de la misma manera.

Resultado esperado: Verá un formulario cuyos campos coinciden con las claves que anotó en el Paso 1.

Nota: Google Play lee el esquema de la aplicación subida, así que el formulario aparece en las aplicaciones distribuidas mediante Google Play gestionado, tanto públicas como privadas. En Nomid, las aplicaciones privadas alojadas en la Nomid Store también muestran un formulario de configuración cuando la aplicación subida declara un esquema. Para cualquier otra vía de distribución, compruebe cómo funciona la configuración antes de depender de ella.

Paso 3: Rellenar la configuración para apps comunes

Antes de rellenar valores, lea los Pasos 4 y 5. Decida qué valores son iguales para todos los dispositivos de la directiva y cuáles cambian según el centro o el dispositivo, para no tener que rehacer los formularios después.

A continuación se detallan los tres patrones que la mayoría de las flotas necesitan. Los nombres de los campos varían según el proveedor, por lo que debe considerar las claves como ejemplos y confirmarlas con el formulario específico de cada app.

3a. Navegador: página de inicio y listas de URLs (Chrome)

Chrome en Android admite muchas de las mismas directivas empresariales que Chrome para escritorio, distribuidas como configuración administrada. Las directivas utilizadas con frecuencia en dispositivos de trabajadores incluyen:

Antes de depender de una directiva, consulte la lista de directivas de Chrome Enterprise para confirmar que sea compatible con Android. Algunas directivas de escritorio, especialmente las relativas al inicio y al comportamiento de la página principal, se comportan de forma distinta o no están disponibles en Android. Si necesita una pantalla de inicio fija, los marcadores administrados o un enlace web en un launcher en modo kiosco suelen ser más predecibles. Si bloquea todo con URLBlocklist ["*"], añada también las páginas de inicio de sesión de su proveedor de identidad a URLAllowlist, o los sitios de trabajo que requieren inicio de sesión no cargarán.

3b. Cliente de correo: servidor y cuenta

Las apps de correo corporativo suelen exponer campos como:

• Dirección de correo electrónico o nombre de usuario
• Nombre de host del servidor (por ejemplo, un host de Exchange ActiveSync)
• Requisito de SSL/TLS
• Si se permite añadir cuentas personales

Los valores por usuario, como la dirección de correo electrónico, se tratan en el Paso 5. Por ahora, complete los campos que sean idénticos para todos, como el host del servidor y las opciones de seguridad.

3c. Apps de escaneo y de línea de negocio: URL del servidor y comportamiento

Las utilidades de dispositivos rugerizados, las apps de escaneo y las apps de negocio suelen exponer:

• URL base del backend o de la API, por ejemplo https://wms.example.com/api
• Código de inquilino (tenant), de sede o de almacén
• Conmutadores de funciones (feature toggles), como el modo sin conexión, escaneo por cámara frente a escáner de hardware o desactivación de registros de depuración

Guarde la directiva. Después, asegúrese de que su dispositivo de prueba está asignado a ella. Resultado esperado: El formulario de cada aplicación contiene los valores compartidos de esta directiva, la directiva está guardada y el dispositivo de prueba la usa.

Advertencia: Evite introducir contraseñas o secretos de larga duración en la configuración administrada. Los valores se almacenan en el dispositivo y pueden ser leídos por la app. Opte preferiblemente por flujos donde la configuración dirija la app al servidor correcto y luego el trabajador o la app se autentiquen.

Paso 4: Definirlo una sola vez por directiva

La configuración administrada pertenece a la directiva, no a un dispositivo individual. Todos los dispositivos bajo esa directiva reciben los mismos valores. Utilice esto a su favor:

1. Agrupe los dispositivos según lo que varíe. Si la tienda A y la tienda B utilizan URLs de backend diferentes, requerirán configuraciones diferentes. Organice sus directivas o grupos de directivas en torno a esa diferencia.
2. Reutilice una línea base validada. Cree una directiva completamente configurada y utilícela como punto de partida para nuevas sedes, de modo que no tenga que reconstruir la configuración manualmente. En Nomid, las plantillas de directivas y los grupos de directivas cumplen este propósito.
3. Cambie una vez, aplique en todas partes. Cuando cambie la URL del servidor, edítela en la directiva. Los dispositivos adoptarán el nuevo valor en su próxima sincronización de directivas.

Resultado esperado: Cada conjunto diferenciado de valores se asigna exactamente a una directiva o grupo de directivas, y nada se configura por dispositivo de forma manual.

Paso 5: Gestionar valores específicos por dispositivo

Algunos valores son diferentes en cada dispositivo: la dirección de correo electrónico de un usuario, el nombre de un dispositivo, una etiqueta de activo o un número de serie que su app necesita para el licenciamiento. Desde Android 10, las apps comunes no pueden leer el número de serie de hardware por sí mismas, por lo que enviarlo a través de la configuración administrada es un patrón habitual.

Existen dos enfoques generales:

• Variables. La Android Management API permite a una consola asociar variables de configuración a una plantilla de configuración administrada. De este modo, una única plantilla puede resolverse con valores diferentes en cada dispositivo. La forma en que una consola expone esto y las variables que ofrece difieren según el producto. Confirme con su proveedor qué atributos de dispositivo o usuario pueden insertarse antes de diseñar en torno a ellos.
• Ámbitos de directiva más reducidos. Si el valor específico por dispositivo realmente corresponde a una sede o equipo, asigne a ese grupo su propia directiva. Para un número reducido de dispositivos, esto resulta sencillo. Para cientos de ellos, no es escalable, lo que indica que necesita variables o un cambio en la app.

Una tercera opción reside en el lado de la app. La app puede tomar un valor compartido, como un ID de inquilino (tenant ID), de la configuración y luego obtener los ajustes específicos del dispositivo desde su propio backend tras el inicio de sesión. A menudo, esto resulta más sólido que enviar cada detalle específico por dispositivo a través del MDM.

Resultado esperado: Ha determinado, para cada campo, si el valor es compartido (a nivel de directiva), variable (resuelto por dispositivo) u obtenido por la app tras el inicio de sesión.

Paso 6: Comprobar que la app adoptó el cambio

1. Confirme que el dispositivo ha recibido la directiva. Verifique su estado de última conexión o sincronización en su consola. En Nomid, la lista de activos muestra la última conexión y el estado de contacto.
2. Confirme que la aplicación está instalada. Una configuración enviada antes de que termine la instalación se aplica en cuanto la aplicación está presente, pero tiene que estar realmente instalada. Revise la lista de aplicaciones del dispositivo en su consola o en el propio dispositivo.
3. Fuerce la detención y vuelva a abrir la aplicación. Muchas aplicaciones solo leen su configuración al iniciarse. Fuerce la detención desde la página de la aplicación en Ajustes. Si la directiva bloquea Ajustes, como en un kiosco, reinicie el dispositivo, algo que puede hacerse en remoto.
4. Verifique el interior de la app. El campo del servidor debe estar prerrellenado y bloqueado, el sitio web bloqueado debe estar inaccesible, etc. Una captura de pantalla remota le permite comprobarlo sin manipular el dispositivo físicamente.

Resultado esperado: En el dispositivo de prueba, cada aplicación configurada muestra los valores enviados sin introducir nada a mano. Después, despliegue por etapas: anote los valores actuales para poder volver atrás, copie los valores probados en la directiva de producción, aplíquela primero a un grupo piloto pequeño y amplíela cuando los dispositivos piloto muestren los valores correctos.

Nota: Si la app continúa mostrando valores antiguos tras forzar la detención, consulte la sección de preguntas frecuentes sobre resolución de problemas a continuación. La causa suele residir en cómo la app gestiona la configuración, no en la entrega.

Para apps internas: solicite a sus desarrolladores que publiquen un esquema

Si su propia app todavía pide a los trabajadores que introduzcan una URL de servidor, la solución reside en el código de la app. Puede remitir el siguiente resumen a su equipo de desarrollo.

1. Declarar el esquema

Cree res/xml/app_restrictions.xml:

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Hacer referencia al esquema en el manifiesto

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Leer los valores y reaccionar a los cambios

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

La difusión (broadcast) ACTION_APPLICATION_RESTRICTIONS_CHANGED solo se envía a los receptores registrados en tiempo de ejecución. La app también debería volver a leer la configuración en onResume() para que se apliquen los cambios realizados mientras estaba en segundo plano.

4. Publicar a través de Managed Google Play

Suba la app a Google Play, como app privada para su organización si no es pública, para que Play pueda leer el esquema y mostrar el formulario a su MDM. Cada nueva versión que añada o cambie el nombre de una clave requiere una nueva subida.

Lista de verificación para desarrolladores

• Mantenga las claves estables. Renombrar server_url invalida cualquier directiva que la configure.
• Oculte un campo en la interfaz cuando esté establecido por configuración, para que los trabajadores no puedan anularlo.
• Gestione los fallos de forma adecuada cuando una clave esté vacía, por ejemplo mostrando un mensaje claro de "contacte con TI".
• Nunca exija un secreto en la configuración. Utilícela para localizar el servidor y luego autentíquese de forma debida.
• Pruebe con la aplicación TestDPC de Google en un dispositivo que no esté inscrito en su MDM. TestDPC tiene que ser la aplicación de gestión del dispositivo, así que no funciona en uno que su MDM ya gestiona.

Preguntas frecuentes sobre resolución de problemas

La app no muestra formulario de configuración en el editor de directivas.

El desarrollador no ha publicado un esquema a través de Google Play o la versión de Play es anterior a este. Consulte la documentación del proveedor o pregúntele directamente. En el caso de apps internas, confirme que la entrada meta-data existe en el manifiesto y que se subió la versión que contiene el esquema. Una clave añadida en una versión nueva solo aparece en el formulario después de que esa versión se haya subido a Google Play y se haya procesado.

He cambiado un valor, pero la app sigue mostrando el anterior.

Revise estos puntos en orden:

1. ¿Ha sincronizado el dispositivo la directiva actualizada? Compruebe la última conexión.
2. Fuerce la detención y vuelva a abrir la app. Si ahora aparece el nuevo valor, la app solo lee la configuración al iniciarse y no escucha la difusión de cambios.
3. Si sigue sin aparecer, puede que la aplicación haya guardado el valor antiguo en su propio almacenamiento. Borrar los datos de la aplicación lo resuelve, pero elimina todo lo que solo está en el dispositivo, como escaneos sin conexión aún no sincronizados, así que sincronice antes. Si no, el desarrollador tiene que corregir la aplicación.

El valor llega, pero la app lo ignora.

Compruebe que el nombre de la clave y su tipo coincidan exactamente con el esquema. Las claves distinguen entre mayúsculas y minúsculas, y un booleano enviado como cadena de texto no se leerá como booleano. Compruebe también si la versión de la app instalada en el dispositivo es anterior a la versión en la que se introdujo la clave. En un dispositivo con perfil de trabajo, compruebe que el trabajador abrió la copia de trabajo de la aplicación, marcada con el icono de un maletín. La copia personal nunca recibe la configuración.

Algunas directivas de Chrome funcionan y otras no.

No todas las directivas de Chrome Enterprise son compatibles con Android. Compruebe la compatibilidad de plataforma de cada una en la lista de directivas de Chrome Enterprise y verifique la versión de Chrome en el dispositivo.

¿Puedo enviar un valor diferente a cada dispositivo?

Sí, pero no de forma predeterminada. Utilice variables de configuración si su consola las admite para el atributo requerido, divida los dispositivos en directivas más pequeñas o haga que la app obtenga la configuración por dispositivo desde su backend. Consulte el Paso 5.

La configuración se aplicó, pero el trabajador todavía puede editar el campo.

Bloquear un campo es función de la app, no de Android. Solicite al desarrollador que inhabilite u oculte los ajustes procedentes de la configuración administrada.

¿Cómo realizo pruebas sin afectar a producción?

Utilice una directiva de prueba dedicada y un único dispositivo inscrito. Para apps internas, los desarrolladores pueden utilizar TestDPC antes de que la app llegue a su MDM.

Próximos pasos

Puntos clave:

• El desarrollador de la app define qué se puede configurar. Su MDM se limita a rellenar esos campos y nada más.
• Confirme primero la compatibilidad, registre las claves y tipos, y realice pruebas en un dispositivo antes del despliegue masivo.
• Los valores compartidos pertenecen a la directiva. Los valores por dispositivo requieren variables, ámbitos más reducidos o consultas desde la propia app.
• En el caso de apps internas, añadir un esquema requiere una modificación pequeña y bien documentada, y elimina el paso de configuración manual para los trabajadores.

Comience esta semana con la app que genere más tickets de configuración. Enumere sus claves, cree una directiva de prueba y verifíquela en un dispositivo. Luego, envíe la lista de verificación para desarrolladores anterior al equipo responsable de su app interna.

Si desea probar este flujo con Nomid MDM, la tarjeta de la app en el editor de directivas abre la configuración administrada de cada app, y el plan gratuito cubre hasta 10 dispositivos sin límite de tiempo. Esto es suficiente para una directiva de prueba y un grupo piloto. El acceso remoto y la API no están incluidos en el plan gratuito.

Preguntas frecuentes

¿Qué es una configuración administrada de Android?

Es un conjunto de parámetros clave-valor que una organización envía a una app en un dispositivo Android administrado. Algunos ejemplos incluyen la URL de un servidor, sitios web permitidos o conmutadores de funciones. El desarrollador de la app define los campos disponibles en un esquema publicado a través de Google Play, y el MDM envía los valores mediante la directiva de dispositivos.

¿Cómo sé si una app admite app config en Android Enterprise?

Añada la app a una directiva de prueba en su MDM y compruebe si aparece un formulario de configuración. También puede revisar la documentación corporativa del proveedor o consultar a su equipo de soporte qué claves de configuración administrada expone la app.

¿Qué es app_restrictions.xml?

Es el archivo XML ubicado en los recursos de una app de Android donde el desarrollador declara el esquema de configuración administrada: la clave, el tipo, el título y el valor predeterminado de cada ajuste. Se hace referencia a este archivo en el manifiesto de la app y Google Play lo lee al subir la app.

¿Se aplica de inmediato un cambio en la configuración administrada?

El dispositivo lo recibe en su siguiente sincronización de directivas. El hecho de que la app lo aplique de inmediato depende de la propia app. Las apps que escuchan la difusión de restricciones modificadas se actualizan durante la ejecución, mientras que otras solo leen su configuración en el siguiente inicio.