Novidades para empresas no Android 10

Esta página fornece uma visão geral dos novos recursos, mudanças de comportamento e APIs empresariais introduzidos no Android 10.

Perfis de trabalho para dispositivos corporativos

O Android 10 introduz novos recursos de provisionamento e atestado para dispositivos corporativos que requerem apenas um perfil de trabalho.

Ferramentas de provisionamento aprimoradas para perfis de trabalho

É possível provisionar perfis de trabalho em dispositivos com Android 10 e versões posteriores usando código QR ou Sem toque. Durante o provisionamento de um dispositivo corporativo, um novo intent extra permite que os apps do controlador de políticas de dispositivo (DPCs, na sigla em inglês) introduzam um perfil de trabalho ou uma configuração totalmente gerenciada. Depois da criação de um perfil de trabalho ou da definição de um gerenciamento total, os DPCs precisam abrir telas de conformidade com as políticas para impor qualquer política inicial.

No arquivo de manifesto do seu DPC, declare um novo filtro de intent para GET_PROVISIONING_MODE em uma atividade e adicione a permissão BIND_DEVICE_ADMIN para evitar que apps arbitrários iniciem a atividade. Exemplo:

<activity
    android:name=".GetProvisioningModeActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action
            android:name="android.app.action.GET_PROVISIONING_MODE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Durante o provisionamento, o sistema inicia a atividade associada ao filtro de intent. O objetivo dessa atividade é especificar um modo de gerenciamento (perfil de trabalho ou totalmente gerenciado).

Pode ser vantajoso recuperar os extras de provisionamento antes de determinar o modo de gerenciamento apropriado para o dispositivo. A atividade pode chamar getIntent() para recuperar o seguinte:

Os DPCs também podem criar um novo intent de resultado e adicionar os seguintes extras a ele:

Para definir o modo de gerenciamento no dispositivo, chame putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode), em que desiredProvisioningMode é:

  • Perfil de trabalho: PROVISIONING_MODE_MANAGED_PROFILE
  • Totalmente gerenciado: PROVISIONING_MODE_FULLY_MANAGED_DEVICE

Conclua o provisionamento do perfil de trabalho ou totalmente gerenciado enviando os detalhes de provisionamento de volta para a configuração via setResult(RESULT_OK, Intent) e feche todas as telas ativas com finish().

Após concluir o provisionamento, um novo intent estará disponível para que os DPCs iniciem as telas de conformidade e apliquem as configurações da política inicial. Nos dispositivos com perfil de trabalho, as telas de conformidade são exibidas nesse perfil. O DPC precisa garantir que as telas de conformidade sejam exibidas aos usuários, mesmo que um usuário pule o fluxo de configuração.

No arquivo de manifesto do seu DPC, declare um novo filtro de intent para ADMIN_POLICY_COMPLIANCE em uma atividade e adicione a permissão BIND_DEVICE_ADMIN para evitar que apps arbitrários iniciem a atividade. Exemplo:

<activity
    android:name=".PolicyComplianceActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action android:name="android.app.action.ADMIN_POLICY_COMPLIANCE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Seu DPC precisa usar esse novo intent em vez de detectar a transmissão de ACTION_PROFILE_PROVISIONING_COMPLETE.

A atividade associada ao filtro de intent pode chamar getIntent() para recuperar o EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE. Depois de realizar a conformidade com a política, ADMIN_POLICY_COMPLIANCE precisa retornar setResult(RESULT_OK, Intent) e fechar todas as telas ativas com finish().

Dispositivos totalmente gerenciados retornam os usuários à tela inicial. Os dispositivos com perfil de trabalho solicitam aos usuários que adicionem uma conta pessoal antes de retorná-los à tela inicial.

Atestado de código de dispositivo do perfil de trabalho

Os DPCs definidos como administradores de um perfil de trabalho provisionado usando o registro sem toque podem receber códigos de dispositivos com atestado de hardware seguro, como um IMEI ou o número de série do fabricante. O dispositivo precisa incluir um hardware seguro, por exemplo, 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), e precisa ser compatível com o atestado de código do dispositivo e o registro sem toque.

O componente de administração de um perfil de trabalho pode chamar DevicePolicyManager.generateKeyPair(), transmitindo um ou mais de ID_TYPE_SERIAL, ID_TYPE_IMEI ou ID_TYPE_MEID para o argumento idAttestationFlags.

Para saber mais sobre como extrair e validar códigos de dispositivos, consulte Como verificar pares de chaves protegidos por hardware com confirmação de chaves.

Melhorias no perfil de trabalho

