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 apresenta novos recursos de provisionamento e atestado para dispositivos da empresa que exigem 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 mais recentes usando código QR ou o recurso Sem toque. Durante o provisionamento de um dispositivo da empresa, um novo intent extra permite que os apps controladores de política de dispositivo (DPCs, na sigla em inglês) iniciem um perfil de trabalho ou uma configuração totalmente gerenciada. Depois que um perfil de trabalho é criado ou o gerenciamento completo é estabelecido, os DPCs precisam abrir telas de conformidade com as políticas para aplicar as políticas iniciais.

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 impedir que apps arbitrários iniciem a atividade. Por 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 útil 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 perfil de trabalho ou o provisionamento totalmente gerenciado enviando os detalhes de provisionamento de volta para a configuração pelo setResult(RESULT_OK, Intent) e feche todas as telas ativas com finish().

Após a conclusão do provisionamento, uma nova intent estará disponível para que os DPCs iniciem as telas de compliance e apliquem as configurações iniciais da política. Em dispositivos com perfil de trabalho, as telas de conformidade são exibidas no perfil. O DPC precisa garantir que as telas de conformidade sejam exibidas aos usuários, mesmo que um usuário saia do 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 impedir que apps arbitrários iniciem a atividade. Por 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>

O DPC precisa usar essa nova intent em vez de detectar a transmissão ACTION_PROFILE_PROVISIONING_COMPLETE.

A atividade associada ao filtro de intent pode chamar getIntent() para recuperar o EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE. Depois de obedecer à 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 que os usuários adicionem uma conta pessoal antes de retornar à 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 IDs 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, 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), e precisa oferecer suporte ao atestado do ID do dispositivo e ao registro sem toque.

O componente administrador de um perfil de trabalho pode chamar DevicePolicyManager.generateKeyPair(), transmitindo um ou mais elementos 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 suporte à visibilidade de agendas entre perfis e ao bloqueio de instalações de apps de fontes desconhecidas em todo o dispositivo.

Fontes desconhecidas pelo dispositivo em perfis de trabalho

Apps transferidos por download 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 administradores de perfis de trabalho podem impedir que qualquer usuário ou perfil instale apps de fontes desconhecidas em qualquer lugar do dispositivo adicionando a restrição de novo usuário DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY. Após adicionar essa restrição, no entanto, o usuário do dispositivo ainda poderá instalar apps usando o adb.

Para evitar que os usuários instalem apps de fontes desconhecidas por engano, recomendamos adicionar essa restrição de usuário, já que ela não exige a instalação do Google Play Services. Se você quiser oferecer suporte a 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 de perfis de trabalho chamam DevicePolicyManager.setPermittedInputMethods(), os usuários ficam restritos apenas 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 sobre os métodos de entrada na parte pessoal do dispositivo.

Excluir permanentemente perfis de trabalho de forma silenciosa

Adicionamos a sinalização WIPE_SILENTLY a DevicePolicyManager.wipeData(). Se a sinalização for definida, 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 apresenta 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 DNS por 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 de um dispositivo chama installSystemUpdate() com o caminho para o arquivo de atualização do sistema de um fabricante do dispositivo. Transmita um objeto InstallSystemUpdateCallback que o sistema pode usar para relatar erros que ocorrem antes da reinicialização do dispositivo. Se algo der errado, o sistema chamará onInstallUpdateError() com o código do erro.

Depois que o dispositivo for reiniciado, o 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 código QR 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, adicione os seguintes extras de provisionamento à sua 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 administrador 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 bem-sucedida. Caso contrário, ele retornará um erro.

Para recuperar o modo de DNS particular e o host definido em um dispositivo, chame getGlobalPrivateDnsMode() e getGlobalPrivateDnsHost(). Você pode impedir que os usuários alterem 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 da 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. Os apps isentos usam uma VPN por padrão, mas se conectam automaticamente a outras redes se ela não está disponível. Os apps isentos que também forem explicitamente negados à VPN só vão usar outras redes.

Para isentar um app do modo de bloqueio total, chame o novo método DevicePolicyManager setAlwaysOnVpnPackage() que aceita uma lista de pacotes de apps isentos. Todos os pacotes de apps adicionados pelo DPC precisam ser instalados no dispositivo quando o método é chamado. Se um app for desinstalado e reinstalado, ele precisará ser isento novamente. Para conseguir os apps isentos anteriormente do modo de bloqueio total, chame getAlwaysOnVpnLockdownWhitelist().

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

Novos escopos de delegação

O Android 10 estende 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 destes 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 aos quais os registros 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 de um único app delegado que processa o registro de rede e 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 de rede depois que o sistema disponibiliza 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 planeja delegar a 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 subclasse, implemente o callback onChoosePrivateKeyAlias() e retorne um alias para um certificado preferido ou, para solicitar 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 DPCs apliquem políticas legadas de administrador de dispositivo. Recomendamos que os clientes e parceiros façam a transição para dispositivos totalmente gerenciados ou perfis de trabalho. As políticas abaixo geram uma SecurityException quando invocadas por um administrador de dispositivo destinado ao Android 10:

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. Para ativar esse recurso, as seguintes políticas continuam disponíveis:

Para ver mais informações sobre essas mudanças, leia Descontinuação do administrador 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 se beneficiam das 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 de bloqueio de tela de um dispositivo ou perfil de trabalho. Os 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, permitindo 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 EXTRA_PASSWORD_COMPLEXITY extra. As opções que não atendem à complexidade especificada no extra da 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:mostre uma mensagem no app antes de abrir a página de bloqueio de tela do sistema. Quando o app for retomado, chame DevicePolicyManager.getPasswordComplexity() novamente. Se um bloqueio de tela mais forte ainda 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 definir um proxy HTTP para a conexão VPN deles. Para adicionar um proxy HTTP, um app de VPN precisa configurar uma instância do 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 HTTP de proxy.

Para ver o código de exemplo que mostra como definir um proxy HTTP, consulte o app de exemplo ToyVPN (link em inglês).

Modos de serviço de VPN

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

Os apps de VPN podem chamar os seguintes métodos VpnService após a conexão com o 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 ativado 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 apresenta várias melhorias relacionadas à API KeyChain.

Quando um app chama KeyChain.choosePrivateKeyAlias(), os dispositivos Android 10 e mais recentes filtram a lista de certificados que um usuário pode escolher com base nos emissores e algoritmos principais 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 de seleção de certificado inclui apenas opções correspondentes ao parâmetro do emissor. Se nenhuma opção correspondente estiver disponível ou se não houver certificados instalados no dispositivo, a solicitação de seleção não será exibida para o usuário.

Além disso, o KeyChain não exige mais que o dispositivo tenha um bloqueio de tela para que chaves ou certificados de CA possam ser importados.