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:
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
: Agrega al paquete existente o crea uno nuevo. Este paquete se envía como un intent adicional cuando tu DPC lanza sus pantallas de cumplimiento de políticas.EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE
: Solo especifica una cuenta para migrar si agregas una cuenta de trabajo como parte del aprovisionamiento de perfiles de trabajo.EXTRA_PROVISIONING_SKIP_EDUCATION_SCREENS
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:
EXTRA_PROVISIONING_WIFI_EAP_METHOD
EXTRA_PROVISIONING_WIFI_IDENTITY
EXTRA_PROVISIONING_WIFI_ANONYMOUS_IDENTITY
EXTRA_PROVISIONING_WIFI_DOMAIN
EXTRA_PROVISIONING_WIFI_PHASE2_AUTH
EXTRA_PROVISIONING_WIFI_USER_CERTIFICATE
EXTRA_PROVISIONING_WIFI_CA_CERTIFICATE
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:
setGlobalPrivateDnsModeOpportunistic()
para que el dispositivo use un DNS privado cuando el sistema detecte un servidor de nombres compatiblesetGlobalPrivateDnsModeSpecifiedHost()
para especificar el nombre de host de un servidor de nombres compatible con RFC7858 en el argumentoprivateDnsHost
.
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:
DELEGATION_NETWORK_LOGGING
para delegar el registro de actividad de redDELEGATION_CERT_SELECTION
para delegar la selección de certificados
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:
- Agrega una subclase de
DelegatedAdminReceiver
a la app delegada. - 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
oACTION_CHOOSE_PRIVATE_KEY_ALIAS
. - 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:
USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD
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:
- Agrega el nuevo permiso
REQUEST_PASSWORD_COMPLEXITY
al manifiesto de tu app. - Llama a
DevicePolicyManager.getPasswordComplexity()
. La complejidad se divide en cuatro categorías:
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 activaisLockdownEnabled()
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.