Qué incluye Android 9 para apps empresariales

En esta página, se proporciona una descripción general de las APIs, las funciones y el comportamiento de las empresas. cambios 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 la configuración selector para ayudar a los usuarios a separar las aplicaciones personales de las de trabajo. Fabricantes de dispositivos que respaldan esto puede presentar a los usuarios en pestañas separadas del trabajo y personales. También facilitamos la activación y desactivación del perfil de trabajo para los usuarios de dispositivos incluido un interruptor en la pestaña de trabajo del selector.

Figura 1: Las pestañas personales y de trabajo del selector predeterminado con el interruptor del 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.

Cómo cambiar de app en un perfil

Android 9 incluye APIs para iniciar otra instancia de una app en una ubicación diferente para ayudar a los usuarios a cambiar de cuenta. Por ejemplo, en una app de correo electrónico proporcionar una IU que permita al usuario cambiar entre el perfil personal y el trabajo para acceder a dos cuentas de correo electrónico. Todas las apps pueden llamar a estas APIs para iniciar actividad principal de la misma app si ya está instalada en el otro perfil. Para agrega el cambio de cuentas de perfiles sincronizados a tu app, sigue los pasos que se indican a continuación para llamar métodos del 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 texto localizado que le solicita al usuario que cambie de perfil
  4. Llama a startMainActivity() para iniciar una instancia de la app en otro perfil.

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

Activa o desactiva los perfiles de trabajo de manera programática

El selector predeterminado (o las apps que tengan el permiso MANAGE_USERS o MODIFY_QUIET_MODE) puede activar o desactivar el perfil de trabajo llamando UserManager.requestQuietModeEnabled() Puedes inspeccionarán el valor de retorno para saber si el usuario debe confirmar su las credenciales antes de que cambie el estado. Porque el cambio podría no ocurrir al instante, escucha la 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 UserManager.isQuietModeEnabled()

Bloquea cualquier app en un dispositivo

A partir de Android 9, los propietarios de dispositivos y perfiles (de usuarios secundarios) Puedes 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 las tareas de bloqueo automático en sus apps. Android 9 también extiende la tarea de bloqueo APIs para perfiles de propietarios de usuarios secundarios no afiliados. Sigue estos pasos: Para bloquear una app en la pantalla, haz lo siguiente:

  1. Llama a DevicePolicyManager.setLockTaskPackages() para 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 del modo de tareas bloqueadas incluir en la lista de entidades permitidas con DevicePolicyManager.setLockTaskPackages()

Cómo habilitar las funciones de la IU del sistema

Cuando el modo de tareas bloqueadas está habilitado, los propietarios de dispositivos y perfiles pueden habilitar ciertas funciones de la IU del sistema en el dispositivo llamando DevicePolicyManager.setLockTaskFeatures() y pasar un 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 está activado el modo de tareas bloqueadas habilitado. Cuando un dispositivo sale del modo de tareas bloqueadas, regresa al estado que exigen otras políticas de dispositivo.

Suprimir diálogos de error

En algunos entornos, como para las demostraciones minoristas o la información pública es posible que no quieras mostrar diálogos de error a los usuarios. Una política de dispositivo El controlador (DPC) puede suprimir los diálogos de error del sistema si falla o no responde de las apps agregando Usuario de DISALLOW_SYSTEM_ERROR_DIALOGS restricción. Cuando la aplica el propietario de un 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 los propietarios de perfiles aplican la restricción. Esta restricción no afectan los perfiles de trabajo.

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

Admitir varios usuarios en dispositivos exclusivos

Android 9 introduce el concepto de usuario efímero para las aplicaciones dispositivos (antes denominados dispositivos COSU). Los usuarios efímeros usuarios a corto plazo destinados a casos en los que varios usuarios comparten un mismo o un dispositivo específico. Esto incluye las sesiones de usuario públicas en dispositivos como la biblioteca o quioscos de registro de hospitalidad, así como sesiones persistentes entre una 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 datos) cuando se detienen, se cambian o el dispositivo se reinicia. Para crear un como usuario efímero, los propietarios de dispositivos pueden hacer lo siguiente:

  1. Establece la marca MAKE_USER_EPHEMERAL cuando realices llamadas 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 durante las llamadas createAndManageUser() Llama al método getUserOperationResult() para descubrir por qué no se creó el usuario.

Recibir notificaciones de eventos

El DeviceAdminReceiver recibe notificaciones del siguientes eventos:

Muestra mensajes de eventos a los usuarios

Los propietarios de los dispositivos pueden configurar los mensajes que se mostrarán a los usuarios cuando iniciar y finalizar sus sesiones:

Cerrar la sesión y detener usuarios

Los propietarios de dispositivos pueden usar DevicePolicyManager.setLogoutEnabled() para especificar si el cierre de sesión está habilitado para los usuarios secundarios. Para comprobar si está habilitada la opción de salir, llama DevicePolicyManager.isLogoutEnabled()

Los propietarios del perfil de usuarios secundarios pueden llamar DevicePolicyManager.logoutUser() para detener el usuario secundario y regresar al usuario principal.

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

Almacenamiento en caché de paquetes

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

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

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

Métodos y constantes adicionales

Android 9 también incluye los siguientes métodos y constantes para brindar mayor compatibilidad Sesiones de usuario en dispositivos compartidos:

Borra los datos del paquete y quita las cuentas

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

Restricciones para los usuarios y mayor control de la configuración

Android 9 presenta un conjunto de restricciones de usuario para DPC, así como el capacidad para configurar APN, hora y zona horaria, y ajustes del sistema en un dispositivo.

Configurar APN

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

Configura la hora y la zona horaria

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

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

En Android 9, se agregan restricciones de usuario para inhabilitar funciones y parámetros de configuración del sistema. Para agregar una restricción, llamar DevicePolicyManager.addUserRestriction() por uno de los Las siguientes constantes UserManager:

Si es DISALLOW_CONFIG_BRIGHTNESS y Se aplica de manera forzosa DISALLOW_CONFIG_SCREEN_TIMEOUT en un dispositivo, los propietarios de dispositivos aún pueden configurar la pantalla brillo, brillo de la pantalla modo y el tiempo de espera de la pantalla en el dispositivo con la API DevicePolicyManager.setSystemSetting().

Datos medidos

Los propietarios de dispositivos y perfiles pueden evitar que las apps usen el redes de datos medidos. Una red se considera de uso medido cuando el usuario son sensibles al uso intensivo de datos debido al costo, los límites de datos o el consumo problemas de rendimiento. Para evitar que las aplicaciones usen redes de uso medido, llama DevicePolicyManager.setMeteredDataDisabledPackages() pasar una lista de nombres de paquetes. Para recuperar las apps restringidas actualmente, llama DevicePolicyManager.getMeteredDataDisabledPackages()

Para obtener más información sobre los datos medidos en Android, consulta el artículo Cómo optimizar los datos de red. Uso.

Migrar DPC

Los controladores de políticas del dispositivo (DPC) pueden transferir la propiedad de un dispositivo o de trabajo a otro DPC. Puedes transferir la propiedad para mover algunos elementos. a la Administración de Android API para migrar dispositivos tu DPC heredado o para ayudar a los administradores de TI a migrar a tu EMM. Porque estás cambiando la propiedad del DPC, no puedes usar esta función para cambiar el tipo de administrada, por ejemplo, migrar de un dispositivo administrado a un perfil de trabajo o viceversa.

Puedes usar el recurso XML de device admin policies para indica que esta versión de tu DPC admite la migración. Un DPC de destino indica que puede recibir propiedad al incluir un elemento llamado <support-transfer-ownership> El siguiente ejemplo muestra cómo podrías hacer esto en el archivo XML del administrador 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 quieran migrar la propiedad a una nueva app de DPC pueden comprobar si un DPC de destino versión admite la migración llamando al método DeviceAdminInfo supportsTransferOwnership() Antes de realizar la transferencia propiedad, es responsabilidad del DPC de origen verificar el DPC de destino comparar firmas de apps La clase PackageManager incluye para trabajar con firmas de firma de código.

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

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

  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 coincide con un valor esperado.
  2. El DPC de origen llama a transferOwnership() para iniciar la de datos entre sitios.
  3. El sistema convierte al DPC de destino en administrador activo y establece como propietario del dispositivo administrado o del perfil de trabajo.
  4. El DPC de destino recibe la devolución de llamada onTransferOwnershipComplete() y puede configurar con valores del argumento bundle.
  5. Si algo sale mal con la transferencia, el sistema revierte la propiedad a el DPC de origen. Si tu DPC de origen debe confirmar que la transferencia de propiedad correctamente, llama a isAdminActive() para comprobar que el DPC de origen ya no es el administrador activo.

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

Perfiles de trabajo en dispositivos completamente administrados

Transferencia de dos instancias de un DPC que se ejecuta como propietario del dispositivo y propietario del perfil en dos etapas. Cuando el perfil personal y el de trabajo se afiliado, completa la transferencia en el siguiente orden:

  1. Primero, transfiere la propiedad del perfil de trabajo.
  2. Espera la devolución de llamada de DeviceAdminReceiver onTransferAffiliatedProfileOwnershipComplete() para confirmar 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 lo siguiente: congelar la versión del SO que se ejecuta en estos dispositivos durante períodos críticos (como días festivos). El sistema aplica un búfer obligatorio de 60 días después de cualquier durante el período de bloqueo para evitar que el dispositivo se congele indefinidamente.

Durante un período sin actualización:

  • Los dispositivos no reciben notificaciones sobre las actualizaciones OTA pendientes.
  • Los dispositivos no instalan actualizaciones OTA al SO.
  • Los usuarios de dispositivos no pueden buscar manualmente actualizaciones OTA en Configuración.

Para establecer un período sin actualización, llama SystemUpdatePolicy.setFreezePeriods() Porque el frío el período se repite anualmente, se representan las fechas de inicio y finalización del período de números enteros que cuentan el número de días desde que comienza el año El día de inicio debe deben comenzar al menos 60 días después del final de cualquier período sin actualización anterior. Dispositivo los propietarios pueden llamar a SystemUpdatePolicy.getFreezePeriods() para Obtener una lista de los períodos de suspensión establecidos anteriormente en el objeto de la política de actualización del sistema Se recibió DevicePolicyManager.getSystemUpdatePolicy() se actualizará para mostrar los períodos de suspensión establecidos por el propietario del dispositivo.

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

Los propietarios de los perfiles pueden impedir que los usuarios compartan datos personales en un perfil de trabajo. en el dispositivo agregando la restricción de usuario 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 las apps del perfil de trabajo.
  • Apps del perfil de trabajo que seleccionan elementos del perfil personal, por ejemplo, fotografías o archivos.

Después de establecer esta restricción, tu DPC podrá seguir permitiendo actividad entre perfiles. intents llamando addCrossProfileIntentFilter()

Claves protegidas por hardware y certificados de máquinas

En Android 9, se agregan APIs para ayudarte a trabajar con claves y certificados que puedes se combinan para identificar los dispositivos de forma segura. Un DPC que se ejecuta en el dispositivo o el propietario del perfil modos de propietario o un instalador de certificados delegado, completa las siguientes tareas:

  • Genera claves y certificados en el hardware seguro (como un entorno de ejecución (TEE) o elemento seguro (SE) del dispositivo Android. El generadas nunca salen del hardware seguro y se pueden usar desde el servicio de Android KeyChain Llamada DevicePolicyManager.generateKeyPair() proporciona la algoritmo (consulta KeyPairGenerator) y cualquier ID de hardware que que quieres certificar, como el número de serie o IMEI. Para obtener más información sobre la seguridad cambios en hardware, consulta el artículo Security 9 Security mejoras.
  • Asocia un certificado con una clave existente generada por el dispositivo. Llamada DevicePolicyManager.setKeyPairCertificate() suministrando el alias de la clave existente y la cadena de certificados (comienza con la hoja certificado e incluir la cadena de confianza en orden.
  • Confirma que el hardware seguro protege la clave antes de usarlo. Para comprobar qué mecanismos protegen la clave, sigue los pasos que se indican en Claves Certificación.
  • Los propietarios de dispositivos y los instaladores de certificados delegados pueden recibir un estado de la cuenta de los dispositivos IDs de hardware con versiones del sistema Android. Llamada DevicePolicyManager.generateKeyPair() que pasa uno o más de ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI o ID_TYPE_MEID en las idAttestationFlags. El certificado que se muestra incluye el hardware IDs 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 ID_TYPE_BASE_INFO). Para comprobar que el dispositivo pueda certificar los IDs, llama isDeviceIdAttestationSupported()
  • Impedir que los usuarios del dispositivo usen de forma inadecuada las claves empresariales (en tareas que no son empresariales) haciendo que no se pueda seleccionar los certificados clave. El sistema no incluye certificados no seleccionables en el panel del selector. En tu DeviceAdminReceiver.onChoosePrivateKeyAlias() método de devolución de llamada, devuelve el alias a tu clave empresarial para que el sistema selecciona automáticamente el certificado en nombre del usuario. Para crear una llave, sigue estos pasos: no seleccionable, llama a los siguientes métodos DevicePolicyManager:

Con la combinación de estas APIs, las empresas pueden identificar dispositivos de forma segura y confirmar su integridad antes de permitir el acceso:

  1. El dispositivo Android genera una clave privada nueva 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 el IDs de dispositivos.
  3. El servidor valida la cadena de certificados (basada en un certificado de Google). Luego, 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 de dispositivo coincidan con los registros de la empresa. El servidor también puede verificar de 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 a el dispositivo.
  6. El dispositivo vincula el certificado con la clave privada (que permanece en el hardware seguro) lo que permite que las aplicaciones se conecten a servicios empresariales.

Más API, funciones y cambios de seguridad

IDs de registros de seguridad y registros de red

Android 9 incluye IDs en los 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 de red son independientes colecciones, el sistema mantiene valores de ID separados.

Llamada 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. Registros de seguridad recuperados con llamadas DevicePolicyManager.retrievePreRebootSecurityLogs() no incluyen estos IDs.

Registro de seguridad

El registro de seguridad asigna a cada SecurityEvent un nivel de registro. Para obtener el nivel de registro, llamar a getLogLevel() Este método devuelve un valor de nivel de registro que puede ser LEVEL_INFO, LEVEL_WARNING o LEVEL_ERROR

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

Etiqueta 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 Se trata de un intento de quitar un certificado raíz del almacenamiento de credenciales del sistema.
TAG_CERT_VALIDATION_FAILURE Un certificado de Wi-Fi no pasó 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 inhabilitó 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 Se intentó 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 El registro de seguridad comenzó a grabar.
TAG_LOGGING_STOPPED El registro de seguridad detuvo la grabación.
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 estableció 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 estableció la duración de vencimiento de las contraseñas.
TAG_PASSWORD_HISTORY_LENGTH_SET Una app de administración estableció una longitud para el historial de contraseñas, lo que evita 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 Falló un intento de 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 exigir que los usuarios establezcan un bloqueo diferente. desafío de pantalla para su perfil de trabajo con la Restricción de usuario de DISALLOW_UNIFIED_PASSWORD. Para Comprobar si un usuario tiene establecida la misma verificación de identidad para la pantalla de bloqueo en su dispositivo perfil de trabajo, llamada DevicePolicyManager.isUsingUnifiedPassword()

Si un dispositivo tiene una pantalla de bloqueo independiente para el perfil de trabajo, DevicePolicyManager.setMaximumTimeToLock() solo establece un tiempo de espera de la 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 a los archivos del perfil de trabajo.

Compatibilidad con más opciones biométricas

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

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

Android 9 marca las políticas que se indican a continuación como obsoletas para los DPC que usan device administrador. Las políticas siguen funcionando en Android 9, como lo hicieron antes. A partir de la versión de Android 10, estas mismas políticas arrojarán una SecurityException cuando las invoque un administrador de dispositivos.

Algunas aplicaciones usan administradores de dispositivos para la administración de dispositivos de consumidores. Para como bloquear y limpiar un dispositivo perdido. Las siguientes políticas continuarán para habilitar esta función:

Para obtener más información sobre estos cambios, lee Administrador del dispositivo. baja.

Inscripción optimizada a través de códigos QR

Biblioteca QR integrada

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

El método de aprovisionamiento con código QR admite los siguientes extras de aprovisionamiento para especificar detalles de Wi-Fi:

Configura la fecha y la zona horaria con los elementos de aprovisionamiento adicionales

El método de aprovisionamiento con código QR admite el aprovisionamiento extra para establecer la hora y la zona horaria de un dispositivo:

Opciones de limpieza de datos

Los administradores de dispositivos pueden mostrar un mensaje personalizado a los usuarios cuando quiten un trabajo. perfil o usuario secundario. El mensaje ayuda a los usuarios de dispositivos a comprender que sus El administrador de TI quitó el perfil de trabajo o el usuario secundario. Llamada wipeData(int, CharSequence) y proporciona una un mensaje explicativo. Cuando lo llama el usuario principal o el propietario del dispositivo, 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 wipeData() y, además, incluye WIPE_EUICC en flags argumento.

Métodos para propietarios de perfiles afiliados

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