Qué incluye Android 9 para apps empresariales

En esta página, se proporciona una descripción general de las APIs, las funciones y los cambios de comportamiento en el ámbito empresarial disponibles en Android 9.

Interfaz de usuario del perfil de trabajo

Android 9 (nivel de API 28) incluye cambios en la interfaz de usuario en el selector predeterminado para ayudar a los usuarios a separar las apps personales de las de trabajo. Los fabricantes de dispositivos que admiten esto pueden presentar las apps de los usuarios en pestañas personales y de trabajo separadas. También facilitamos que los usuarios de los dispositivos activen y desactiven el perfil de trabajo con un interruptor en la pestaña de trabajo del selector.

Figura 1. La pestaña personal y de trabajo del selector predeterminado con el interruptor de perfil de trabajo

Cuando se aprovisionan perfiles de trabajo y dispositivos administrados, Android 9 incluye ilustraciones animadas para ayudar a los usuarios de dispositivos a comprender estas funciones.

Cambia de app entre perfiles

Android 9 incluye API para iniciar otra instancia de una app en un perfil diferente a fin de ayudar a los usuarios a cambiar de una cuenta a otra. Por ejemplo, una app de correo electrónico puede proporcionar una IU que permita al usuario alternar entre el perfil personal y el de trabajo para acceder a dos cuentas de correo electrónico. Todas las apps pueden llamar a estas APIs para iniciar la actividad principal de la misma app si ya está instalada en el otro perfil. Si quieres agregar a tu app el cambio de cuenta entre perfiles, sigue los pasos que se indican a continuación para llamar a los métodos de la clase CrossProfileApps:

  1. Llama a getTargetUserProfiles() para obtener una lista de perfiles en los que puedes iniciar otra instancia de la app. Este método verifica que la app esté instalada en los perfiles.
  2. Llama a getProfileSwitchingIconDrawable() para obtener un ícono que puedas usar para representar otro perfil.
  3. Llama a getProfileSwitchingLabel() para obtener texto localizado que le solicite al usuario cambiar de perfil.
  4. Llama a startMainActivity() para iniciar una instancia de tu app en otro perfil.

Verifica que la actividad principal que quieras iniciar esté declarada en el archivo de manifiesto de tu app, con una acción de intent ACTION_MAIN y que incluya una categoría de intent CATEGORY_LAUNCHER.

Cómo activar o desactivar perfiles de trabajo de forma programática

El selector predeterminado (o las apps que tienen el permiso MANAGE_USERS o MODIFY_QUIET_MODE) puede llamar a UserManager.requestQuietModeEnabled() para activar o desactivar el perfil de trabajo. Puedes inspeccionar el valor que se muestra para saber si el usuario debe confirmar sus credenciales antes de que cambie el estado. Como es posible que el cambio no ocurra al instante, escucha la transmisión ACTION_MANAGED_PROFILE_AVAILABLE o ACTION_MANAGED_PROFILE_UNAVAILABLE para saber cuándo actualizar la interfaz de usuario.

Tu app puede verificar el estado del perfil de trabajo llamando a UserManager.isQuietModeEnabled().

Bloquea cualquier app en un dispositivo

A partir de Android 9, los propietarios de dispositivos y perfiles (de usuarios secundarios) pueden bloquear cualquier app en la pantalla de un dispositivo al poner la app en el modo de tareas bloqueadas. Antes, los desarrolladores de apps tenían que agregar compatibilidad con el modo de tareas bloqueadas en sus apps. Android 9 también extiende las APIs de bloqueo de tarea a los propietarios de perfiles de usuarios secundarios no afiliados. Sigue los pasos que se indican a continuación para bloquear una app en la pantalla:

  1. Llama a DevicePolicyManager.setLockTaskPackages() a fin de incluir apps en la lista de entidades permitidas para el modo de tareas bloqueadas.
  2. Llama a ActivityOptions.setLockTaskEnabled() para iniciar una app incluida en la lista de entidades permitidas en el modo de tareas bloqueadas.