Novas APIs estão disponíveis para oferecer a possibilidade de visualizar agendas entre perfis e bloquear a instalação de apps no dispositivo por fontes desconhecidas.

Fontes desconhecidas pelo dispositivo em perfis de trabalho

Apps transferidos de fontes que não sejam o Google Play (ou outras app stores confiáveis) são chamados de apps de fontes desconhecidas. No Android 10, os admins de perfis de trabalho podem impedir que qualquer usuário ou perfil instale apps de fontes desconhecidas em qualquer lugar do dispositivo adicionando a nova restrição de usuário DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY. No entanto, depois de adicionar essa restrição, uma pessoa que usa o dispositivo ainda pode instalar apps usando o adb.

Para evitar que os usuários instalem apps de fontes desconhecidas por engano, recomendamos que você adicione essa restrição de usuário, visto que isso não exige a instalação do Google Play Services. Se você quiser compatibilidade com versões mais antigas do Android, defina um valor de configuração gerenciada para o Google Play.

Limitar dispositivos de entrada permitidos para perfis de trabalho

Quando os administradores dos perfis de trabalho chamam DevicePolicyManager.setPermittedInputMethods(), os usuários só ficam restringidos aos métodos de entrada permitidos dentro do perfil de trabalho, e não em todo o dispositivo. Isso dá aos usuários controle total dos métodos de entrada na área pessoal do dispositivo.

Excluir permanentemente perfis de trabalho de forma silenciosa

Adicionamos a flag WIPE_SILENTLY a DevicePolicyManager.wipeData(). Se o flag for definido, os usuários não vão receber uma notificação quando o perfil de trabalho for excluído permanentemente usando wipeData().

Novos recursos para dispositivos totalmente gerenciados

O Android 10 introduz novos recursos e APIs para dispositivos totalmente gerenciados, incluindo atualizações manuais do sistema, ampliação do código QR e provisionamento de NFC para incluir as credenciais de uma rede Wi-Fi EAP e compatibilidade com o DNS via TLS.

Instalação manual da atualização do sistema

No Android 10, os administradores de dispositivos totalmente gerenciados podem instalar atualizações do sistema por meio de um arquivo de atualização do sistema. As atualizações manuais do sistema permitem que os administradores de TI façam o seguinte:

  • Testem uma atualização em um pequeno número de dispositivos antes de instalá-la em todos.
  • Evitem downloads duplicados em redes com largura de banda limitada.
  • Distribuam as instalações ou atualizem os dispositivos apenas quando eles não estiverem sendo usados.

Primeiro, um administrador de TI define uma política de atualização do sistema adiada para atrasar a instalação automática (se necessário). Em seguida, o DPC do dispositivo chama installSystemUpdate() com o caminho para o arquivo de atualização do sistema de um fabricante de dispositivo. Transmita um objeto InstallSystemUpdateCallback que o sistema possa usar para relatar erros que acontecerem antes da reinicialização do dispositivo. Se algo der errado, o sistema vai chamar onInstallUpdateError() com o código do erro.

Depois que o dispositivo for reiniciado, seu DPC precisará confirmar a conclusão da instalação usando uma API de versão, como Build.FINGERPRINT. Se a atualização falhar, informe a falha a um administrador de TI.

Provisionamento de Wi-Fi EAP

No Android 10, os códigos QR e os dados de NFC usados no provisionamento de dispositivos podem conter credenciais e configurações de EAP, incluindo certificados. Quando uma pessoa lê um QR code ou toca em uma tag NFC, o dispositivo faz automaticamente uma autenticação para uma rede Wi-Fi local usando o EAP e inicia o processo de provisionamento sem nenhuma outra entrada manual.

Para autenticar o Wi-Fi usando EAP, adicione um extra EXTRA_PROVISIONING_WIFI_SECURITY_TYPE com o valor "EAP". Para especificar a autenticação EAP, você pode adicionar os seguintes extras de provisionamento ao seu intent:

Compatibilidade com DNS privado

As organizações podem usar o DNS via TLS (chamado de DNS particular em dispositivos Android) para evitar o vazamento de consultas DNS, incluindo as de nomes de host internos. Os componentes de administração de dispositivos totalmente gerenciados podem controlar as configurações de DNS particular do dispositivo. Para definir o modo de DNS particular, chame:

Quando o DPC chamar um desses métodos, o sistema retornará PRIVATE_DNS_SET_NO_ERROR se a chamada for realizada. Caso contrário, ele retornará um erro.

