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.
![](https://developer.android.com/static/images/about/versions/pie/p-work-profile.jpg?authuser=3&hl=es-419)
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
:
- 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 texto localizado que le solicita al usuario que cambie de perfil - 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:
- Llama a
DevicePolicyManager.setLockTaskPackages()
para 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 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:
LOCK_TASK_FEATURE_NONE
LOCK_TASK_FEATURE_SYSTEM_INFO
LOCK_TASK_FEATURE_HOME
LOCK_TASK_FEATURE_NOTIFICATIONS
Solo se puede usar en combinación conLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_KEYGUARD
LOCK_TASK_FEATURE_OVERVIEW
Solo se puede usar en combinación 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 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:
- Establece la marca
MAKE_USER_EPHEMERAL
cuando realices llamadasDevicePolicyManager.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
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:
onUserStarted()
: Se llama cuando se inicia un usuario.onUserSwitched()
: Se llama cuando se cambia de usuario. de la configuración.onUserStopped()
: Se llama junto cononUserRemoved()
cuando un usuario se detiene o registra registros sale.
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:
- Usa
DevicePolicyManager.setStartUserSessionMessage()
para configurar el mensaje que se mostrará a un usuario cuando comience su sesión. Para recuperar el mensaje, llamarDevicePolicyManager.getStartUserSessionMessage()
- Usa
DevicePolicyManager.setEndUserSessionMessage()
para configurar el mensaje que se mostrará al usuario cuando finalice su sesión. Para recuperar el mensaje, llamarDevicePolicyManager.getEndUserSessionMessage()
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:
Llamada
DevicePolicyManager.setKeepUninstalledPackages()
para especificar la lista de paquetes que se conservarán como APK. Para recuperar una lista paquetes, llamaDevicePolicyManager.getKeepUninstalledPackages()
Llama a
DevicePolicyManager.installExistingPackage()
instalar un paquete que se guardó después de su eliminación mediantesetKeepUninstalledPackages()
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:
DevicePolicyManager.getSecondaryUsers()
obtiene una lista de para todos los usuarios secundarios de un dispositivo.DISALLOW_USER_SWITCH
es una restricción de usuario que puedes para habilitarlo llamandoDevicePolicyManager.addUserRestriction()
para bloquear el cambio de usuarios.LEAVE_ALL_SYSTEM_APPS_ENABLED
es una marca disponible paraDevicePolicyManager.createAndManageUser()
Cuando se establece, las apps del sistema no se inhabiliten durante el aprovisionamiento de usuarios.- arroja
UserManager.UserOperationException
DevicePolicyManager.createAndManageUser()
cuando no se puede crear un usuario (el excepción contiene el motivo del error.
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:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
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
:
DISALLOW_AIRPLANE_MODE
DISALLOW_AMBIENT_DISPLAY
DISALLOW_CONFIG_BRIGHTNESS
DISALLOW_CONFIG_DATE_TIME
DISALLOW_CONFIG_LOCATION
DISALLOW_CONFIG_SCREEN_TIMEOUT
DISALLOW_PRINTING
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:
- 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.
- El DPC de origen llama a
transferOwnership()
para iniciar la de datos entre sitios. - El sistema convierte al DPC de destino en administrador activo y establece como propietario del dispositivo administrado o del perfil de trabajo.
- El DPC de destino recibe la devolución de llamada
onTransferOwnershipComplete()
y puede configurar con valores del argumentobundle
. - 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:
- Primero, transfiere la propiedad del perfil de trabajo.
- Espera la devolución de llamada de
DeviceAdminReceiver
onTransferAffiliatedProfileOwnershipComplete()
para confirmar 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 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 (consultaKeyPairGenerator
) 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 deID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
oID_TYPE_MEID
en lasidAttestationFlags
. 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, pasa0
Los propietarios de perfiles solo pueden recibir información del fabricanteID_TYPE_BASE_INFO
). Para comprobar que el dispositivo pueda certificar los IDs, llamaisDeviceIdAttestationSupported()
- 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étodosDevicePolicyManager
:setKeyPairCertificate()
y pasafalse
para el argumentoisUserSelectable
.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
y omitirINSTALLKEY_SET_USER_SELECTABLE
de el argumentoflags
.
Con la combinación de estas APIs, las empresas pueden identificar dispositivos de forma segura y confirmar su integridad antes de permitir el acceso:
- 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.
- 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.
- El servidor valida la cadena de certificados (basada en un certificado de Google). Luego, 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 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.
- El servidor genera un certificado a partir de la CSR y lo envía a el dispositivo.
- 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.
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. 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:
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 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:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()