Para detener una app en el modo de tareas bloqueadas, quítala de la lista de entidades permitidas del modo de tareas bloqueadas mediante DevicePolicyManager.setLockTaskPackages().

Cómo habilitar funciones de la IU del sistema

Cuando está habilitado el modo de tareas bloqueadas, los propietarios del dispositivo y del perfil pueden habilitar ciertas funciones de la IU del sistema llamando a DevicePolicyManager.setLockTaskFeatures() y pasando un campo de bits de las siguientes marcas de función:

Puedes llamar a DevicePolicyManager.getLockTaskFeatures() para obtener la lista de funciones disponibles en un dispositivo cuando el modo de tareas bloqueadas está habilitado. Cuando un dispositivo sale del modo de tareas bloqueadas, vuelve al estado que exigen otras políticas.

Suprimir diálogos de error

En algunos entornos, como las demostraciones para minoristas o las pantallas de información pública, es posible que no quieras mostrar los diálogos de error a los usuarios. Un controlador de políticas de dispositivo (DPC) puede suprimir los diálogos de error del sistema para las apps con fallas o que no responden agregando la restricción de usuario DISALLOW_SYSTEM_ERROR_DIALOGS. Cuando la aplica el propietario del dispositivo, esta restricción afecta a todos los diálogos, pero solo se suprimen los diálogos de error que se muestran en el usuario principal o secundario cuando la aplican los propietarios de perfiles. Esta restricción no afecta los perfiles de trabajo.

En Android 9, las apps que se ejecutan en el modo de pantalla completa envolvente no muestran el cuadro de recordatorio en el modo de tareas bloqueadas. La burbuja de recordatorio es un panel que se muestra a los usuarios (en el primer inicio) y que explica cómo salir del modo envolvente.

Cómo admitir varios usuarios en dispositivos dedicados

Android 9 presenta el concepto de un usuario efímero para dispositivos dedicados (antes llamados dispositivos COSU). Los usuarios efímeros son usuarios a corto plazo destinados a casos en los que varios usuarios comparten un solo dispositivo dedicado. Esto incluye sesiones de usuario públicas en dispositivos como kioscos de registro de entrada de hoteles o bibliotecas, así como sesiones persistentes entre un conjunto fijo de usuarios en dispositivos, por ejemplo, los trabajadores por turnos.

Los usuarios efímeros se deben crear en segundo plano. Se crean como usuarios secundarios en un dispositivo y se quitan (junto con las apps y los datos asociados) cuando se detienen, se cambian o se reinicia el dispositivo. Para crear un usuario efímero, los propietarios de los dispositivos pueden hacer lo siguiente:

  1. Establece la marca MAKE_USER_EPHEMERAL cuando llames a DevicePolicyManager.createAndManageUser().
  2. Llama a DevicePolicyManager.startUserInBackground() para iniciar el usuario efímero en segundo plano.

Ten en cuenta que las apps orientadas a Android 9 deben detectar UserManager.UserOperationException cuando llaman a createAndManageUser(). Llama al método getUserOperationResult() de la excepción para averiguar por qué no se creó el usuario.

Recibir notificaciones de eventos

El DeviceAdminReceiver recibe notificaciones de los siguientes eventos:

Muestra mensajes de eventos a los usuarios

Los propietarios de dispositivos pueden configurar los mensajes que se muestran a los usuarios cuando inician y finalizan sus sesiones:

Cerrar la sesión y detener usuarios

Los propietarios de dispositivos pueden usar DevicePolicyManager.setLogoutEnabled() a fin de especificar si el cierre de sesión está habilitado para los usuarios secundarios. Para verificar si el cierre de sesión está habilitado, llama a DevicePolicyManager.isLogoutEnabled().

Los propietarios de perfiles de los usuarios secundarios pueden llamar a DevicePolicyManager.logoutUser() para detener al usuario secundario y volver al usuario principal.

Los propietarios de dispositivos pueden usar DevicePolicyManager.stopUser() para detener a un usuario secundario especificado.

Almacenamiento en caché de paquetes