Para recuperar o modo de DNS particular e o conjunto de hosts em um dispositivo, chame getGlobalPrivateDnsMode() e getGlobalPrivateDnsHost(). Você pode impedir que os usuários mudem as configurações de DNS particular adicionando a restrição de usuário DISALLOW_CONFIG_PRIVATE_DNS.

Isenção do modo de bloqueio total de VPN

O modo de bloqueio total de VPN permite que um DPC bloqueie qualquer tráfego de rede que não use a VPN. Os administradores de dispositivos totalmente gerenciados e perfis de trabalho podem isentar apps do modo de bloqueio total. Por padrão, apps isentos usam uma VPN, mas se conectam automaticamente a outras redes se a VPN não estiver disponível. Apps isentos que o acesso à VPN também seja explicitamente negado só usarão outras redes.

Para isentar um app do modo de bloqueio, chame o novo método DevicePolicyManager setAlwaysOnVpnPackage() que aceita uma lista de pacotes de apps isentos. Todo pacote de apps adicionado pelo DPC precisa ser instalado no dispositivo quando o método for chamado. Se um app for desinstalado e reinstalado, ele precisará ser isentado novamente. Para ver os apps que foram isentados anteriormente do modo de bloqueio total, chame getAlwaysOnVpnLockdownWhitelist().

Para ajudar os administradores de dispositivos totalmente gerenciados e perfis de trabalho a conseguir o status do modo de bloqueio total, o Android 10 acrescenta o método isAlwaysOnVpnLockdownEnabled().

Novos escopos de delegação

O Android 10 amplia a lista de funções que um DPC pode delegar a outros apps mais especializados. O Android agrupa os métodos de API necessários para uma tarefa em escopos. Para delegar um escopo, chame setDelegatedScopes() e transmita um ou mais dos seguintes escopos:

O Android 10 introduz a nova classe DelegatedAdminReceiver para apps delegados. O sistema usa esse broadcast receiver para enviar callbacks do tipo DPC para delegar apps. Os apps a que o registro de atividades de rede e a seleção de certificados foram delegados precisam implementar essa classe. Para adicionar esse componente a um app delegado, siga estas etapas:

  1. Adicione uma subclasse de DelegatedAdminReceiver ao app delegado.
  2. Declare o <receiver> no manifesto do app, adicionando uma ação de filtro de intent para cada callback. Por exemplo, ACTION_NETWORK_LOGS_AVAILABLE ou ACTION_CHOOSE_PRIVATE_KEY_ALIAS.
  3. Proteja o broadcast receiver com a permissão BIND_DEVICE_ADMIN.

O snippet a seguir mostra o manifesto do app de um único app delegado que gerencia tanto o registro de rede quanto a seleção de certificado:

<receiver android:name=".app.DelegatedAdminReceiver"
        android:permission="android.permission.BIND_DELEGATED_ADMIN">
    <intent-filter>
        <action android:name="android.app.admin.action.NETWORK_LOGS_AVAILABLE">
        <action android:name="android.app.action.CHOOSE_PRIVATE_KEY_ALIAS">
    </intent-filter>
    </receiver>

Registro de atividades de rede

Para ajudar as organizações a detectar e rastrear malware, os DPCs podem registrar conexões TCP e buscas DNS pelo sistema. No Android 10, os administradores de dispositivos totalmente gerenciados podem delegar o registro de rede a um app especializado.

Para recuperar registros da rede após o sistema disponibilizar um lote, os apps delegados precisam primeiro subclassificar DelegatedAdminReceiver (descrito anteriormente). Na subclasse, implemente o callback onNetworkLogsAvailable() seguindo as orientações em Recuperar registros.

Os apps delegados podem chamar os seguintes métodos DevicePolicyManager (transmitindo null para o argumento admin):

Para evitar a perda de registros, os DPCs não podem ativar o registro de rede se planejarem delegar para outro app. O app delegado precisa ativar e coletar registros de rede. Depois que um DPC delega o registro de rede, ele não recebe mais callbacks onNetworkLogsAvailable().

Para saber como relatar o registro de atividades de rede de um app delegado, leia o guia do desenvolvedor Registro de atividades de rede.

Seleção de certificado

No Android 10, os administradores de dispositivos totalmente gerenciados, perfis de trabalho e usuários secundários podem delegar a seleção de certificados a um app especializado.

Para selecionar um alias de certificado, os apps delegados precisam primeiro subclassificar DelegatedAdminReceiver (descrito anteriormente). Na sua subclasse, implemente o callback onChoosePrivateKeyAlias() e retorne um alias para um certificado preferido ou, para pedir que o usuário selecione um certificado, retorne null.

Suspensão do uso de políticas administrativas dos dispositivos

O Android 10 impede que os apps e DPCs apliquem as políticas legadas de administração de dispositivos. Recomendamos que os clientes e parceiros façam a transição para dispositivos totalmente gerenciados ou perfis de trabalho. As políticas a seguir geram uma SecurityException quando são invocadas por um administrador de dispositivo destinado ao Android 10:

Alguns apps usam o administrador do dispositivo para administração do dispositivo do consumidor. Por exemplo, para bloquear e excluir permanentemente os dados de um dispositivo perdido. Para ativar esse recurso, as políticas a seguir continuam disponíveis:

Para mais informações sobre essas mudanças, leia Suspensão de uso da administração do dispositivo.

Novos recursos para apps

Os apps destinados ao Android 10 podem consultar a complexidade de bloqueio de tela definida em um dispositivo antes de exibir dados confidenciais ou abrir recursos essenciais. Os apps que chamam a API KeyChain são beneficiados pelas melhorias de comportamento, e novos recursos também estão disponíveis para apps de VPN.

Verificação de qualidade do bloqueio de tela

A partir do Android 10, apps com recursos essenciais que exigem um bloqueio de tela podem consultar a complexidade do bloqueio de tela de um dispositivo ou de um perfil de trabalho. Apps que precisam de um bloqueio de tela mais forte podem direcionar o usuário para as configurações de bloqueio de tela do sistema e permitir que ele atualize as configurações de segurança.

Para verificar a qualidade do bloqueio de tela:

Para iniciar as configurações de bloqueio de tela do sistema, use ACTION_SET_NEW_PASSWORD com o extra EXTRA_PASSWORD_COMPLEXITY. As opções que não atendem à complexidade especificada no extra de intent ficam esmaecidas. O usuário pode escolher entre as opções de bloqueio de tela disponíveis ou sair da tela.

Prática recomendada:exiba uma mensagem no seu app antes de abrir a página de bloqueio de tela do sistema. Quando o app retomar a execução, chame DevicePolicyManager.getPasswordComplexity() novamente. Se um bloqueio de tela mais forte for necessário, restrinja o acesso em vez de solicitar repetidamente que os usuários atualizem as configurações de segurança.

Compatibilidade com proxy HTTP em apps de VPN

No Android 10, os apps de VPN podem configurar um proxy HTTP para a conexão VPN deles. Para adicionar um proxy HTTP, um app de VPN precisa configurar uma instância ProxyInfo com um host e uma porta antes de chamar VpnService.Builder.setHttpProxy(). O sistema e muitas bibliotecas de rede usam essa configuração de proxy, mas o sistema não força os apps a solicitações de proxy HTTP.

Para ver o exemplo de código que mostra como configurar um Proxy HTTP, consulte o app de exemplo ToyVPN.

Modos de serviço de VPN

Os apps de VPN podem descobrir se o serviço está sendo executado devido à VPN sempre ativa e se o modo de bloqueio total está ativo. Novos métodos adicionados ao Android 10 podem ajudar você a ajustar sua interface do usuário. Por exemplo, você pode desativar o botão "desconectar" quando uma VPN sempre ativa controlar o ciclo de vida do seu serviço.

Os apps de VPN podem chamar os seguintes métodos VpnService depois de se conectar ao serviço e estabelecer a interface local:

  • isAlwaysOn() para descobrir se o sistema iniciou o serviço devido à VPN sempre ativa.
  • isLockdownEnabled() para descobrir se o sistema está bloqueando conexões que não usam a VPN

O status "sempre ativo" permanece o mesmo enquanto o serviço está em execução, mas o status do modo de bloqueio total pode mudar.

Melhorias no Keychain

O Android 10 inclui várias melhorias relacionadas à API KeyChain.

Quando um app chama KeyChain.choosePrivateKeyAlias(), os dispositivos com Android 10 e versões mais recentes filtram a lista de certificados à disposição do usuário com base nos emissores e principais algoritmos especificados na chamada.

Por exemplo, quando um servidor TLS envia uma mensagem de Solicitação de certificado como parte de um handshake de TLS, e o navegador chama KeyChain.choosePrivateKeyAlias(), a solicitação para seleção de certificado só inclui opções que correspondem ao parâmetro do emissor. Se nenhuma opção correspondente estiver disponível ou se não houver certificados instalados no dispositivo, o prompt de seleção não será exibido para o usuário.

Além disso, o KeyChain não exige mais que o dispositivo tenha bloqueio de tela antes de importar chaves ou certificados de CA.