Quais são as novidades do Android 9 para apps corporativos

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.

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:

1. 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.
2. Chamar getProfileSwitchingIconDrawable() para obter um ícone que pode ser usado para representar outro perfil.
3. Chame getProfileSwitchingLabel() para receber texto localizado que solicita que o usuário troque de perfil.
4. 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:

1. Chame DevicePolicyManager.setLockTaskPackages() para colocar apps na lista de permissões para o modo de bloqueio de tarefas.
2. 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 com LOCK_TASK_FEATURE_HOME.
• LOCK_TASK_FEATURE_KEYGUARD
• LOCK_TASK_FEATURE_OVERVIEW só podem ser usadas em combinação com LOCK_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:

1. Defina a flag MAKE_USER_EPHEMERAL ao chamar DevicePolicyManager.createAndManageUser()
2. 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 com onUserRemoved() 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, chame DevicePolicyManager.getStartUserSessionMessage()
• Usar DevicePolicyManager.setEndUserSessionMessage() para definir a mensagem que aparece quando a sessão do usuário termina. Para recupere a mensagem, chame DevicePolicyManager.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:

1. Ligação DevicePolicyManager.setKeepUninstalledPackages() para especificar a lista de pacotes a serem mantidos como APKs. Para recuperar uma lista das pacotes, chame DevicePolicyManager.getKeepUninstalledPackages()

2. Chamar DevicePolicyManager.installExistingPackage() para instalar um pacote que foi mantido após a remoção por meio de setKeepUninstalledPackages()

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 chamando DevicePolicyManager.addUserRestriction() para bloquear a troca de usuários.
• LEAVE_ALL_SYSTEM_APPS_ENABLED é uma sinalização. disponível para DevicePolicyManager.createAndManageUser() Quando definido, os apps do sistema não são desativados durante o provisionamento de usuários.
• UserManager.UserOperationException é gerada por DevicePolicyManager.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:

• setTime()
• setTimeZone()

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:

1. 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.
2. O DPC de origem chama transferOwnership() para iniciar o transferência.
3. O sistema torna o DPC de destino o administrador ativo e define a propriedade do dispositivo gerenciado ou do perfil de trabalho.
4. O DPC de destino recebe o callback onTransferOwnershipComplete() e podem configurar usando valores do argumento bundle.
5. 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:

1. Primeiro, transfira a propriedade do perfil de trabalho.
2. Aguarde o callback DeviceAdminReceiver. onTransferAffiliatedProfileOwnershipComplete() para confirmar que o perfil de trabalho foi transferido para o DPC de destino.
3. 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 (consulte KeyPairGenerator) 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 de ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI ou ID_TYPE_MEID no idAttestationFlags. O certificado retornado inclui o hardware IDs no registro de atestado. Se não quiser que os IDs de hardware sejam incluídos, transmita 0: Os proprietários de perfis só podem receber informações do fabricante (ao transmitir ID_TYPE_BASE_INFO). Para verificar se o dispositivo pode atestar IDs, chame isDeviceIdAttestationSupported().
• 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étodos DevicePolicyManager:
  • setKeyPairCertificate() e transmita false para o argumento isUserSelectable.
  • installKeyPair (ComponentName, PrivateKey, Certificate[], String, int) e omitir INSTALLKEY_SET_USER_SELECTABLE do o argumento flags.

Ao combinar essas APIs, as empresas podem identificar dispositivos e confirmar com segurança a integridade deles antes de conceder acesso:

1. O dispositivo Android gera uma nova chave privada no hardware seguro. Como a chave privada nunca deixa o hardware seguro, ela permanece secreta.
2. 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.
3. 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.
4. 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.
5. O servidor gera um certificado com base na CSR e o envia para o dispositivo.
6. 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().

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:

• USES_POLICY_WIPE_DATA
• USES_POLICY_FORCE_LOCK
• USES_POLICY_RESET_PASSWORD

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:

• EXTRA_PROVISIONING_TIME_ZONE
• EXTRA_PROVISIONING_LOCAL_TIME
• EXTRA_PROVISIONING_LOCALE

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()