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.
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
:
- 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. - Llama a
getProfileSwitchingIconDrawable()
para obtener un ícono que puedas usar para representar otro perfil. - Llama a
getProfileSwitchingLabel()
para obtener texto localizado que le solicite al usuario cambiar de perfil. - 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:
- Llama a
DevicePolicyManager.setLockTaskPackages()
a fin de incluir apps en la lista de entidades permitidas para el modo de tareas bloqueadas. - 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:
LOCK_TASK_FEATURE_NONE
LOCK_TASK_FEATURE_SYSTEM_INFO
LOCK_TASK_FEATURE_HOME
LOCK_TASK_FEATURE_NOTIFICATIONS
solo se puede usar junto conLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_KEYGUARD
LOCK_TASK_FEATURE_OVERVIEW
solo se puede usar junto conLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_GLOBAL_ACTIONS
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:
- Establece la marca
MAKE_USER_EPHEMERAL
cuando llames aDevicePolicyManager.createAndManageUser()
. - 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:
onUserStarted()
: Se llama cuando se inicia un usuario.onUserSwitched()
: Se llama cuando se completa un cambio de usuario.onUserStopped()
: Se llama junto cononUserRemoved()
cuando un usuario se detiene o cierra sesión.
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:
- Usa
DevicePolicyManager.setStartUserSessionMessage()
para configurar el mensaje que se mostrará a un usuario cuando comience su sesión. Para recuperar el mensaje, llama aDevicePolicyManager.getStartUserSessionMessage()
. - Usa
DevicePolicyManager.setEndUserSessionMessage()
para configurar el mensaje que se mostrará al usuario cuando finalice su sesión. Para recuperar el mensaje, llama aDevicePolicyManager.getEndUserSessionMessage()
.
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:
Llama a
DevicePolicyManager.setKeepUninstalledPackages()
para especificar la lista de paquetes que se conservarán como APKs. Para recuperar una lista de estos paquetes, llama aDevicePolicyManager.getKeepUninstalledPackages()
.Llama a
DevicePolicyManager.installExistingPackage()
para instalar un paquete que se mantuvo después de la eliminación mediantesetKeepUninstalledPackages()
.
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:
DevicePolicyManager.getSecondaryUsers()
obtiene una lista de todos los usuarios secundarios de un dispositivo.DISALLOW_USER_SWITCH
es una restricción de usuario que puedes habilitar llamando aDevicePolicyManager.addUserRestriction()
para bloquear el cambio de usuarios.LEAVE_ALL_SYSTEM_APPS_ENABLED
es una marca disponible paraDevicePolicyManager.createAndManageUser()
. Cuando se configura, las apps del sistema no se inhabilitan durante el aprovisionamiento de usuarios.DevicePolicyManager.createAndManageUser()
arrojaUserManager.UserOperationException
cuando no se puede crear un usuario (la excepción contiene el motivo de la falla).
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:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
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
:
DISALLOW_AIRPLANE_MODE
DISALLOW_AMBIENT_DISPLAY
DISALLOW_CONFIG_BRIGHTNESS
DISALLOW_CONFIG_DATE_TIME
DISALLOW_CONFIG_LOCATION
DISALLOW_CONFIG_SCREEN_TIMEOUT
DISALLOW_PRINTING
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:
- 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.
- El DPC de origen llama a
transferOwnership()
para iniciar la transferencia. - 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.
- El DPC de destino recibe la devolución de llamada
onTransferOwnershipComplete()
y puede configurarse a sí mismo usando valores del argumentobundle
. - 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:
- Primero, transfiere la propiedad del perfil de trabajo.
- Espera a que la devolución de llamada
onTransferAffiliatedProfileOwnershipComplete()
deDeviceAdminReceiver
confirme que el perfil de trabajo se transfirió al DPC de destino. - 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 (consultaKeyPairGenerator
) 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 deID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
oID_TYPE_MEID
en el argumentoidAttestationFlags
. 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, pasa0
. Los propietarios de perfiles solo pueden recibir información del fabricante (pasandoID_TYPE_BASE_INFO
). Para verificar que el dispositivo pueda certificar IDs, llama aisDeviceIdAttestationSupported()
. - 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étodosDevicePolicyManager
:setKeyPairCertificate()
y pasafalse
para el argumentoisUserSelectable
.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
y omiteINSTALLKEY_SET_USER_SELECTABLE
del argumentoflags
.
Cuando se combinan estas APIs, las empresas pueden identificar los dispositivos de forma segura y confirmar su integridad antes de proporcionar acceso:
- 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.
- 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.
- 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.
- 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.
- El servidor genera un certificado a partir de la CSR y lo envía al dispositivo.
- 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.
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. 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:
EXTRA_PROVISIONING_WIFI_HIDDEN
EXTRA_PROVISIONING_WIFI_PAC_URL
EXTRA_PROVISIONING_WIFI_PASSWORD
EXTRA_PROVISIONING_WIFI_PROXY_BYPASS
EXTRA_PROVISIONING_WIFI_PROXY_HOST
EXTRA_PROVISIONING_WIFI_PROXY_PORT
EXTRA_PROVISIONING_WIFI_SECURITY_TYPE
EXTRA_PROVISIONING_WIFI_SSID
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:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()