Esta página fornece uma visão geral dos recursos, mudanças de comportamento e APIs empresariais disponíveis no Android 9.
Interface do usuário do perfil de trabalho
O Android 9 (nível 28 da API) inclui mudanças na interface do usuário na tela de início padrão para ajudar os usuários a separar apps pessoais e de trabalho. Os fabricantes de dispositivos que oferecem suporte a esse recurso podem apresentar os apps dos usuários em guias de trabalho e pessoais separadas. Também facilitamos a ativação e desativação do perfil de trabalho para os usuários com a inclusão de uma chave na guia de trabalho da tela de início.
![](https://developer.android.com/static/images/about/versions/pie/p-work-profile.jpg?authuser=5&hl=pt-br)
Ao provisionar perfis de trabalho e dispositivos gerenciados, o Android 9 inclui ilustrações animadas para ajudar os usuários dos dispositivos a entender esses recursos.
Alternar apps entre perfis
O Android 9 inclui APIs para iniciar outra instância de um app em um perfil diferente
para ajudar os usuários a alternar entre as contas. Por exemplo, um app de e-mails pode
fornecer uma interface que permite ao usuário alternar entre o perfil pessoal e o de trabalho
para acessar duas contas de e-mail. Todos os apps podem chamar essas APIs para iniciar a
atividade principal do mesmo app, caso ele já esteja instalado no outro perfil. Para
adicionar a alternância de contas entre perfis ao app, siga as etapas abaixo, chamando métodos
da classe
CrossProfileApps
:
- Chame
getTargetUserProfiles()
para ver uma lista de perfis em que é possível iniciar outra instância do app. Esse método verifica se o app está instalado nos perfis. - Chame
getProfileSwitchingIconDrawable()
para receber um ícone que possa ser usado para representar outro perfil. - Chame
getProfileSwitchingLabel()
para receber um texto localizado que solicite que o usuário troque de perfil. - Chame
startMainActivity()
para iniciar uma instância do app em outro perfil.
Confira se a atividade principal que você quer iniciar está declarada no arquivo de manifesto
do app, com uma ação da intent ACTION_MAIN
, e inclui
uma categoria de intent CATEGORY_LAUNCHER
.
Ativar ou desativar perfis de trabalho programaticamente
A tela de início padrão ou os apps que têm a permissão MANAGE_USERS
ou
MODIFY_QUIET_MODE
podem ativar ou desativar o perfil de trabalho chamando
UserManager.requestQuietModeEnabled()
. Você pode
inspecionar o valor de retorno para saber se o usuário precisa confirmar as
credenciais antes da mudança do estado. Como a mudança pode não acontecer
instantaneamente, detecte a transmissão
ACTION_MANAGED_PROFILE_AVAILABLE
ou
ACTION_MANAGED_PROFILE_UNAVAILABLE
para saber quando atualizar a interface do usuário.
Seu app pode verificar o status do perfil de trabalho chamando
UserManager.isQuietModeEnabled()
.
Bloquear qualquer app a um dispositivo
A partir do Android 9, os proprietários de dispositivos e de perfis (de usuários secundários) podem bloquear qualquer app na tela de um dispositivo colocando-o no modo de bloqueio de tarefas. Anteriormente, os desenvolvedores de apps precisavam adicionar suporte ao modo de tarefa de bloqueio nos apps. O Android 9 também estende as APIs de tarefas de bloqueio para proprietários de perfis de usuários secundários não afiliados. Siga as etapas abaixo para bloquear um app na tela:
- Chame
DevicePolicyManager.setLockTaskPackages()
para adicionar apps à lista de permissões para o modo de bloqueio de tarefas. - Chame
ActivityOptions.setLockTaskEnabled()
para iniciar um app da lista de permissões no modo de tarefa de bloqueio.
Para interromper um app no modo de bloqueio de tarefas, remova o app da lista de permissões
do modo de bloqueio de tarefas usando
DevicePolicyManager.setLockTaskPackages()
.
Ativar recursos de interface do sistema
Quando o modo de bloqueio de tarefas está ativado, os proprietários de dispositivos e perfis podem ativar
determinados recursos de interface do sistema no dispositivo chamando
DevicePolicyManager.setLockTaskFeatures()
e transmitindo um
campo de bits das flags de recursos abaixo:
LOCK_TASK_FEATURE_NONE
LOCK_TASK_FEATURE_SYSTEM_INFO
LOCK_TASK_FEATURE_HOME
LOCK_TASK_FEATURE_NOTIFICATIONS
só pode ser usado em combinação comLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_KEYGUARD
LOCK_TASK_FEATURE_OVERVIEW
só pode ser usado em combinação comLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_GLOBAL_ACTIONS
Você pode chamar DevicePolicyManager.getLockTaskFeatures()
para acessar a lista de recursos disponíveis em um dispositivo quando o modo de bloqueio de tarefas está
ativado. Quando um dispositivo sai do modo de bloqueio de tarefas, ele retorna ao estado determinado por
outras políticas do dispositivo.
Suprimir caixas de diálogo de erro
Em alguns ambientes, como demonstrações na loja ou exibições de informações públicas, talvez você não queira mostrar caixas de diálogo de erro aos usuários. Um controlador de política
de dispositivo (DPC) pode suprimir caixas de diálogo de erro do sistema para apps com falha ou que não respondem
adicionando a
restrição de usuário
DISALLOW_SYSTEM_ERROR_DIALOGS
. Essa restrição afeta todas as caixas de diálogo, quando aplicada por um proprietário do dispositivo,
mas apenas as caixas de diálogo de erro mostradas no usuário principal ou secundário são suprimidas
quando a restrição é aplicada pelos proprietários do perfil. Essa restrição não
afeta os perfis de trabalho.
No Android 9, os apps executados no modo de tela cheia imersiva não mostram o balão de lembrete quando estão no modo de bloqueio de tarefas. O balão do lembrete é um painel mostrado aos usuários (na primeira inicialização) que explica como sair do modo imersivo.
Oferecer suporte a vários usuários em dispositivos dedicados
O Android 9 introduz o conceito de um usuário temporário para dispositivos dedicados (anteriormente chamados de dispositivos COSU). São usuários temporários, de curta duração, destinados a casos em que vários usuários compartilham um único dispositivo dedicado. Isso inclui sessões públicas de usuário em dispositivos como quiosques de check-in de biblioteca ou hospitalidade, bem como sessões persistentes entre um conjunto fixo de usuários em dispositivos, como funcionários em turnos.
Os usuários efêmeros devem ser criados no segundo plano. Eles são criados como usuários secundários em um dispositivo e são removidos (junto dos apps e dados associados) quando são interrompidos, trocados ou o dispositivo é reinicializado. Para criar um usuário temporário, os proprietários de dispositivos podem:
- Defina a flag
MAKE_USER_EPHEMERAL
ao chamarDevicePolicyManager.createAndManageUser()
. - Chame
DevicePolicyManager.startUserInBackground()
para iniciar o usuário temporário em segundo plano.
Os apps destinados ao Android 9 precisam capturar
UserManager.UserOperationException
ao chamar
createAndManageUser()
. Chame o método
getUserOperationResult()
da exceção para descobrir por que o
usuário não foi criado.
Receber notificações de eventos
O DeviceAdminReceiver
recebe notificações para os
seguintes eventos:
onUserStarted()
: chamado quando um usuário é iniciado.onUserSwitched()
: chamado quando uma mudança de usuário é concluída.onUserStopped()
: chamado comonUserRemoved()
quando um usuário para ou faz logout.
Exibir mensagens de eventos para os usuários
Os proprietários de dispositivos podem configurar as mensagens que são exibidas aos usuários quando iniciam e encerram as sessões:
- Use
DevicePolicyManager.setStartUserSessionMessage()
para definir a mensagem que será exibida quando a sessão do usuário começar. Para recuperar a mensagem, chameDevicePolicyManager.getStartUserSessionMessage()
. - Use
DevicePolicyManager.setEndUserSessionMessage()
para definir a mensagem que aparece para o usuário quando a sessão dele termina. Para recuperar a mensagem, chameDevicePolicyManager.getEndUserSessionMessage()
.
Desconectar e interromper usuários
Os proprietários de dispositivos podem usar
DevicePolicyManager.setLogoutEnabled()
para especificar se
a saída será ativada para usuários secundários. Para verificar se a saída está ativada, chame
DevicePolicyManager.isLogoutEnabled()
.
Os proprietários de perfil de usuários secundários podem chamar
DevicePolicyManager.logoutUser()
para interromper o usuário secundário e
voltar para o usuário principal.
Os proprietários de dispositivos podem usar DevicePolicyManager.stopUser()
para interromper um
usuário secundário especificado.
Armazenamento em cache de pacotes
Para simplificar o provisionamento de usuários em dispositivos compartilhados com um conjunto fixo de usuários, como dispositivos para trabalhadores de turnos, é possível armazenar em cache pacotes necessários para sessões multiusuário:
Chame
DevicePolicyManager.setKeepUninstalledPackages()
para especificar a lista de pacotes a serem mantidos como APKs. Para recuperar uma lista desses pacotes, chameDevicePolicyManager.getKeepUninstalledPackages()
.Chame
DevicePolicyManager.installExistingPackage()
para instalar um pacote que foi mantido após a remoção usandosetKeepUninstalledPackages()
.
Métodos e constantes adicionais
O Android 9 também inclui os métodos e constantes abaixo para oferecer ainda mais suporte a sessões de usuários em dispositivos compartilhados:
DevicePolicyManager.getSecondaryUsers()
recebe uma lista de todos os usuários secundários em um dispositivo.DISALLOW_USER_SWITCH
é uma restrição de usuário que pode ser ativada chamandoDevicePolicyManager.addUserRestriction()
para bloquear a alternância de usuários.LEAVE_ALL_SYSTEM_APPS_ENABLED
é uma sinalização disponível paraDevicePolicyManager.createAndManageUser()
. Quando definido, os apps do sistema não são desativados durante o provisionamento de usuários.UserManager.UserOperationException
é gerado porDevicePolicyManager.createAndManageUser()
quando não é possível criar um usuário. A exceção contém o motivo da falha.
Limpar dados do pacote e remover contas
Os proprietários de dispositivos e de perfis podem chamar
clearApplicationUserData()
para limpar os dados do usuário
de um determinado pacote. Para remover uma conta do
AccountManager
, os proprietários do dispositivo e do perfil podem chamar
removeAccount()
.
Restrições de usuários e maior controle das configurações
O Android 9 apresenta um conjunto de restrições de usuário para DPCs, bem como a capacidade de definir APNs, horário, fuso horário e configurações do sistema em um dispositivo.
Configurar APNs
Os proprietários de dispositivos podem usar os métodos abaixo na classe
DevicePolicyManager
para configurar APNs em um
dispositivo:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
Configurar horário e fuso horário
Os proprietários de dispositivos podem usar os seguintes métodos na classe
DevicePolicyManager
para definir a hora e o fuso horário
em um dispositivo:
Aplicar restrições de usuário a configurações importantes
O Android 9 adiciona restrições de usuário para desativar recursos e configurações do sistema. Para
adicionar uma restrição, chame
DevicePolicyManager.addUserRestriction()
com uma das
seguintes constantes UserManager
:
DISALLOW_AIRPLANE_MODE
DISALLOW_AMBIENT_DISPLAY
DISALLOW_CONFIG_BRIGHTNESS
DISALLOW_CONFIG_DATE_TIME
DISALLOW_CONFIG_LOCATION
DISALLOW_CONFIG_SCREEN_TIMEOUT
DISALLOW_PRINTING
Se os métodos DISALLOW_CONFIG_BRIGHTNESS
e
DISALLOW_CONFIG_SCREEN_TIMEOUT
forem aplicados
em um dispositivo, os proprietários ainda poderão definir as configurações de brilho
da tela, modo de brilho
da tela e tempo limite da tela
usando a API
DevicePolicyManager.setSystemSetting()
.
Dados limitados
Os proprietários de dispositivos e de perfis podem impedir que apps usem as redes de dados limitadas de um dispositivo. Uma rede é considerada limitada quando o usuário se preocupa
com o uso intenso de dados devido a custos, limites de dados ou problemas de bateria e
desempenho. Para evitar que os apps usem redes limitadas, chame
DevicePolicyManager.setMeteredDataDisabledPackages()
transmitindo uma lista de nomes de pacotes. Para recuperar os apps restritos no momento, chame
DevicePolicyManager.getMeteredDataDisabledPackages()
.
Para saber mais sobre dados limitados no Android, leia Como otimizar o uso de dados de rede.
Migrar DPCs
Os controladores de política do dispositivo (DPCs) podem transferir a propriedade de um dispositivo ou perfil de trabalho para outro DPC. Você pode transferir a propriedade para mover alguns recursos para a API Android Management, migrar dispositivos do DPC legado ou ajudar os administradores de TI a migrar para o EMM. Como você está apenas mudando a propriedade do DPC, não é possível usar esse recurso para mudar o tipo de gerenciamento, por exemplo, migrar de um dispositivo gerenciado para um perfil de trabalho ou vice-versa.
Use o recurso XML das políticas de administração de dispositivos para
indicar que essa versão do DPC é compatível com a migração. Um DPC de destino
indica que pode receber propriedade incluindo um elemento chamado
<support-transfer-ownership>
. O exemplo abaixo mostra como fazer isso no
arquivo XML do administrador do dispositivo do 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>
Os DPCs que quiserem migrar a propriedade para o novo app de DPC podem verificar se a versão de um DPC de destino
oferece suporte à migração chamando o método DeviceAdminInfo
supportsTransferOwnership()
. Antes de transferir
a propriedade, é responsabilidade do DPC de origem verificar o DPC de destino
comparando as assinaturas do app. A classe PackageManager
inclui
métodos para trabalhar com assinaturas de assinatura de código.
O Android mantém as políticas do usuário e do sistema do DPC de origem por uma transferência de
propriedade. Os DPCs não precisam migrá-las. Um DPC de origem pode transmitir dados personalizados para
o DPC de destino usando pares de chave-valor em um PersistableBundle
. Após uma
transferência bem-sucedida, o DPC de destino pode recuperar esses dados chamando
DevicePolicyManager.getTransferOwnershipBundle()
.
As etapas para transferir a propriedade de um dispositivo gerenciado ou de um perfil de trabalho são as mesmas:
- O DPC de origem verifica se a versão do DPC de destino oferece suporte à migração e confirma se a assinatura do app do DPC de destino corresponde a um valor esperado.
- O DPC de origem chama
transferOwnership()
para iniciar a transferência. - O sistema torna o DPC de destino o administrador ativo e o define como proprietário do dispositivo gerenciado ou perfil de trabalho.
- O DPC de destino recebe o callback
onTransferOwnershipComplete()
e pode se configurar usando valores do argumentobundle
. - Se algo der errado com a transferência, o sistema vai reverter a propriedade para
o DPC de origem. Se o DPC de origem precisar confirmar que a transferência de propriedade
foi bem-sucedida, chame
isAdminActive()
para verificar se o DPC de origem não é mais o administrador ativo.
Todos os apps em execução no perfil de trabalho recebem a
transmissão ACTION_PROFILE_OWNER_CHANGED
quando
o proprietário do perfil muda. Os apps em execução em um dispositivo gerenciado recebem a transmissão
ACTION_DEVICE_OWNER_CHANGED
quando o
proprietário do dispositivo muda.
Perfis de trabalho em dispositivos totalmente gerenciados
A transferência de duas instâncias de um DPC executado como proprietário do dispositivo e proprietário do perfil ocorre em duas etapas. Quando o perfil pessoal e o de trabalho forem afiliados, conclua a transferência na seguinte ordem:
- Transfira a propriedade do perfil de trabalho primeiro.
- Aguarde o callback
DeviceAdminReceiver
onTransferAffiliatedProfileOwnershipComplete()
para confirmar que o perfil de trabalho foi transferido para o DPC de destino. - Por fim, transfira a propriedade do dispositivo gerenciado para o DPC de destino.
Adiar atualizações over the air (OTA)
Os proprietários de dispositivos podem adiar as atualizações do sistema OTA nos dispositivos por até 90 dias para congelar a versão do SO executada nesses dispositivos em períodos críticos, como feriados. O sistema aplica um buffer obrigatório de 60 dias após qualquer período de congelamento definido para evitar que o dispositivo fique congelado indefinidamente.
Durante um período de congelamento:
- Os dispositivos não recebem notificações sobre atualizações OTA pendentes.
- Os dispositivos não instalam atualizações OTA no SO.
- Os usuários de dispositivos não podem verificar manualmente se há atualizações OTA nas Configurações.
Para definir um período de congelamento, chame
SystemUpdatePolicy.setFreezePeriods()
. Como o período de congelamento se repete anualmente, as datas de início e término do período são representadas por números inteiros que contam o número de dias desde o início do ano. A data de início precisa
começar pelo menos 60 dias após o término de qualquer período de congelamento anterior. Os proprietários
de dispositivos podem chamar SystemUpdatePolicy.getFreezePeriods()
para
receber uma lista de períodos de congelamento definidos anteriormente no objeto da política de atualização do sistema.
O DevicePolicyManager.getSystemUpdatePolicy()
foi
atualizado para retornar todos os períodos de congelamento definidos pelo proprietário do dispositivo.
Restringir o compartilhamento em um perfil de trabalho
Os proprietários de perfis podem impedir que os usuários compartilhem dados pessoais em um perfil de trabalho
no dispositivo adicionando a restrição de usuário
DISALLOW_SHARE_INTO_MANAGED_PROFILE
.
Essa restrição evita as seguintes ações e compartilhamento de intent:
- Apps do perfil pessoal que compartilham dados e arquivos com apps do perfil de trabalho.
- Apps do perfil de trabalho que selecionam itens do perfil pessoal, por exemplo, imagens ou arquivos.
Após definir essa restrição, o DPC ainda poderá permitir intents de atividade
entre perfis chamando
addCrossProfileIntentFilter()
.
Chaves protegidas por hardware e certificados de máquina
O Android 9 adiciona APIs para ajudar você a trabalhar com chaves e certificados que podem ser combinados para identificar dispositivos com segurança. Um DPC em execução nos modos de proprietário do perfil ou do dispositivo, ou um instalador de certificado delegado, pode concluir as seguintes tarefas:
- Gerar chaves e certificados no hardware seguro, como um ambiente
de execução confiável (TEE, na sigla em inglês) ou um Elemento de segurança (SE, na sigla em inglês) do dispositivo Android. As
chaves geradas nunca saem do hardware seguro e podem ser usadas no Android
KeyChain. Chame
DevicePolicyManager.generateKeyPair()
fornecendo o algoritmo (consulteKeyPairGenerator
) e os IDs de hardware que você quer atestar, como o número de série ou o IMEI. Para saber mais sobre mudanças seguras de hardware, consulte as Melhorias de segurança do Android 9. - Associar um certificado a uma chave gerada pelo dispositivo. Chame
DevicePolicyManager.setKeyPairCertificate()
fornecendo o alias da chave atual e da cadeia de certificados, começando com o certificado folha e incluindo a cadeia de confiança em ordem. - Confirme se o hardware seguro protege a chave antes de usá-la. Para verificar quais mecanismos protegem a chave, siga as etapas em Atestado de chaves.
- Os proprietários de dispositivos e os instaladores de certificados delegados podem receber uma declaração
assinada dos IDs de hardware dos dispositivos com as versões do sistema Android. Chame
DevicePolicyManager.generateKeyPair()
transmitindo um ou mais deID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
ouID_TYPE_MEID
no argumentoidAttestationFlags
. O certificado retornado inclui os IDs do hardware no registro de confirmação. Se você não quiser incluir os IDs de hardware, transmita0
. Os proprietários de perfis só podem receber informações do fabricante (transmitindoID_TYPE_BASE_INFO
). Para verificar se o dispositivo pode atestar IDs, chameisDeviceIdAttestationSupported()
. - Para evitar o uso indevido de chaves empresariais (em tarefas não corporativas),
torne os certificados de chave não selecionáveis. O sistema não inclui
certificados que não podem ser selecionados no painel do seletor. No método de callback
DeviceAdminReceiver.onChoosePrivateKeyAlias()
, retorne o alias à chave corporativa para que o sistema selecione automaticamente o certificado em nome do usuário. Para tornar uma chave não selecionável, chame os seguintes métodosDevicePolicyManager
:setKeyPairCertificate()
e transmitirfalse
para o argumentoisUserSelectable
.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
e omitaINSTALLKEY_SET_USER_SELECTABLE
do argumentoflags
.
Ao combinar essas APIs, as empresas podem identificar com segurança os dispositivos e confirmar a integridade deles antes de fornecer acesso:
- O dispositivo Android gera uma nova chave privada no hardware protegido. Como a chave privada nunca deixa o hardware seguro, ela permanece secreta.
- O dispositivo usa a chave para criar e enviar uma solicitação de assinatura de certificado (CSR, na sigla em inglês) ao servidor. O CSR inclui o registro de atestado que contém os IDs dos dispositivos.
- O servidor valida a cadeia de certificados (com acesso root a um certificado do Google) e extrai os metadados do dispositivo do registro de atestado.
- O servidor confirma que o hardware seguro protege a chave privada e que os IDs dos dispositivos correspondem aos registros da empresa. O servidor também pode verificar se as versões do sistema Android e do patch atendem a todos os requisitos.
- O servidor gera um certificado a partir do CSR e o envia ao dispositivo.
- O dispositivo faz o pareamento do certificado com a chave privada (que permanece no hardware seguro), permitindo que os apps se conectem a serviços corporativos.
Mais APIs, recursos e mudanças de segurança
IDs para registros de segurança e de rede
O Android 9 inclui IDs em registros de atividade de segurança e de rede. O ID numérico aumenta monotonicamente para cada evento, facilitando a detecção de lacunas nos registros pelos administradores de TI. Como os registros de segurança e de rede são coleções separadas, o sistema mantém valores de ID separados.
Chame SecurityEvent.getId()
,
DnsEvent.getId()
ou
ConnectEvent.getId()
para receber o valor do ID. O sistema
redefine o ID sempre que um DPC ativa a geração de registros ou o dispositivo é reiniciado.
Os registros de segurança buscados chamando
DevicePolicyManager.retrievePreRebootSecurityLogs()
não incluem esses IDs.
Geração de registros de segurança
A geração de registros de segurança atribui um nível de registro a cada SecurityEvent
. Para conferir o nível de registro,
chame getLogLevel()
. Esse método retorna um valor de nível de registro que
pode ser: LEVEL_INFO
, LEVEL_WARNING
ou
LEVEL_ERROR
.
O Android 9 registra os eventos listados na tabela abaixo nos registros de
segurança. Para verificar a tag de um evento, chame getTag()
. Para
recuperar os dados do evento, chame getData()
.
Tag | Descrição do evento |
---|---|
TAG_CERT_AUTHORITY_INSTALLED |
Uma tentativa de instalar um novo certificado raiz no armazenamento de credenciais do sistema. |
TAG_CERT_AUTHORITY_REMOVED |
Uma tentativa de remover um certificado raiz do armazenamento de credenciais do sistema. |
TAG_CERT_VALIDATION_FAILURE |
Ocorreu uma falha em uma verificação de validação do certificado de Wi-Fi durante a conexão. |
TAG_CRYPTO_SELF_TEST_COMPLETED |
O sistema concluiu o autoteste de criptografia. |
TAG_KEYGUARD_DISABLED_FEATURES_SET |
Um app de administrador desativou os recursos da tela de bloqueio de um dispositivo ou de um perfil de trabalho. |
TAG_KEY_DESTRUCTION |
Tentativa de excluir uma chave criptográfica. |
TAG_KEY_GENERATED |
Tentativa de gerar uma nova chave criptográfica. |
TAG_KEY_IMPORT |
Tentativa de importar uma nova chave criptográfica. |
TAG_KEY_INTEGRITY_VIOLATION |
O Android detectou uma chave de criptografia ou autenticação danificada. |
TAG_LOGGING_STARTED |
A geração de registros de segurança iniciou a gravação. |
TAG_LOGGING_STOPPED |
A geração de registros de segurança parou de gravar. |
TAG_LOG_BUFFER_SIZE_CRITICAL |
O buffer do registro de segurança atingiu 90% da capacidade. |
TAG_MAX_PASSWORD_ATTEMPTS_SET |
Um app de administrador definiu o número permitido de tentativas de senha incorreta. |
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET |
Um app de administrador definiu um tempo limite máximo de bloqueio de tela. |
TAG_MEDIA_MOUNT |
O dispositivo está montado em uma mídia de armazenamento removível. |
TAG_MEDIA_UNMOUNT |
O dispositivo desconectou a mídia de armazenamento removível. |
TAG_OS_SHUTDOWN |
O sistema Android foi desligado. |
TAG_OS_STARTUP |
O sistema Android foi iniciado. |
TAG_PASSWORD_COMPLEXITY_SET |
Um app de administração definiu requisitos de complexidade de senha. |
TAG_PASSWORD_EXPIRATION_SET |
Um app de administrador definiu uma duração para a senha. |
TAG_PASSWORD_HISTORY_LENGTH_SET |
Um app de administrador definiu o tamanho do histórico de senhas, impedindo que os usuários reutilizem senhas antigas. |
TAG_REMOTE_LOCK |
Um app de administrador bloqueou o dispositivo ou perfil de trabalho. |
TAG_USER_RESTRICTION_ADDED |
Um app de administrador definiu uma restrição de usuário. |
TAG_USER_RESTRICTION_REMOVED |
Um app de administrador removeu uma restrição de usuário. |
TAG_WIPE_FAILURE |
Falha ao tentar excluir permanentemente um dispositivo ou perfil de trabalho. |
Desafio da tela de bloqueio do perfil de trabalho
A partir do Android 9, os proprietários de perfis podem exigir que os usuários definam um desafio de tela
de bloqueio separado para o perfil de trabalho usando a
restrição de usuário DISALLOW_UNIFIED_PASSWORD
. Para
verificar se um usuário tem o mesmo desafio de tela de bloqueio definido para o dispositivo e
o perfil de trabalho, chame
DevicePolicyManager.isUsingUnifiedPassword()
.
Se um dispositivo tiver uma tela de bloqueio de perfil de trabalho separada,
o DevicePolicyManager.setMaximumTimeToLock()
definirá um
tempo limite de tela de bloqueio apenas para o perfil de trabalho, e não para todo o dispositivo.
Acesso às ferramentas para desenvolvedores
Para ajudar a manter os dados de trabalho no perfil de trabalho, a ferramenta Android Debug Bridge (adb) não pode acessar diretórios e arquivos no perfil de trabalho.
Suporte a mais opções de biometria
O Android 9 adiciona controle refinado sobre a autenticação biométrica de hardware na
tela de bloqueio de um perfil de trabalho. Chame o método
DevicePolicyManager.setKeyguardDisabledFeatures()
atual com KEYGUARD_DISABLE_FACE
e
KEYGUARD_DISABLE_IRIS
.
Para desativar todos os métodos de autenticação biométrica fornecidos pelo dispositivo, adicione KEYGUARD_DISABLE_BIOMETRICS
.
Suspensão do uso de políticas administrativas dos dispositivos
O Android 9 marca as políticas listadas abaixo como descontinuadas para DPCs que usam administrador do dispositivo. As políticas continuam funcionando no Android 9 como antes. A partir da versão do Android 10, as mesmas políticas gerarão uma SecurityException quando invocadas por um administrador do dispositivo.
USES_POLICY_DISABLE_CAMERA
USES_POLICY_DISABLE_KEYGUARD_FEATURES
USES_POLICY_EXPIRE_PASSWORD
USES_POLICY_LIMIT_PASSWORD
Alguns aplicativos usam o administrador do dispositivo para administração do dispositivo do consumidor. Por exemplo, bloquear e excluir permanentemente os dados de um dispositivo perdido. As políticas a seguir continuarão disponíveis para ativar esse recurso:
Para ver mais informações sobre essas mudanças, leia Descontinuação do administrador do dispositivo.
Inscrição simplificada de código QR
Biblioteca QR integrada
O Android 9 vem com uma biblioteca QR para simplificar o provisionamento de dispositivos de código QR. Os administradores de TI não precisam mais inserir manualmente os detalhes do Wi-Fi para configurar um dispositivo. Em vez disso, com o Android 9, é possível incluir esses detalhes de Wi-Fi em um código QR. Quando um administrador de TI lê o código QR com um dispositivo da empresa, o dispositivo se conecta automaticamente ao Wi-Fi e entra no processo de provisionamento sem nenhuma outra entrada manual.
O método de provisionamento de código QR oferece suporte aos seguintes extras de provisionamento para especificar detalhes 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
Definir data e fuso horário usando os extras de provisionamento
O método de provisionamento de código QR oferece suporte ao provisionamento de extras para definir a hora e o fuso horário em um dispositivo:
Excluindo permanentemente as opções de dados
Os administradores do dispositivo podem mostrar uma mensagem personalizada aos usuários ao remover um perfil
de trabalho ou um usuário secundário. A mensagem ajuda os usuários do dispositivo a entender que o
administrador de TI removeu o perfil de trabalho ou o usuário secundário. Chame
wipeData(int, CharSequence)
e forneça uma breve
mensagem explicativa. Quando chamado pelo usuário principal ou proprietário do dispositivo, o sistema
não mostra uma mensagem e inicia a redefinição do dispositivo para a configuração original.
Para remover dados de assinatura de um chip eUICC incorporado, chame
wipeData()
e inclua WIPE_EUICC
no argumento
flags
.
Métodos para proprietários de perfis afiliados
Os seguintes métodos estão disponíveis para proprietários de perfis afiliados:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()