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

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.

Figura 1. As guias pessoais e de trabalho padrão na tela de início com interruptor para perfil de trabalho

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:

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

  1. Chame DevicePolicyManager.setLockTaskPackages() para adicionar apps à lista de permissões para o modo de bloqueio de tarefas.
  2. 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:

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:

  1. Defina a flag MAKE_USER_EPHEMERAL ao chamar DevicePolicyManager.createAndManageUser().
  2. 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:

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:

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:

  1. Chame DevicePolicyManager.setKeepUninstalledPackages() para especificar a lista de pacotes a serem mantidos como APKs. Para recuperar uma lista desses pacotes, chame DevicePolicyManager.getKeepUninstalledPackages().

  2. Chame DevicePolicyManager.installExistingPackage() para instalar um pacote que foi mantido após a remoção usando setKeepUninstalledPackages().

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:

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:

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:

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:

  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 a transferência.
  3. O sistema torna o DPC de destino o administrador ativo e o define como proprietário do dispositivo gerenciado ou perfil de trabalho.
  4. O DPC de destino recebe o callback onTransferOwnershipComplete() e pode se configurar usando valores do argumento bundle.
  5. 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:

  1. Transfira a propriedade do perfil de trabalho primeiro.
  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 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 (consulte KeyPairGenerator) 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 de ID_TYPE_BASE_INFO, ID_TYPE_SERIAL, ID_TYPE_IMEI ou ID_TYPE_MEID no argumento idAttestationFlags. O certificado retornado inclui os IDs do hardware no registro de confirmação. Se você não quiser incluir os IDs de hardware, transmita 0. Os proprietários de perfis só podem receber informações do fabricante (transmitindo ID_TYPE_BASE_INFO). Para verificar se o dispositivo pode atestar IDs, chame isDeviceIdAttestationSupported().
  • 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étodos DevicePolicyManager:

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

  1. O dispositivo Android gera uma nova chave privada no hardware protegido. 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. O CSR inclui o registro de atestado que contém 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 de atestado.
  4. 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.
  5. O servidor gera um certificado a partir do CSR e o envia ao dispositivo.
  6. 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.

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:

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: