Novedades de Android 10 en el ámbito empresarial

En esta página, se proporciona una descripción general de las nuevas API, funciones y cambios de comportamiento en el ámbito empresarial que se introdujeron en Android 10.

Perfiles de trabajo para dispositivos empresariales

Android 10 presenta nuevas funciones de aprovisionamiento y certificación para dispositivos empresariales que solo requieren un perfil de trabajo.

Herramientas de aprovisionamiento mejoradas para perfiles de trabajo

Puedes aprovisionar perfiles de trabajo en Android 10 y dispositivos posteriores inscritos mediante un código QR o la inscripción automática. Durante el aprovisionamiento de un dispositivo empresarial, un nuevo intent adicional les permite a las apps controladoras de políticas de dispositivos (DPC) iniciar un perfil de trabajo o una configuración completamente administrada. Después de que se crea un perfil de trabajo o se establece la administración completa, los DPC deben mostrar pantallas de cumplimiento de políticas para aplicar las políticas iniciales.

En el archivo de manifiesto de tu DPC, declara un nuevo filtro de intents para GET_PROVISIONING_MODE en una actividad y agrega el permiso BIND_DEVICE_ADMIN a fin de evitar que apps arbitrarias inicien la actividad. Por ejemplo:

<activity
    android:name=".GetProvisioningModeActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action
            android:name="android.app.action.GET_PROVISIONING_MODE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Durante el aprovisionamiento, el sistema inicia la actividad asociada con el filtro de intents. El propósito de esta actividad es especificar un modo de administración (de perfil de trabajo o completamente administrado).

Puede resultar útil recuperar elementos adicionales de aprovisionamiento antes de determinar el modo de administración apropiado para el dispositivo. La actividad puede llamar a getIntent() para recuperar lo siguiente:

Los DPC también pueden crear un nuevo intent de resultado y agregar los siguientes adicionales:

Para configurar el modo de administración en el dispositivo, llama a putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode), donde desiredProvisioningMode es:

  • Perfil de trabajo: PROVISIONING_MODE_MANAGED_PROFILE
  • Completamente administrado: PROVISIONING_MODE_FULLY_MANAGED_DEVICE

Completa el perfil de trabajo o el aprovisionamiento completamente administrado. Para ello, vuelve a enviar los detalles del aprovisionamiento a la configuración mediante setResult(RESULT_OK, Intent) y cierra todas las pantallas activas con finish().

Una vez que se completa el aprovisionamiento, hay un nuevo intent disponible para que los DPC abran sus pantallas de cumplimiento y apliquen la configuración inicial de las políticas. En los dispositivos con perfiles de trabajo, las pantallas de cumplimiento se muestran allí. Tu DPC debe garantizar que se muestren sus pantallas de cumplimiento a los usuarios, incluso si un usuario sale del flujo de configuración.

En el archivo de manifiesto de tu DPC, declara un nuevo filtro de intents para ADMIN_POLICY_COMPLIANCE en una actividad y agrega el permiso BIND_DEVICE_ADMIN a fin de evitar que apps arbitrarias inicien la actividad. Por ejemplo:

<activity
    android:name=".PolicyComplianceActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action android:name="android.app.action.ADMIN_POLICY_COMPLIANCE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Tu DPC debe usar este nuevo intent en lugar de escuchar la transmisión de ACTION_PROFILE_PROVISIONING_COMPLETE.

La actividad asociada con el filtro de intents puede llamar a getIntent() para recuperar EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE. Después de cumplir con la política, ADMIN_POLICY_COMPLIANCE debe mostrar setResult(RESULT_OK, Intent) y cerrar todas las pantallas activas con finish().

Los dispositivos completamente administrados redirigen a los usuarios a la pantalla principal. Los dispositivos con perfiles de trabajo les solicitan a los usuarios que agreguen su cuenta personal antes de regresarlos a la pantalla principal.

Certificación del ID de los dispositivos con perfiles de trabajo

Los DPC configurados como administradores de un perfil de trabajo aprovisionado con inscripción automática pueden obtener un ID de dispositivo con certificación de hardware, como un IMEI o el número de serie del fabricante. El dispositivo debe incluir hardware seguro (como un entorno de ejecución confiable [TEE] o un elemento seguro [SE]) y ser compatible con la certificación del ID del dispositivo y la inscripción automática.

El componente administrativo de un perfil de trabajo puede llamar a DevicePolicyManager.generateKeyPair() pasando uno o más elementos ID_TYPE_SERIAL, ID_TYPE_IMEI o ID_TYPE_MEID para el argumento idAttestationFlags.

Para obtener más información sobre la extracción y validación de los IDs de dispositivo, consulta el artículo Cómo verificar pares de claves con copia de seguridad en hardware con la certificación de claves.

Mejoras a los perfiles de trabajo

Hay nuevas APIs disponibles para admitir la visibilidad de calendarios sincronizados con perfiles y el bloqueo de instalaciones de apps desde fuentes desconocidas en todo el dispositivo.

Fuentes desconocidas, perfiles de trabajo y dispositivos

Las apps descargadas de fuentes distintas a Google Play (o cualquier otra tienda de aplicaciones confiable) se denominan apps de fuentes desconocidas. En Android 10, los administradores de perfiles de trabajo pueden evitar que cualquier usuario o perfil instalen apps de fuentes desconocidas en cualquier parte del dispositivo. Para ello, agregan la nueva restricción de usuarios DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY. Sin embargo, después de agregar esta restricción, una persona que use el dispositivo podrá instalar apps mediante adb.

Para evitar que los usuarios instalen apps por error desde fuentes desconocidas, recomendamos agregar esta restricción para los usuarios, ya que no requiere que se instalen los Servicios de Google Play. Si quieres admitir versiones anteriores de Android, establece un valor de configuración administrado para Google Play.

Cómo limitar los dispositivos de entrada permitidos en los perfiles de trabajo

Cuando los administradores de perfiles de trabajo llaman a DevicePolicyManager.setPermittedInputMethods(), los usuarios solo pueden acceder a los métodos de entrada permitidos dentro del perfil de trabajo, en lugar de a todo el dispositivo, lo que les da control total sobre los métodos de entrada personales en su dispositivo.

Cómo limpiar perfiles de trabajo sin notificarlo

Se agregó la marca WIPE_SILENTLY a DevicePolicyManager.wipeData(). Si se configura la marca, los usuarios no recibirán una notificación después de que se limpie su perfil de trabajo con wipeData().

Funciones nuevas para los dispositivos completamente administrados

Android 10 presenta nuevas funciones y API para dispositivos completamente administrados, lo que incluye actualizaciones manuales del sistema, extensión del código QR y aprovisionamiento de NFC para incluir las credenciales de una red Wi-Fi EAP y compatibilidad con DNS por TLS.

Instalación de la actualización del sistema manual

En Android 10, los administradores de dispositivos completamente administrados pueden instalar actualizaciones del sistema a través de un archivo de actualización del sistema. Las actualizaciones manuales del sistema permiten que los administradores de TI puedan:

  • Prueba una actualización en una pequeña cantidad de dispositivos antes de instalarlas de forma masiva.
  • Evita las descargas duplicadas en redes con ancho de banda limitado.
  • Escalonada o actualiza los dispositivos solo cuando no se estén usando.

Primero, un administrador de TI establece una política de actualización del sistema pospuesta para retrasar la instalación automática (si es necesario). A continuación, el DPC del dispositivo llama a installSystemUpdate() con la ruta de acceso al archivo de actualización del sistema del fabricante del dispositivo. Pasa un objeto InstallSystemUpdateCallback que el sistema pueda usar para informar errores que ocurren antes de que se reinicie el dispositivo. Si se produce un error, el sistema llama a onInstallUpdateError() con el código de error.

Después de reiniciar el dispositivo, tu DPC debe confirmar que la instalación se realizó correctamente mediante una API de versión, como Build.FINGERPRINT. Si falla la actualización, informa el error a un administrador de TI.

Aprovisionamiento de Wi-Fi con EAP

En Android 10, los códigos QR y los datos NFC que se usan para el aprovisionamiento de dispositivos pueden contener credenciales y configuración de EAP, incluidos los certificados. Cuando una persona escanea un código QR o presiona una etiqueta NFC, el dispositivo se autentica automáticamente en una red Wi-Fi local con EAP e inicia el proceso de aprovisionamiento sin ninguna entrada manual adicional.

Para autenticar Wi-Fi con EAP, agrega un extra EXTRA_PROVISIONING_WIFI_SECURITY_TYPE con el valor "EAP". Para especificar la autenticación de EAP, puedes agregar los siguientes elementos adicionales de aprovisionamiento a tu intent:

Compatibilidad con DNS privados

Las organizaciones pueden usar un DNS por TLS (llamado DNS privado en los dispositivos Android) para evitar filtrar consultas de DNS, como nombres de host internos. Los componentes administrativos de los dispositivos completamente administrados pueden controlar la configuración del DNS privado del dispositivo. Para configurar el modo de DNS privado, llama a lo siguiente:

Cuando tu DPC llama a cualquiera de estos métodos, el sistema muestra PRIVATE_DNS_SET_NO_ERROR si la llamada se realizó correctamente. De lo contrario, muestra un error.