Para optimizar el aprovisionamiento de usuarios en dispositivos compartidos con un conjunto fijo de usuarios, como dispositivos para trabajadores por turnos, es posible almacenar en caché los paquetes necesarios para las sesiones multiusuario:

  1. Llama a DevicePolicyManager.setKeepUninstalledPackages() para especificar la lista de paquetes que se conservarán como APKs. Para recuperar una lista de estos paquetes, llama a DevicePolicyManager.getKeepUninstalledPackages().

  2. Llama a DevicePolicyManager.installExistingPackage() para instalar un paquete que se mantuvo después de la eliminación mediante setKeepUninstalledPackages().

Métodos y constantes adicionales

Android 9 también incluye los siguientes métodos y constantes para admitir aún más las sesiones de usuario en dispositivos compartidos:

Borrar datos del paquete y quitar cuentas

Los propietarios de dispositivos y perfiles pueden llamar a clearApplicationUserData() para borrar los datos del usuario de un paquete determinado. Para quitar una cuenta de AccountManager, los propietarios del dispositivo y el perfil pueden llamar a removeAccount().

Restricciones del usuario y mayor control de la configuración

Android 9 presenta un conjunto de restricciones de usuario para DPC, además de la capacidad de configurar APNS, la hora, la zona horaria y la configuración del sistema en un dispositivo.

Configurar APNS

Los propietarios de dispositivos pueden usar los siguientes métodos en la clase DevicePolicyManager para configurar APNS en un dispositivo:

Configurar la hora y la zona horaria

Los propietarios de dispositivos pueden usar los siguientes métodos en la clase DevicePolicyManager para configurar la hora y la zona horaria de un dispositivo:

Aplicar restricciones de usuario a parámetros de configuración importantes

En Android 9, se agregan restricciones del usuario para inhabilitar funciones y parámetros de configuración del sistema. Para agregar una restricción, llama a DevicePolicyManager.addUserRestriction() con una de las siguientes constantes UserManager:

Si se aplican DISALLOW_CONFIG_BRIGHTNESS y DISALLOW_CONFIG_SCREEN_TIMEOUT en un dispositivo, los propietarios de dispositivos aún pueden configurar el brillo de la pantalla, el modo de brillo de la pantalla y el tiempo de espera de la pantalla en el dispositivo mediante la API DevicePolicyManager.setSystemSetting().

Datos medidos

Los propietarios de dispositivos y perfiles pueden evitar que las apps usen las redes de datos medidos de un dispositivo. Una red se considera de uso medido cuando el usuario es sensible al uso intensivo de datos debido a problemas de costo, límites de datos, batería y rendimiento. Para evitar que las apps usen redes de uso medido, llama a DevicePolicyManager.setMeteredDataDisabledPackages() y pasa una lista de nombres de paquetes. Para recuperar las apps restringidas, llama a DevicePolicyManager.getMeteredDataDisabledPackages().

Para obtener más información sobre los datos medidos en Android, consulta Cómo optimizar el uso de datos de la red.

Migra los DPC

Los controladores de políticas de dispositivos (DPC) pueden transferir la propiedad de un dispositivo o perfil de trabajo a otro DPC. Puedes transferir la propiedad para mover algunas funciones a la API de Android Management, migrar dispositivos desde tu DPC heredado o ayudar a administradores de TI a migrar a tu EMM. Debido a que solo estás cambiando la propiedad del DPC, no puedes usar esta función para cambiar el tipo de administración, por ejemplo, si migras de un dispositivo administrado a un perfil de trabajo o viceversa.

Puedes usar el recurso XML de las políticas de administración de dispositivos para indicar que esta versión de tu DPC admite la migración. Un DPC de destino indica que puede recibir la propiedad mediante la inclusión de un elemento llamado <support-transfer-ownership>. En el siguiente ejemplo, se muestra cómo puedes hacerlo en el archivo en formato XML de administración de dispositivos de tu DPC:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
    <support-transfer-ownership />
    <uses-policies>
        <limit-password />
        <watch-login />
        <reset-password />
    </uses-policies>
</device-admin>

Los DPC que desean migrar la propiedad a una nueva app de DPC pueden llamar al método supportsTransferOwnership() de DeviceAdminInfo para verificar si la versión del DPC de destino admite la migración. Antes de transferir la propiedad, es responsabilidad del DPC de origen verificar el DPC de destino comparando las firmas de la app. La clase PackageManager incluye métodos para trabajar con firmas de código,

Android mantiene las políticas del sistema y del usuario del DPC de origen mediante una transferencia de propiedad; los DPC no necesitan migrarlas. Un DPC de origen puede pasar datos personalizados al DPC de destino mediante pares clave-valor en un PersistableBundle. Después de una transferencia exitosa, el DPC de destino puede recuperar estos datos llamando a DevicePolicyManager.getTransferOwnershipBundle().

Los pasos para transferir la propiedad de un dispositivo administrado o un perfil de trabajo son los mismos:

  1. El DPC de origen verifica que la versión del DPC de destino admita la migración y confirma que la firma de la app del DPC de destino coincida con un valor esperado.
  2. El DPC de origen llama a transferOwnership() para iniciar la transferencia.
  3. El sistema convierte al DPC de destino en el administrador activo y lo establece como el propietario del dispositivo administrado o del perfil de trabajo.
  4. El DPC de destino recibe la devolución de llamada onTransferOwnershipComplete() y puede configurarse a sí mismo usando valores del argumento bundle.
  5. Si algo sale mal con la transferencia, el sistema revierte la propiedad al DPC de origen. Si el DPC de origen necesita confirmar que la transferencia de propiedad se realizó correctamente, llama a isAdminActive() para verificar que el DPC de origen ya no sea el administrador activo.

Todas las apps que se ejecutan en el perfil de trabajo reciben la transmisión ACTION_PROFILE_OWNER_CHANGED cuando cambia el propietario del perfil. Las apps que se ejecutan en un dispositivo administrado reciben la transmisión de ACTION_DEVICE_OWNER_CHANGED cuando cambia el propietario del dispositivo.

Perfiles de trabajo en dispositivos completamente administrados

La transferencia de dos instancias de un DPC que se ejecuta como propietario del dispositivo y propietario del perfil se realiza en dos etapas. Cuando el perfil personal y el de trabajo estén afiliados, completa la transferencia en el siguiente orden:

  1. Primero, transfiere la propiedad del perfil de trabajo.
  2. Espera a que la devolución de llamada onTransferAffiliatedProfileOwnershipComplete() de DeviceAdminReceiver confirme que el perfil de trabajo se transfirió al DPC de destino.
  3. Por último, transfiere la propiedad del dispositivo administrado al DPC de destino.

Cómo posponer actualizaciones inalámbricas (OTA)

Los propietarios de dispositivos pueden posponer las actualizaciones inalámbricas del sistema hasta por 90 días para congelar la versión del SO que se ejecuta en estos dispositivos durante períodos críticos (como festividades). El sistema aplica un búfer obligatorio de 60 días después de cualquier período sin actualización para evitar que el dispositivo se bloquee de forma indefinida.

Durante un período sin actualización:

  • Los dispositivos no reciben notificaciones sobre actualizaciones inalámbricas pendientes.
  • Los dispositivos no instalan actualizaciones inalámbricas en el SO.
  • Los usuarios de dispositivos no pueden buscar actualizaciones inalámbricas en la configuración de forma manual.

Para establecer un período sin actualización, llama a SystemUpdatePolicy.setFreezePeriods(). Debido a que el período sin actualización se repite anualmente, las fechas de inicio y finalización del período se representan con números enteros que cuentan la cantidad de días desde el inicio del año. El día de inicio debe comenzar al menos 60 días después del final de cualquier período sin actualización anterior. Los propietarios de dispositivos pueden llamar a SystemUpdatePolicy.getFreezePeriods() para obtener una lista de los períodos de suspensión configurados previamente en el objeto de la política de actualización del sistema. Se actualizó DevicePolicyManager.getSystemUpdatePolicy() para mostrar los períodos sin actualización que estableció el propietario del dispositivo.

Cómo restringir el uso compartido en un perfil de trabajo

