En esta página, se proporciona una descripción general de las nuevas API, funciones y cambios de comportamiento en el ámbito empresarial introducidos en Android 10.
Perfiles de trabajo para dispositivos empresariales
Android 10 incluye 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
Ahora es posible 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. Una vez que se creó un perfil de trabajo o se estableció la administración completa, los DPC deben mostrar pantallas de cumplimiento de las políticas para aplicar las políticas iniciales.
En el archivo de manifiesto de tu DPC, declara un nuevo filtro de intent para
GET_PROVISIONING_MODE
en una actividad y agrega el BIND_DEVICE_ADMIN
permiso para 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 intent. El objetivo de esa actividad será especificar un modo de administración (aprovisionamiento con perfil de trabajo o completamente administrado).
Puede resultarte útil recuperar elementos adicionales de aprovisionamiento antes de determinar el modo adecuado de administración 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: Para agregar al paquete existente o crear uno nuevo. Este paquete se envía como un intent adicional cuando tu DPC inicia sus pantallas de cumplimiento de las políticas.EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE: Solo para especificar una cuenta a la cual realizar la migración si agregas una cuenta de trabajo como parte del aprovisionamiento de perfiles de trabajo.EXTRA_PROVISIONING_SKIP_EDUCATION_SCREENS
Para definir el modo de administración, 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
Para completar el aprovisionamiento del perfil de trabajo o el aprovisionamiento completamente administrado, envía los detalles del aprovisionamiento a la configuración a través de setResult(RESULT_OK,
Intent)
y cierra todas las pantallas activas con
finish().
Una vez finalizado el aprovisionamiento, verás un nuevo intent disponible para el DPC, que permitirá mostrar las pantallas relacionadas con el cumplimiento y hacer cumplir la configuración inicial de las políticas. En los dispositivos con perfiles de trabajo, las pantallas de cumplimiento se muestran en el perfil de trabajo. Tu DPC debe asegurarse de que las pantallas de cumplimiento se muestren a los usuarios, incluso si un usuario omite el flujo de configuración.
En el archivo de manifiesto de tu DPC, declara un nuevo filtro de intent para
ADMIN_POLICY_COMPLIANCE
en una actividad y agrega el permiso BIND_DEVICE_ADMIN
para 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 detectar la
ACTION_PROFILE_PROVISIONING_COMPLETE
transmisión.
La actividad asociada con el filtro de intent puede llamar
getIntent() para recuperar
el
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE.
Después de realizar el cumplimiento de las políticas, 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 que tienen perfiles de trabajo solicitarán a los usuarios que agreguen su cuenta personal antes de dirigirlos a la pantalla principal.
Certificación del ID de los dispositivos con perfiles de trabajo
Los DPC configurados como los administradores de un perfil de trabajo aprovisionado con inscripción sin contacto pueden obtener un ID de dispositivo con certificación de hardware, como el IMEI o el número de serie del fabricante. El dispositivo debe incluir hardware seguro (como un entorno de ejecución confiable [TEE] o Elemento seguro [SE]) y ser compatible con la certificación del ID de dispositivo y la inscripción sin contacto.
El componente de administrador de un perfil de trabajo puede llamar a DevicePolicyManager.generateKeyPair() y pasar uno o más de ID_TYPE_SERIAL, ID_TYPE_IMEI o ID_TYPE_MEID para el argumento idAttestationFlags.
Para obtener más información sobre cómo extraer y validar IDs de dispositivos, consulta Cómo verificar pares de claves guardadas en hardware con certificación de claves.
Mejoras a los perfiles de trabajo
Hay nuevas API disponibles que admiten la visibilidad de calendarios sincronizados con perfiles y el bloqueo de instalaciones de apps de fuentes desconocidas en todo el dispositivo.
Fuentes desconocidas, perfiles de trabajo y dispositivos
Aquellas apps descargadas de otros sitios ajenos a Google Play (o a otras tiendas de apps de confianza) se denominan apps de fuentes desconocidas. En Android 10, los administradores de perfiles de trabajo pueden evitar que cualquier usuario o perfil instale apps de fuentes desconocidas en cualquier lugar del dispositivo agregando la nueva restricción de usuario
DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY.
Sin embargo, después de agregar esta restricción, una persona que use el dispositivo aún puede
instalar apps con adb.
Para evitar que los usuarios instalen apps de fuentes desconocidas por error, te recomendamos que agregues esta restricción de usuario, ya que no requiere que se instalen los Servicios de Google Play. Si quieres brindar compatibilidad con versiones anteriores de Android, puedes configurar 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 de su perfil
de trabajo, en lugar de a todo el dispositivo, lo que les proporciona el control total sobre los métodos de entrada que pueden utilizar en el perfil personal del dispositivo.
Cómo limpiar perfiles de trabajo sin notificarlo
Se agregó la WIPE_SILENTLY
marca a DevicePolicyManager.wipeData().
Si se establece la marca, no se notificará a los usuarios después de que se limpie su perfil de trabajo
con wipeData().
Funciones nuevas para los dispositivos completamente administrados
Android 10 introduce nuevas funciones y APIs para dispositivos completamente administrados, como actualizaciones manuales del sistema, extensión del código QR y aprovisionamiento de NFC a fin de incluir credenciales para una red Wi-Fi con EAP y compatibilidad con DNS mediante TLS.
Instalación de la actualización del sistema manual
En Android 10, los administradores de dispositivos completamente administrados pueden instalar actualizaciones del sistema mediante un archivo específico para tal fin. Las actualizaciones manuales del sistema permiten que los administradores de TI puedan:
- Probar una actualización en una pequeña cantidad de dispositivos antes de instalarlos de forma generalizada
- Evitar descargas duplicadas en redes con ancho de banda limitado
- Escalonar las instalaciones o actualizar los dispositivos solo cuando no se estén usando
Primero, un administrador de TI configura una política de actualización del sistema pospuesta
para retrasar la instalación automática (si es necesario). Luego, el DPC del dispositivo llama a installSystemUpdate()
con la ruta de acceso al archivo de actualización del sistema del fabricante del dispositivo. Se transfiere un InstallSystemUpdateCallback
objeto que el sistema puede usar para informar errores que ocurren antes de que se reinicie el dispositivo. Si se registra algún problema, el sistema llama a onInstallUpdateError()
con el código de error.
Después de que se reinicie el dispositivo, tu DPC debe confirmar una instalación exitosa
con una API de versión, como
Build.FINGERPRINT. Si falla la actualización, comunícate con un administrador de TI.
Aprovisionamiento de Wi-Fi con EAP
En Android 10, los códigos QR y los datos NFC para la provisión de dispositivo pueden contener credenciales y elementos de configuración de EAP, como certificados. Cuando una persona escanea un código QR o presiona una etiqueta NFC, el dispositivo realiza automáticamente una autenticación 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_PROVISIONING_WIFI_SECURITY_TYPE
adicional con el valor "EAP". Para especificar la autenticación EAP, puedes agregar los siguientes elementos adicionales de aprovisionamiento a tu intent:
EXTRA_PROVISIONING_WIFI_EAP_METHODEXTRA_PROVISIONING_WIFI_IDENTITYEXTRA_PROVISIONING_WIFI_ANONYMOUS_IDENTITYEXTRA_PROVISIONING_WIFI_DOMAINEXTRA_PROVISIONING_WIFI_PHASE2_AUTHEXTRA_PROVISIONING_WIFI_USER_CERTIFICATEEXTRA_PROVISIONING_WIFI_CA_CERTIFICATE
Compatibilidad con DNS privados
Las organizaciones pueden usar DNS mediante 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 nombre compatiblesetGlobalPrivateDnsModeSpecifiedHost()para especificar el nombre de host de un servidor de nombres que admita 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 tuvo éxito. De lo contrario, muestra un error.
Para recuperar el modo de DNS privado y el host configurado en un dispositivo, llama a getGlobalPrivateDnsMode()
y getGlobalPrivateDnsHost().
Puedes evitar que los usuarios modifiquen la configuración de DNS privado agregando la
DISALLOW_CONFIG_PRIVATE_DNS
restricción para el usuario.
Exención del modo de bloqueo de VPN
Este modo le permite a un DPC bloquear cualquier tráfico de red que no use la VPN. Los administradores de dispositivos completamente administrados y perfiles de trabajo ahora 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 usarán únicamente otras redes.
Para eximir una app del modo de bloqueo, llama al nuevo
DevicePolicyManager método
setAlwaysOnVpnPackage()
que acepta una lista de los paquetes de apps exentos. Cualquier paquete de apps que el DPC agregue deberá instalarse en el dispositivo cuando se llame al método. Si se desinstala y se vuelve a instalar una app, se debe eximir nuevamente. Para acceder a las apps
que antes 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
isAlwaysOnVpnLockdownEnabled()
método.
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 transfiere uno o varios de los siguientes alcances:
DELEGATION_NETWORK_LOGGINGpara delegar el registro de la actividad de redDELEGATION_CERT_SELECTIONpara delegar la selección de certificados
En Android 10, se introduce la nueva clase
DelegatedAdminReceiver
para apps delegadas. El sistema usa este receptor de transmisiones para enviar devoluciones de llamada similares al DPC a las apps delegadas. Aquellas apps que recibieron 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
DelegatedAdminReceivera la app delegada. - Declara el
<receiver>en el manifiesto de la app y agrega una acción de filtro de intent para cada devolución de llamada; por ejemplo,ACTION_NETWORK_LOGS_AVAILABLEoACTION_CHOOSE_PRIVATE_KEY_ALIAS. - Protege el receptor de transmisiones con el
BIND_DEVICE_ADMINpermiso.
El siguiente fragmento muestra el manifiesto de la app de una sola app delegada, que administra 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 la 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 la subclase, implementa la
onNetworkLogsAvailable()
devolución de llamada siguiendo las instrucciones de Recuperar registros.
Las apps delegadas pueden llamar a los siguientes
DevicePolicyManager métodos
(pasando null para el argumento admin):
Para evitar la pérdida de registros, los DPC no deben habilitar el registro de red
si planean delegar a otra app. La app delegada debe activar y
reunir los registros de red. Una vez que un DPC delegue el registro de red, no recibirá
ninguna devolución de llamadaonNetworkLogsAvailable().
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 la 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
onChoosePrivateKeyAlias() devolución de llamada y muestra un alias para un certificado preferido
o, para solicitar 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 pasarse a dispositivos completamente administrados o a perfiles de trabajo. Las siguientes políticas arrojan una SecurityException cuando las invoca un administrador de dispositivos orientado a Android 10:
USES_POLICY_DISABLE_CAMERAUSES_POLICY_DISABLE_KEYGUARD_FEATURESUSES_POLICY_EXPIRE_PASSWORDUSES_POLICY_LIMIT_PASSWORD
Algunas aplicaciones usan administradores de dispositivos para la administración de los dispositivos de consumidores. Por ejemplo, para bloquear y limpiar un dispositivo perdido. Si deseas activar esta función, las siguientes políticas continúan disponibles:
Para obtener más información sobre estos cambios, lee Baja de las políticas de administración del dispositivo.
Funciones nuevas para apps
Las apps orientadas a Android 10 pueden buscar la complejidad del bloqueo de pantalla establecida en un dispositivo antes de mostrar información confidencial o iniciar funciones esenciales. Las apps que llaman
a la API de KeyChain aprovechan las mejoras de comportamiento, mientras que las funciones nuevas también están disponibles para apps de VPN.
Control de calidad del bloqueo de pantalla
A partir de Android 10, las apps con funciones esenciales que necesiten un bloqueo de pantalla pueden consultar la complejidad de este bloqueo en un dispositivo o perfil de trabajo. Aquellas apps que necesiten un bloqueo de pantalla más seguro pueden dirigir al usuario a la configuración del bloqueo de pantalla del sistema, lo que les permitirá actualizar su configuración de seguridad.
Para comprobar la calidad del bloqueo de pantalla:
- Agrega el nuevo permiso
REQUEST_PASSWORD_COMPLEXITYal 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 el adicional EXTRA_PASSWORD_COMPLEXITY (las opciones que no
cumplen con los requisitos de complejidad especificados en el intent adicional aparecen inhabilitadas). Los usuarios pueden elegir entre las opciones de bloqueo de pantalla disponibles o salir de la pantalla.
Recomendación: Muestra un mensaje en tu app antes de cargar la página del bloqueo de pantalla del sistema. Cuando se reanude la app, vuelve a llamar a
DevicePolicyManager.getPasswordComplexity()
Si aún se necesita un bloqueo de pantalla más seguro, restringe el acceso en lugar de solicitar varias veces 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
ProxyInfo instancia con un host y un puerto,
antes de llamar a
VpnService.Builder.setHttpProxy().
El sistema y varias bibliotecas con herramientas de redes usan esta configuración del proxy, pero el sistema no fuerza a las apps a cumplir con las solicitudes del proxy HTTP.
Para ver un ejemplo de código que muestra cómo establecer 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 always-on Vpn y si el lockdown mode está activo. Los nuevos métodos agregados en Android 10 pueden ayudarte a ajustar la interfaz de usuario. Por ejemplo, puedes desactivar el botón para desconectar si la VPN siempre activada controla el ciclo de vida de tu servicio.
Las apps de VPN pueden llamar a los siguientes VpnService
métodos después de conectarse al servicio
y establecer la interfaz local de la siguiente manera:
isAlwaysOn()para saber si el sistema inició el servicio gracias a la VPN siempre activadaisLockdownEnabled()para saber si el sistema está bloqueando conexiones que no usan la VPN
El estado siempre activado no cambia mientras se ejecuta tu servicio, pero sí podría cambiar el estado del modo de bloqueo.
Mejoras de KeyChain
En Android 10, se incluyen varias mejoras relacionadas con la
KeyChain API.
Cuando una app llama a KeyChain.choosePrivateKeyAlias(), Android 10 y los dispositivos 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 de 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 concordancia disponibles o certificados instalados en el dispositivo, no se muestra el mensaje de selección al usuario.
Además, KeyChain ya no
requiere que un dispositivo tenga un bloqueo de pantalla para importar claves o certificados de CA.