Para recuperar el modo de DNS privado y la configuración de host en un dispositivo, llama a getGlobalPrivateDnsMode() y getGlobalPrivateDnsHost(). Para evitar que los usuarios cambien la configuración de DNS privado, agrega la restricción de usuarios DISALLOW_CONFIG_PRIVATE_DNS.

Exención del modo de bloqueo de VPN

El modo de bloqueo de VPN permite que un DPC bloquee cualquier tráfico de red que no use la VPN. Los administradores de dispositivos completamente administrados y perfiles de trabajo pueden eximir a las apps del modo de bloqueo. Las apps exentas usan una VPN de forma predeterminada, pero se conectan automáticamente a otras redes si la VPN no está disponible. Las apps exentas a las que se les niegue explícitamente el acceso a la VPN solo usarán otras redes.

Para eximir una app del modo de bloqueo, llama al nuevo método DevicePolicyManager setAlwaysOnVpnPackage(), que acepta una lista de paquetes de apps exentos. Cualquier paquete de apps que agregue el DPC debe instalarse en el dispositivo cuando se llama al método. Si se desinstala y se vuelve a instalar una app, esta debe volver a ser exenta. Para acceder a las apps que estaban exentas del modo de bloqueo, llama a getAlwaysOnVpnLockdownWhitelist().

Para ayudar a los administradores de los perfiles de trabajo y de los dispositivos completamente administrados a obtener el estado del modo de bloqueo, Android 10 agrega el método isAlwaysOnVpnLockdownEnabled().

Nuevos alcances de las delegaciones

Android 10 amplía la lista de funciones que un DPC puede delegar a otras apps más especializadas. Android agrupa en alcances a los métodos de API necesarios para realizar una tarea. Para delegar un alcance, llama a setDelegatedScopes() y pasa uno o más de los siguientes alcances:

Android 10 introduce la nueva clase DelegatedAdminReceiver para apps delegadas. El sistema usa este receptor de emisión para enviar devoluciones de llamada similares al DPC a fin de delegar apps. Las apps a las que se delegó el registro de actividad de red y la selección de certificados deben implementar esta clase. Para agregar este componente a una app delegada, sigue estos pasos:

  1. Agrega una subclase de DelegatedAdminReceiver a la app delegada.
  2. Declara el <receiver> en el manifiesto de la app y agrega una acción de filtro de intents para cada devolución de llamada. Por ejemplo, ACTION_NETWORK_LOGS_AVAILABLE o ACTION_CHOOSE_PRIVATE_KEY_ALIAS.
  3. Protege el receptor de emisión con el permiso BIND_DEVICE_ADMIN.

En el siguiente fragmento, se muestra el manifiesto de una sola app delegada que controla tanto el registro de red como la selección de certificados:

<receiver android:name=".app.DelegatedAdminReceiver"
        android:permission="android.permission.BIND_DELEGATED_ADMIN">
    <intent-filter>
        <action android:name="android.app.admin.action.NETWORK_LOGS_AVAILABLE">
        <action android:name="android.app.action.CHOOSE_PRIVATE_KEY_ALIAS">
    </intent-filter>
    </receiver>

Registro de actividad de red

Para ayudar a las organizaciones a detectar y rastrear software malicioso, los DPC pueden registrar conexiones TCP y búsquedas de DNS en el sistema. En Android 10, los administradores de dispositivos completamente administrados pueden delegar el registro de red a una app especializada.

Para recuperar los registros de red después de que el sistema habilita un lote, las apps delegadas deben crear primero una subclase DelegatedAdminReceiver (como se describió anteriormente). En tu subclase, sigue las instrucciones en Cómo recuperar registros para implementar la devolución de llamada onNetworkLogsAvailable().

Las apps delegadas pueden llamar a los siguientes métodos DevicePolicyManager (pasando null para el argumento admin):

Para evitar perder registros, los DPC no deben habilitar el registro de red si planean delegar a otra app. La app delegada debe habilitar y recopilar registros de red. Después de que un DPC delega el registro de red, no recibirá más devoluciones de llamada de onNetworkLogsAvailable().

Para obtener información sobre cómo informar el registro de actividad de red desde una app delegada, lee la guía para desarrolladores Registro de actividad de red.

Selección de certificados

En Android 10, los administradores de los dispositivos completamente administrados, los perfiles de trabajo y los usuarios secundarios pueden delegar la selección de certificados a una app especializada.

Para seleccionar un alias de certificado, las apps delegadas deben crear primero una subclase DelegatedAdminReceiver (como se describió anteriormente). En la subclase, implementa la devolución de llamada onChoosePrivateKeyAlias() y muestra un alias para un certificado preferido o, si deseas pedirle al usuario que seleccione un certificado, muestra null.

Baja de las políticas de administración del dispositivo

Android 10 evita que los DPC apliquen políticas de administración de dispositivos heredadas. Recomendamos a los clientes y socios realizar la transición a dispositivos completamente administrados o perfiles de trabajo. Las siguientes políticas arrojan una SecurityException cuando las invoca un administrador de dispositivos que se orienta a Android 10:

Algunas aplicaciones usan administradores de dispositivos para la administración de dispositivos de consumidores. Por ejemplo, para bloquear y limpiar un dispositivo perdido. Para habilitar esto, las siguientes políticas continúan disponibles:

Para obtener más información sobre estos cambios, consulta Baja de las administración del dispositivo.

Funciones nuevas para apps

Las apps orientadas a Android 10 pueden consultar la complejidad del bloqueo de pantalla establecida en un dispositivo antes de mostrar datos confidenciales o iniciar funciones esenciales. Las apps que llaman a la API de KeyChain se benefician de las mejoras en el comportamiento, mientras que las funciones nuevas también están disponibles para las apps de VPN.

Control de calidad del bloqueo de pantalla

A partir de Android 10, las apps con funciones esenciales que requieren un bloqueo de pantalla pueden consultar la complejidad del bloqueo de pantalla de un dispositivo o perfil de trabajo. Las apps que necesitan un bloqueo de pantalla más seguro pueden dirigir al usuario a la configuración del bloqueo de pantalla del sistema, lo que le permite actualizar la configuración de seguridad.

Para comprobar la calidad del bloqueo de pantalla:

Para iniciar la configuración del bloqueo de pantalla del sistema, usa ACTION_SET_NEW_PASSWORD con EXTRA_PASSWORD_COMPLEXITY adicional. Las opciones que no cumplan con la complejidad especificada en el intent adicional aparecerán inhabilitadas. Los usuarios pueden elegir entre las opciones de bloqueo de pantalla disponibles o salir de ella.

Práctica recomendada: Muestra un mensaje en tu app antes de iniciar la página de bloqueo de pantalla del sistema. Cuando se reanude la app, vuelve a llamar a DevicePolicyManager.getPasswordComplexity(). Si aún se requiere un bloqueo de pantalla más seguro, restringe el acceso en lugar de solicitar repetidamente a los usuarios que actualicen su configuración de seguridad.

Compatibilidad del proxy HTTP con apps de VPN

En Android 10, las apps de VPN pueden establecer un proxy HTTP para su conexión VPN. Para agregar un proxy HTTP, una app de VPN debe configurar una instancia de ProxyInfo con un host y un puerto, antes de llamar a VpnService.Builder.setHttpProxy(). El sistema y muchas bibliotecas de herramientas de redes usan esta configuración de proxy, pero el sistema no fuerza a las apps a cumplir con las solicitudes HTTP del proxy.

Para ver un código de muestra que ilustra cómo configurar un proxy HTTP, consulta la app de muestra ToyVPN.

Modos de servicio VPN

Las apps de VPN pueden detectar si el servicio está en ejecución gracias a la función VPN siempre activada y si el modo de bloqueo está activo. Los nuevos métodos que se agregaron en Android 10 pueden ayudarte a ajustar la interfaz de usuario. Por ejemplo, puedes inhabilitar el botón Desconectar cuando la VPN siempre activada controle el ciclo de vida de tu servicio.

Las apps de VPN pueden llamar a los siguientes métodos VpnService después de conectarse al servicio y establecer la interfaz local:

  • isAlwaysOn() para saber si el sistema inició el servicio gracias a la VPN siempre activa
  • isLockdownEnabled() para saber si el sistema bloquea conexiones que no usan la VPN

El estado siempre activo permanece igual mientras se ejecuta el servicio, pero el estado del modo de bloqueo puede cambiar.

Mejoras de KeyChain

En Android 10, se incluyen varias mejoras relacionadas con la API de KeyChain.

Cuando una app llama a KeyChain.choosePrivateKeyAlias(), los dispositivos con Android 10 y versiones posteriores filtran la lista de certificados que un usuario puede elegir según los emisores y los algoritmos clave especificados en la llamada.

Por ejemplo, cuando un servidor de TLS envía un mensaje de solicitud de certificado como parte de un protocolo de enlace TLS y el navegador llama a KeyChain.choosePrivateKeyAlias(), el mensaje de selección de certificado solo incluye opciones que coinciden con el parámetro de los emisores. Si no hay opciones de coincidencia disponibles o certificados instalados en el dispositivo, no se mostrará el mensaje de selección al usuario.

Además, KeyChain ya no requiere que un dispositivo tenga un bloqueo de pantalla para que se puedan importar claves o certificados de CA.