Los propietarios de perfiles pueden evitar que los usuarios compartan datos personales en un perfil de trabajo en el dispositivo agregando la restricción de usuarios DISALLOW_SHARE_INTO_MANAGED_PROFILE. Esta restricción evita los siguientes manejos y usos compartidos vinculados a intents:

  • Apps de perfil personal que comparten datos y archivos con apps del perfil de trabajo
  • Apps del perfil de trabajo que seleccionan elementos del perfil personal, como fotos o archivos

Después de configurar esta restricción, tu DPC aún puede permitir intents de actividad de perfiles sincronizados llamando a addCrossProfileIntentFilter().

Claves y certificados de máquina protegidos por hardware

Android 9 agrega APIs que te ayudan a trabajar con claves y certificados que puedes combinar para identificar dispositivos de forma segura. Un DPC que se ejecuta en los modos de propietario de perfil o propietario de dispositivo, o un instalador de certificados delegados, puede completar las siguientes tareas:

  • Genera claves y certificados en el hardware seguro (como un entorno de ejecución confiable (TEE) o un Elemento seguro (SE)) del dispositivo Android. Las claves generadas nunca salen del hardware seguro y se pueden usar desde Android KeyChain. Llama a DevicePolicyManager.generateKeyPair() y proporciona el algoritmo (consulta KeyPairGenerator) y los IDs de hardware que desees certificar, como el número de serie o IMEI. Para obtener más información sobre los cambios en el hardware seguro, consulta las Mejoras de seguridad de Android 9.
  • Asocia un certificado a una clave existente generada por el dispositivo. Llama a DevicePolicyManager.setKeyPairCertificate() proporcionando el alias de la clave existente y la cadena de certificados, comenzando con el certificado de entidad final e incluyendo la cadena de confianza en orden.
  • Confirma que el hardware seguro proteja la clave antes de usarla. Para verificar qué mecanismos protegen la clave, sigue los pasos que se indican en Certificación de claves.
  • Los propietarios de dispositivos y los instaladores de certificados delegados pueden recibir una declaración firmada de los ID de hardware de los dispositivos con las versiones del sistema Android. Llama a DevicePolicyManager.generateKeyPair() y pasa uno o más de ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI o ID_TYPE_MEID en el argumento idAttestationFlags. El certificado que se muestra incluye los ID de hardware en el registro de certificación. Si no quieres que se incluyan los IDs de hardware, pasa 0. Los propietarios de perfiles solo pueden recibir información del fabricante (pasando ID_TYPE_BASE_INFO). Para verificar que el dispositivo pueda certificar IDs, llama a isDeviceIdAttestationSupported().
  • Para evitar que los usuarios de dispositivos usen claves empresariales de forma inadecuada (en tareas no empresariales), anula la selección de los certificados de claves. El sistema no incluye certificados que no se puedan seleccionar en el panel de selección. En el método de devolución de llamada DeviceAdminReceiver.onChoosePrivateKeyAlias(), muestra el alias a la clave empresarial para que el sistema seleccione automáticamente el certificado en nombre del usuario. Para que no se pueda seleccionar una clave, llama a los siguientes métodos DevicePolicyManager:

Cuando se combinan estas APIs, las empresas pueden identificar los dispositivos de forma segura y confirmar su integridad antes de proporcionar acceso:

  1. El dispositivo Android genera una nueva clave privada en el hardware seguro. Debido a que la clave privada nunca abandona el hardware seguro, se mantiene su carácter de secreta.
  2. El dispositivo usa la clave para crear y enviar una solicitud de firma de certificado (CSR) al servidor. La CSR incluye el registro de certificación que contiene los ID de los dispositivos.
  3. El servidor valida la cadena de certificados (con permisos de administrador en un certificado de Google) y extrae los metadatos del dispositivo del registro de certificación.
  4. El servidor confirma que el hardware seguro protege la clave privada y que los IDs del dispositivo coinciden con los registros de la empresa. El servidor también puede verificar que las versiones del sistema Android y los parches cumplan con los requisitos.
  5. El servidor genera un certificado a partir de la CSR y lo envía al dispositivo.
  6. El dispositivo vincula el certificado con la clave privada (que permanece en el hardware seguro), lo que permite que las apps se conecten a servicios empresariales.

