Esta página fornece uma visão geral das APIs, dos recursos e do comportamento da empresa que estão disponíveis no Android 9.
Interface do usuário do perfil de trabalho
O Android 9 (nível 28 da API) inclui mudanças de interface do usuário na versão para ajudar os usuários a separar apps pessoais e de trabalho. Fabricantes de dispositivos isso pode apresentar às pessoas apps em guias separadas de trabalho e pessoal. Também ficou mais fácil para os usuários de dispositivos ativarem e desativarem o perfil de trabalho, incluindo uma chave na guia de trabalho.
![](https://developer.android.com/static/images/about/versions/pie/p-work-profile.jpg?authuser=9&hl=pt-br)
Ao provisionar perfis de trabalho e dispositivos gerenciados, o Android 9 inclui ilustrações animadas para ajudar os usuários de dispositivos a entender esses recursos.
Alternar apps entre perfis
O Android 9 inclui APIs para iniciar outra instância de um app em uma
para ajudar os usuários a alternar entre contas. Por exemplo, um app de e-mails pode
fornecer uma interface que permita ao usuário alternar entre o perfil pessoal e o de trabalho
para acessar duas contas de e-mail. Todos os aplicativos podem chamar essas APIs para iniciar a
atividade principal do mesmo app se ele já estiver instalado no outro perfil. Para
adicionar a troca de contas entre perfis ao seu app, siga as etapas abaixo chamando
métodos do
Classe CrossProfileApps
:
- Chame
getTargetUserProfiles()
para receber uma lista dos perfis em que você pode iniciar outra instância do app. Esse método verifica se o app é instalado nos perfis. - Chamar
getProfileSwitchingIconDrawable()
para obter um ícone que pode ser usado para representar outro perfil. - Chame
getProfileSwitchingLabel()
para receber texto localizado que solicita que o usuário troque de perfil. - Chame
startMainActivity()
para iniciar uma instância do seu app em outro perfil.
Verifique se a atividade principal que você quer iniciar foi declarada no arquivo
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 apps que têm a permissão MANAGE_USERS
ou
MODIFY_QUIET_MODE
) pode 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 a
antes que o estado mude. Como a mudança pode não acontecer
instantaneamente, ouça o
ACTION_MANAGED_PROFILE_AVAILABLE
ou
ACTION_MANAGED_PROFILE_UNAVAILABLE
transmissão 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, proprietários de dispositivos e de perfis (de usuários secundários) pode bloquear qualquer app na tela de um dispositivo, colocando o app no modo de bloqueio de tarefas. Antes, os desenvolvedores de apps precisavam adicionar suporte a tarefas de bloqueio nos apps deles. O Android 9 também estende a tarefa de bloqueio APIs 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 colocar apps na lista de permissões para o modo de bloqueio de tarefas. - Chame
ActivityOptions.setLockTaskEnabled()
para iniciar um app na lista de permissões para o modo de bloqueio de tarefas.
Para interromper um app no modo de bloqueio de tarefas, remova-o desse modo
adicionar à lista de permissões usando
DevicePolicyManager.setLockTaskPackages()
Ativar recursos da interface do sistema
Quando o modo de bloqueio de tarefas está ativado, os proprietários de dispositivos e de perfis podem ativá-lo
alguns recursos de interface do sistema no dispositivo chamando
DevicePolicyManager.setLockTaskFeatures()
e transmitindo um
campo de bit dos seguintes sinalizadores de recurso:
LOCK_TASK_FEATURE_NONE
LOCK_TASK_FEATURE_SYSTEM_INFO
LOCK_TASK_FEATURE_HOME
LOCK_TASK_FEATURE_NOTIFICATIONS
só podem ser usadas em combinação comLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_KEYGUARD
LOCK_TASK_FEATURE_OVERVIEW
só podem ser usadas em combinação comLOCK_TASK_FEATURE_HOME
.LOCK_TASK_FEATURE_GLOBAL_ACTIONS
Você pode chamar DevicePolicyManager.getLockTaskFeatures()
para conferir a lista de recursos disponíveis em um dispositivo quando o modo de bloqueio de tarefas está ativado
ativado. Quando um dispositivo sai do modo de bloqueio de tarefas, ele retorna ao estado determinado pelo
outras políticas do dispositivo.
Suprimir caixas de diálogo de erro
Em alguns ambientes, como demonstrações na loja ou informações públicas
for exibido, talvez você não queira mostrar caixas de diálogo de erro aos usuários. Uma política do dispositivo
controlador (DPC) pode suprimir caixas de diálogo de erro do sistema para falhas ou respostas
adicionando o
Usuário do DISALLOW_SYSTEM_ERROR_DIALOGS
e a segunda é a restrição de recursos. 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
afetam perfis de trabalho.
No Android 9, os apps executados em tela cheia imersiva modo não mostram o balão do lembrete quando estão modo de bloqueio de atividade. O balão de lembrete é um painel mostrado aos usuários (na primeira inicialização) que explica como sair do modo imersivo.
Suporte a vários usuários em dispositivos dedicados
O Android 9 introduz o conceito de usuário efêmero para serviços dedicados (anteriormente chamados de dispositivos COSU). Usuários temporários são usuários de curto prazo destinados a casos em que vários usuários compartilham uma única um dispositivo dedicado. Isso inclui sessões públicas de usuários em dispositivos como biblioteca ou quiosques de check-in de hospitalidade, bem como sessões persistentes entre uma conjunto de usuários em dispositivos, por exemplo, funcionários que trabalham em turnos.
Os usuários efêmeros devem ser criados no segundo plano. Eles são criados usuários secundários em um dispositivo e são removidos (junto com os aplicativos e aplicativos associados dados) quando eles forem interrompidos, alternados ou o dispositivo for reinicializado. Para criar um usuários temporários, os proprietários de dispositivos podem:
- Defina a flag
MAKE_USER_EPHEMERAL
ao chamarDevicePolicyManager.createAndManageUser()
- Chamar
DevicePolicyManager.startUserInBackground()
para iniciar o usuário temporário em segundo plano.
Os apps direcionados ao Android 9 devem entender
UserManager.UserOperationException
ao ligar
createAndManageUser()
. Chame o método
getUserOperationResult()
para descobrir por que o
usuário não foi criado.
Receber notificações de eventos
O DeviceAdminReceiver
recebe notificações das
seguintes eventos:
onUserStarted()
: chamado quando um usuário é iniciado.onUserSwitched()
: chamado quando uma chave de usuário é chamada. é concluída.onUserStopped()
: chamado junto comonUserRemoved()
quando um usuário interrompe ou registra para fora.
Mostrar mensagens de eventos aos usuários
Os proprietários de dispositivos podem configurar as mensagens que são exibidas aos usuários quando eles iniciar e encerrar as sessões:
- Usar
DevicePolicyManager.setStartUserSessionMessage()
para definir a mensagem que é exibida quando a sessão do usuário começa. Para recupere a mensagem, chameDevicePolicyManager.getStartUserSessionMessage()
- Usar
DevicePolicyManager.setEndUserSessionMessage()
para definir a mensagem que aparece quando a sessão do usuário termina. Para recupere a mensagem, chameDevicePolicyManager.getEndUserSessionMessage()
Desconectar e interromper usuários
Os proprietários de dispositivos podem usar
DevicePolicyManager.setLogoutEnabled()
para especificar
o logout está ativado para usuários secundários. Para verificar se o logout está ativado, chame
DevicePolicyManager.isLogoutEnabled()
Os proprietários de perfis de usuários secundários podem ligar
DevicePolicyManager.logoutUser()
para interromper o usuário secundário e
volte para o usuário principal.
Os proprietários de dispositivos podem usar o DevicePolicyManager.stopUser()
para interromper uma
usuário secundário especificado.
Armazenamento de pacotes em cache
Para simplificar o provisionamento de usuários em dispositivos compartilhados com um conjunto fixo de usuários, como dispositivos para workers de turno, é possível armazenar em cache pacotes necessárias para sessões multiusuário:
Ligação
DevicePolicyManager.setKeepUninstalledPackages()
para especificar a lista de pacotes a serem mantidos como APKs. Para recuperar uma lista das pacotes, chameDevicePolicyManager.getKeepUninstalledPackages()
Chamar
DevicePolicyManager.installExistingPackage()
para instalar um pacote que foi mantido após a remoção por meio desetKeepUninstalledPackages()
Outros métodos e constantes
O Android 9 também inclui os métodos e constantes a seguir para maior compatibilidade sessões do usuário 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 você pode ative chamandoDevicePolicyManager.addUserRestriction()
para bloquear a troca 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
é gerada porDevicePolicyManager.createAndManageUser()
quando não é possível criar um usuário. exceção contém o motivo da falha.
Limpar dados do pacote e remover contas
Os proprietários de dispositivos e perfis podem ligar
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 ligar
removeAccount()
Restrições de usuários e maior controle sobre as configurações
O Android 9 introduz um conjunto de restrições de usuário para DPCs, bem como a capacidade de configurar APNs, horário, fuso horário e configurações do sistema em um dispositivo.
Configurar APNs
Os proprietários de dispositivos podem usar os seguintes métodos na
DevicePolicyManager
para configurar APNs em um
dispositivo:
addOverrideApn()
updateOverrideApn()
removeOverrideApn()
getOverrideApns()
setOverrideApnEnabled()
isOverrideApnEnabled()
Configurar hora e fuso horário
Os proprietários de dispositivos podem usar os seguintes métodos na
DevicePolicyManager
para definir o horário 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
adicione uma restrição, chame
DevicePolicyManager.addUserRestriction()
por um dos
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 DISALLOW_CONFIG_BRIGHTNESS
e
DISALLOW_CONFIG_SCREEN_TIMEOUT
são aplicadas
em um dispositivo, os proprietários ainda podem definir a tela
brilho, brilho da tela
modo e tempo limite da tela
no dispositivo usando a API
DevicePolicyManager.setSystemSetting()
.
Dados medidos
Proprietários de dispositivos e de perfil podem impedir que apps usem o
redes de dados limitadas. Uma rede é considerada limitada quando o usuário
sensíveis ao uso intenso de dados devido a custo, limites de dados ou bateria e
problemas de desempenho. Para impedir que apps usem redes limitadas, chame
DevicePolicyManager.setMeteredDataDisabledPackages()
passando uma lista de nomes de pacotes. Para recuperar os aplicativos restritos no momento, chame
DevicePolicyManager.getMeteredDataDisabledPackages()
Para saber mais sobre dados limitados no Android, leia Como otimizar dados de rede Uso.
Migrar DPCs
Os controladores de política do dispositivo (DPCs) podem transferir a propriedade de um dispositivo ou do perfil de trabalho para outro DPC. Você pode transferir a propriedade para mover alguns recursos na página Gerenciamento do Android API, para migrar os dispositivos seu DPC legado ou ajudar os administradores de TI a migrar para o EMM. Porque você está apenas alterar a propriedade do DPC, não poderá usar esse recurso para alterar o tipo de como a migração de um dispositivo gerenciado para um perfil de trabalho ou vice-versa.
Você pode usar o recurso XML de políticas de administrador do dispositivo para
indicar que essa versão do DPC é compatível com a migração. Um DPC de destino
indica que pode receber propriedade ao incluir um elemento chamado
<support-transfer-ownership>
: O exemplo abaixo mostra como você pode fazer isso em
o arquivo XML de 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 podem verificar se a propriedade de um DPC
oferece suporte à migração chamando o método DeviceAdminInfo
supportsTransferOwnership()
. Antes de transferir
é responsabilidade do DPC de origem verificar o DPC de destino
e comparar assinaturas de apps. A classe PackageManager
inclui
para trabalhar com assinaturas de assinatura de código.
O Android mantém as políticas do sistema e do usuário do DPC de origem por uma propriedade
transferência, já que os DPCs não precisam migrá-las. Um DPC de origem pode passar dados personalizados para
o DPC de destino usando pares de chave-valor em um PersistableBundle
. Após um
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 perfil de trabalho são as o mesmo:
- 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 o transferência. - O sistema torna o DPC de destino o administrador ativo e define a propriedade do dispositivo gerenciado ou do perfil de trabalho.
- O DPC de destino recebe o callback
onTransferOwnershipComplete()
e podem configurar usando valores do argumentobundle
. - Se algo der errado com a transferência, o sistema reverterá a propriedade para
ao DPC de origem. Se o DPC de origem precisar confirmar que a transferência de propriedade
for bem-sucedido, 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 o
ACTION_PROFILE_OWNER_CHANGED
são transmitidos quando
o proprietário do perfil muda. Os apps executados em um dispositivo gerenciado recebem
ACTION_DEVICE_OWNER_CHANGED
são transmitidas quando o
pelo proprietário do dispositivo.
Perfis de trabalho em dispositivos totalmente gerenciados
Transferência de duas instâncias de um DPC executado como proprietário do dispositivo e proprietário do perfil acontece em duas etapas. Quando o perfil pessoal e o perfil de trabalho são afiliado, conclua a transferência na seguinte ordem:
- Primeiro, transfira a propriedade do perfil de trabalho.
- 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 OTA
Os proprietários de dispositivos podem adiar as atualizações OTA do sistema por até 90 dias para congelam a versão do SO em execução nesses dispositivos durante períodos críticos (como datas comemorativas). O sistema aplica um buffer obrigatório de 60 dias após qualquer período de congelamento para evitar o congelamento do dispositivo 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 do dispositivo 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 congelamento
se repete anualmente, as datas de início e término do período são representadas
por números inteiros, contando o número de dias desde o início do ano. A data de início deve
começará pelo menos 60 dias após o término de qualquer período de congelamento anterior. Dispositivo
proprietários podem chamar SystemUpdatePolicy.getFreezePeriods()
para
acessar uma lista de períodos de congelamento definidos anteriormente no objeto da política de atualização do sistema.
DevicePolicyManager.getSystemUpdatePolicy()
foi
atualizado para retornar 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.
Depois de definir essa restrição, seu DPC ainda poderá permitir atividades entre perfis
intents 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 você pode se combinam para identificar dispositivos com segurança. Um DPC em execução no dispositivo ou proprietário do perfil de proprietário ou um instalador de certificados delegado, podem conclua as seguintes tarefas:
- Gerar chaves e certificados no hardware seguro (como um ambiente
ambiente de execução (TEE) ou Elemento de segurança (SE) do dispositivo Android. A
as chaves geradas nunca saem do hardware protegido e podem ser usadas na plataforma
KeyChain (em inglês). Ligação
DevicePolicyManager.generateKeyPair()
fornecendo o algoritmo (consulteKeyPairGenerator
) e todos os IDs de hardware que você como o número de série ou o IMEI. Para saber mais sobre segurança mudanças de hardware, consulte a documentação de Segurança e melhorias de desempenho. - Associe um certificado a uma chave atual gerada pelo dispositivo. Ligação
DevicePolicyManager.setKeyPairCertificate()
fornecendo o alias da chave existente e da cadeia de certificados, começando com a folha certificado e incluindo a cadeia de confiança em ordem. - Confirme se o hardware protegido protege a chave antes de usá-la. Para verificar quais mecanismos protegem a chave, siga as etapas em Chave Atestado.
- Os proprietários de dispositivos e os instaladores de certificados delegados podem receber
dos dispositivos IDs de hardware com versões do sistema Android. Ligação
DevicePolicyManager.generateKeyPair()
transmitindo um ou mais deID_TYPE_BASE_INFO
,ID_TYPE_SERIAL
,ID_TYPE_IMEI
ouID_TYPE_MEID
noidAttestationFlags
. O certificado retornado inclui o hardware IDs no registro de atestado. Se não quiser que os IDs de hardware sejam incluídos, transmita0
: Os proprietários de perfis só podem receber informações do fabricante (ao transmitirID_TYPE_BASE_INFO
). Para verificar se o dispositivo pode atestar IDs, chameisDeviceIdAttestationSupported()
. - Impedir que os usuários do dispositivo usem chaves empresariais indevidamente (em tarefas não corporativas)
desfazendo os certificados-chave não selecionáveis. O sistema não inclui
não selecionáveis no painel do seletor. Em seu
DeviceAdminReceiver.onChoosePrivateKeyAlias()
método de callback, retorne o alias para sua chave empresarial para que o sistema seleciona automaticamente o certificado em nome do usuário. Para fazer uma chave não selecionáveis, chame os seguintes métodosDevicePolicyManager
:setKeyPairCertificate()
e transmitafalse
para o argumentoisUserSelectable
.installKeyPair (ComponentName, PrivateKey, Certificate[], String, int)
e omitirINSTALLKEY_SET_USER_SELECTABLE
do o argumentoflags
.
Ao combinar essas APIs, as empresas podem identificar dispositivos e confirmar com segurança a integridade deles antes de conceder acesso:
- O dispositivo Android gera uma nova chave privada no hardware seguro. 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. A CSR inclui o registro do atestado que contém a e 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 do atestado.
- O servidor confirma que o hardware seguro protege a chave privada e se 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 com base na CSR e o envia para o dispositivo.
- O dispositivo pareia o certificado com a chave privada (que permanece no hardware seguro), permitindo que os apps se conectem a serviços empresariais.
Mais APIs, recursos e alterações de segurança
IDs para registros de segurança e de rede
O Android 9 inclui IDs em registros de atividades de segurança e rede. O ID numérico aumenta monotonicamente para cada evento, facilitando a detecção ou lacunas nos registros. Como os registros de segurança e de rede são separados coleções, 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 quando o dispositivo é reiniciado.
Registros de segurança buscados por chamada
DevicePolicyManager.retrievePreRebootSecurityLogs()
não incluam 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 descobrir 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 em segurança
registros do Terraform. Para verificar a tag de um evento, chame getTag()
. Para
recupere 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 |
Um certificado de Wi-Fi falhou em uma verificação de validação durante a conexão. |
TAG_CRYPTO_SELF_TEST_COMPLETED |
O sistema concluiu o autoteste criptográfico. |
TAG_KEYGUARD_DISABLED_FEATURES_SET |
Um app de administração desativou os recursos da tela de bloqueio de um dispositivo ou perfil de trabalho. |
TAG_KEY_DESTRUCTION |
Uma tentativa de excluir uma chave criptográfica. |
TAG_KEY_GENERATED |
Uma tentativa de gerar uma nova chave criptográfica. |
TAG_KEY_IMPORT |
Uma tentativa de importar uma nova chave criptográfica. |
TAG_KEY_INTEGRITY_VIOLATION |
O Android detectou uma criptografia ou chave de 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 de registro de segurança atingiu 90% da capacidade. |
TAG_MAX_PASSWORD_ATTEMPTS_SET |
Um app de administração definiu o número de tentativas permitidas com a senha incorreta. |
TAG_MAX_SCREEN_LOCK_TIMEOUT_SET |
Um app de administração definiu um tempo limite máximo para o bloqueio de tela. |
TAG_MEDIA_MOUNT |
O dispositivo ativou 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 administração definiu uma duração de validade de senha. |
TAG_PASSWORD_HISTORY_LENGTH_SET |
Um app de administração definiu o tamanho do histórico de senhas, evitando 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 administração 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 na tentativa de 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 bloqueio separado
desafio de segurança no perfil de trabalho usando o
Restrição de usuário do DISALLOW_UNIFIED_PASSWORD
. Para
Verifique se um usuário tem o mesmo desafio de bloqueio de tela definido para seu dispositivo e
perfil de trabalho, chamada
DevicePolicyManager.isUsingUnifiedPassword()
Se um dispositivo tiver uma tela de bloqueio separada para perfis de trabalho,
O DevicePolicyManager.setMaximumTimeToLock()
só define
tempo limite da tela de bloqueio no perfil de trabalho e não no dispositivo todo.
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.
Compatibilidade com mais opções biométricas
O Android 9 adiciona controle refinado sobre a autenticação de hardware biométrica em uma
na tela de bloqueio do perfil de trabalho. Chamar o método
DevicePolicyManager.setKeyguardDisabledFeatures()
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 dispositivos do Google Cloud. 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. Para como bloquear e excluir permanentemente os dados de um dispositivo perdido. As políticas a seguir continuarão estar disponíveis para ativar isso:
Saiba mais sobre essas mudanças em Administrador do dispositivo descontinuação.
Registro simplificado de QR code
Biblioteca de QR code integrada
O Android 9 vem com uma biblioteca QR para simplificar o dispositivo na nuvem. Os administradores de TI não precisam mais inserir manualmente os detalhes do Wi-Fi para configurar um dispositivo. Em vez disso, no Android 9, é possível incluir estes detalhes em um QR code. Quando um administrador de TI lê o QR code com uma empresa da empresa dispositivo, ele se conecta automaticamente ao Wi-Fi e insere o sem nenhuma outra entrada manual.
O método de provisionamento por QR code é compatível com os 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 extras de provisionamento
O método de provisionamento por QR code é compatível com o provisionamento de extras para definir a hora e fuso horário em um dispositivo:
Opções de dados sendo excluídos permanentemente
Os administradores do dispositivo podem mostrar uma mensagem personalizada aos usuários ao remover um trabalho.
ou usuário secundário. A mensagem ajuda os usuários de dispositivos a entender que
O administrador de TI removeu o perfil de trabalho ou o usuário secundário. Ligação
wipeData(int, CharSequence)
e forneça um Short
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 os dados de assinatura de um chip eUICC incorporado, chame
wipeData()
e incluir WIPE_EUICC
no flags
.
Métodos para proprietários de perfil afiliados
Os seguintes métodos estão disponíveis para o perfil afiliado proprietários:
DevicePolicyManager.setKeyguardDisabled()
DevicePolicyManager.setStatusBarDisabled()
PackageInstaller.createSession()