Más API, funciones y cambios relacionados con la seguridad

IDs para los registros de seguridad y los registros de red

Android 9 incluye IDs en registros de seguridad y actividad de red. El ID numérico aumenta monótonamente para cada evento, lo que facilita que los administradores de TI detecten brechas en sus registros. Debido a que los registros de seguridad y los registros de red son recopilaciones independientes, el sistema mantiene valores de ID separados.

Llama a SecurityEvent.getId(), DnsEvent.getId() o ConnectEvent.getId() para obtener el valor del ID. El sistema restablece el ID cada vez que un DPC habilita el registro o cuando se reinicia el dispositivo. Los registros de seguridad recuperados con una llamada a DevicePolicyManager.retrievePreRebootSecurityLogs() no incluyen estos ID.

Registro de seguridad

El registro de seguridad asigna a cada SecurityEvent un nivel de registro. Para obtener el nivel de registro, llama a getLogLevel(). Este método muestra un valor a nivel de registro que puede ser uno de los siguientes: LEVEL_INFO, LEVEL_WARNING o LEVEL_ERROR.

Android 9 registra los eventos que se indican en la siguiente tabla en registros de seguridad. Para verificar la etiqueta de un evento, llama a getTag(). Para recuperar los datos del evento, llama a getData().

Etiqueta La descripción del evento
TAG_CERT_AUTHORITY_INSTALLED Un intento de instalar un nuevo certificado raíz en el almacenamiento de credenciales del sistema
TAG_CERT_AUTHORITY_REMOVED Un intento de quitar un certificado raíz del almacenamiento de credenciales del sistema.
TAG_CERT_VALIDATION_FAILURE Un certificado de Wi-Fi no superó la verificación de validación durante la conexión.
TAG_CRYPTO_SELF_TEST_COMPLETED El sistema completó la autoprueba criptográfica.
TAG_KEYGUARD_DISABLED_FEATURES_SET Una app de administración inhabilita funciones de la pantalla de bloqueo de un dispositivo o perfil de trabajo.
TAG_KEY_DESTRUCTION Se intentó borrar una clave criptográfica.
TAG_KEY_GENERATED Un intento de generar una clave criptográfica nueva.
TAG_KEY_IMPORT Se intentó importar una clave criptográfica nueva.
TAG_KEY_INTEGRITY_VIOLATION Android detectó una clave de encriptación o autenticación dañada.
TAG_LOGGING_STARTED Se inició la grabación del registro de seguridad.
TAG_LOGGING_STOPPED El registro de seguridad dejó de grabar.
TAG_LOG_BUFFER_SIZE_CRITICAL El búfer del registro de seguridad alcanzó el 90% de su capacidad.
TAG_MAX_PASSWORD_ATTEMPTS_SET Una app de administración estableció la cantidad permitida de intentos para ingresar contraseñas incorrectas.
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET Una app de administración establece un tiempo de espera máximo para el bloqueo de pantalla.
TAG_MEDIA_MOUNT El dispositivo activó un medio de almacenamiento extraíble.
TAG_MEDIA_UNMOUNT El dispositivo desmontó los medios de almacenamiento extraíbles.
TAG_OS_SHUTDOWN Se apagó el sistema Android.
TAG_OS_STARTUP Se inició el sistema Android.
TAG_PASSWORD_COMPLEXITY_SET Una app de administración estableció requisitos de complejidad para las contraseñas.
TAG_PASSWORD_EXPIRATION_SET Una app de administración establece el tiempo de vencimiento de la contraseña.
TAG_PASSWORD_HISTORY_LENGTH_SET Una app de administración estableció la duración de un historial de contraseñas para impedir que los usuarios reutilicen contraseñas anteriores.
TAG_REMOTE_LOCK Una app de administración bloqueó el dispositivo o el perfil de trabajo.
TAG_USER_RESTRICTION_ADDED Una app de administración estableció una restricción de usuarios.
TAG_USER_RESTRICTION_REMOVED Una app de administración quitó una restricción de usuarios.
TAG_WIPE_FAILURE Se produjo un error al limpiar un dispositivo o un perfil de trabajo.

Comprobación de la pantalla de bloqueo del perfil de trabajo

A partir de Android 9, los propietarios de perfiles pueden requerir que los usuarios definan una comprobación de pantalla de bloqueo independiente para su perfil de trabajo mediante la restricción de usuario de DISALLOW_UNIFIED_PASSWORD. Para verificar si un usuario tiene configurada la misma verificación de pantalla de bloqueo para su dispositivo y perfil de trabajo, llama a DevicePolicyManager.isUsingUnifiedPassword().

Si un dispositivo tiene una pantalla de bloqueo independiente del perfil de trabajo, DevicePolicyManager.setMaximumTimeToLock() solo establece un tiempo de espera de pantalla de bloqueo para el perfil de trabajo en lugar de para todo el dispositivo.

Acceso a las herramientas para desarrolladores

Para ayudar a mantener los datos laborales en el perfil de trabajo, la herramienta Android Debug Bridge (adb) no puede acceder a los directorios ni los archivos del perfil de trabajo.

Compatibilidad con más opciones biométricas

Android 9 agrega control detallado sobre la autenticación biométrica de hardware en la pantalla de bloqueo de un perfil de trabajo. Llama al método DevicePolicyManager.setKeyguardDisabledFeatures() existente con KEYGUARD_DISABLE_FACE y KEYGUARD_DISABLE_IRIS. Para inhabilitar todos los métodos de autenticación biométrica que proporciona el dispositivo, agrega KEYGUARD_DISABLE_BIOMETRICS.

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

Android 9 marca las políticas que se mencionan a continuación como obsoletas para los DPC mediante el uso de device admin. Las políticas continúan funcionando en Android 9 como antes. A partir de la versión de Android 10, las mismas políticas arrojarán una SecurityException cuando las invoque un administrador del dispositivo.

Algunas aplicaciones usan administradores de dispositivos para la administración de dispositivos de consumidores. Por ejemplo, para bloquear y limpiar un dispositivo perdido. Las siguientes políticas seguirán estando disponibles para habilitar esta función:

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

Inscripción en código QR optimizada

Biblioteca de código QR integrada

Android 9 incluye una biblioteca de códigos QR para optimizar el aprovisionamiento de dispositivos con códigos QR. Los administradores de TI ya no tienen que ingresar manualmente los detalles de la red Wi-Fi para configurar un dispositivo. En cambio, con Android 9, es posible incluir esos detalles de Wi-Fi en un código QR. Cuando un administrador de TI escanea el código QR con un dispositivo empresarial, este se conecta automáticamente a la red Wi-Fi y comienza al proceso de aprovisionamiento sin ninguna entrada manual adicional.

El método de provisión de código QR admite los siguientes elementos adicionales de provisión para especificar los detalles de Wi-Fi:

Configura la fecha y la zona horaria con servicios adicionales de aprovisionamiento

El método de aprovisionamiento de código QR admite elementos de provisión adicionales para configurar la hora y la zona horaria de un dispositivo:

Opciones de datos para la limpieza

Los administradores de dispositivos pueden mostrar un mensaje personalizado a los usuarios cuando quitan un perfil de trabajo o un usuario secundario. El mensaje ayuda a los usuarios del dispositivo a comprender que su administrador de TI quitó el perfil de trabajo o el usuario secundario. Llama a wipeData(int, CharSequence) y proporciona un mensaje explicativo breve. Cuando el usuario principal o el propietario del dispositivo lo llama, el sistema no muestra un mensaje y comienza a restablecer la configuración de fábrica del dispositivo.

Para quitar datos de suscripción de una SIM eUICC incorporada, llama a wipeData() e incluye WIPE_EUICC en el argumento flags.

Métodos para propietarios de perfiles afiliados

Los siguientes métodos están disponibles para los propietarios de perfiles afiliados: