Novidades para empresas no Android 10

Esta página fornece uma visão geral das novas APIs, recursos e mudanças de comportamento introduzidas no Android 10.

Perfis de trabalho para dispositivos corporativos

O Android 10 introduz 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 registrados usando QR code ou o recurso Sem toque. Durante o provisionamento de um dispositivo corporativo, um novo intent extra permite aplicativos controladores de política de dispositivo (DPCs) para iniciar um perfil de trabalho ou apps totalmente gerenciados configuração da infraestrutura. 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 o BIND_DEVICE_ADMIN permissão 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 desta atividade é especificar um modo de gerenciamento (perfil de trabalho ou totalmente gerenciado).

Pode ser útil recuperar os extras de provisionamento antes de determinar os 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

Complete o perfil de trabalho ou o provisionamento totalmente gerenciado enviando o provisionamento detalhes de volta para a configuração via 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 os DPCs lançarem as telas de compliance e aplicar as configurações iniciais de política. No perfil de trabalho dispositivos, as telas de conformidade são exibidas no perfil de trabalho. Seu DPC precisa garantir que as telas de conformidade sejam mostradas aos usuários, mesmo se um usuário escapar 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 o BIND_DEVICE_ADMIN permissão 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 essa nova intent em vez de detectar ACTION_PROFILE_PROVISIONING_COMPLETE transmissão.

A atividade associada ao filtro de intent pode chamar getIntent() para recuperar as EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE Depois de cumprir 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. Dispositivos com perfil de trabalho solicitar que os usuários adicionem a conta pessoal antes de retorná-los à casa tela.

Atestado de código de dispositivo do perfil de trabalho

DPCs definidos como administradores de um perfil de trabalho provisionado com o registro sem toque pode receber IDs de dispositivos com atestado de hardware seguro, como IMEI ou número de série. O dispositivo deve incluir um hardware seguro (como um ambiente de execução (TEE) ou Elemento de segurança (SE)) e aceita código do dispositivo e no registro sem toque.

O componente de administração de um perfil de trabalho pode chamar DevicePolicyManager.generateKeyPair(), transmitindo um ou mais parâmetros 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 bloqueio de instalações de apps de fontes desconhecidas em todo o dispositivo.

Fontes desconhecidas pelo dispositivo em perfis de trabalho

Apps transferidos de fontes que não sejam o Google Play (ou outro app confiável) lojas) são chamados de apps de fontes desconhecidas. No Android 10, os administradores de trabalho os perfis podem impedir que usuários ou perfis instalem apps desconhecidos fontes 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, 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, nós recomendamos adicionar essa restrição de usuário, porque ela não exige o Google Play sejam instalados. Para oferecer suporte a versões mais antigas do Android, faça o seguinte: definir 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 ficam restritos apenas aos métodos de entrada permitidos no trabalho em vez de todo o dispositivo, oferecendo aos usuários controle total sobre as entradas no lado pessoal do dispositivo.

Excluir permanentemente perfis de trabalho de forma silenciosa

WIPE_SILENTLY adicionado para DevicePolicyManager.wipeData(). Se a sinalização for definida, os usuários não serão notificados 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, extensão do código QR e provisionamento de NFC para incluem as credenciais de uma rede Wi-Fi EAP e suporte para DNS sobre TLS.

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

No Android 10, os administradores de dispositivos totalmente gerenciados podem instalar atualizações do sistema pelo 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. atrasar a instalação automática (se necessário). Em seguida, o DPC de um dispositivo chama installSystemUpdate(). pelo caminho para o arquivo de atualização do sistema de um fabricante de dispositivo. Transmita um InstallSystemUpdateCallback. objeto que o sistema pode usar para relatar erros que ocorrem antes de o dispositivo reinicializações. Se algo der errado, o sistema vai chamar onInstallUpdateError(). com o código de 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 para o provisionamento de dispositivos podem conter Configuração e credenciais do EAP, incluindo certificados. Quando uma pessoa lê um QR code ou tocar em uma tag NFC, o dispositivo será autenticado automaticamente na rede Wi-Fi usando o EAP e inicia o processo de provisionamento entrada manual.

Para autenticar o Wi-Fi usando o EAP, adicione um EXTRA_PROVISIONING_WIFI_SECURITY_TYPE extra com o valor "EAP". Para especificar a autenticação EAP, adicione o método seguintes extras de provisionamento para a intent:

Compatibilidade com DNS privado

As organizações podem usar o DNS sobre TLS (chamado DNS particular em dispositivos Android) para evitar o vazamento de consultas DNS, incluindo os de nomes do host internos. Componentes de administrador de dispositivos totalmente gerenciados pode controlar as configurações de DNS particular do dispositivo. Para definir o modo de DNS particular, ligue para:

Quando o DPC chamar um desses métodos, o sistema retornará PRIVATE_DNS_SET_NO_ERROR se: a chamada foi bem-sucedida. Caso contrário, ele retornará um erro.

Para recuperar o modo 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 o DISALLOW_CONFIG_PRIVATE_DNS restrição de usuários.

Isenção do modo de bloqueio total de VPN

O modo de bloqueio total da VPN permite que um DPC bloqueie qualquer rede tráfego que não usa à VPN. Administradores de contas dispositivos 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 outros redes locais se a VPN não estiver disponível. Apps isentos que também sejam explicitamente negaram acesso ao VPN só vai usar outras redes.

Para isentar um app do modo de bloqueio total, chame o novo método Método DevicePolicyManager setAlwaysOnVpnPackage() que aceita uma lista de pacotes de apps isentos. Todos os pacotes de aplicativos adicionados pelo DPC deve ser instalado no dispositivo quando o método é chamado. Se um app é desinstalado e reinstalado, o app precisa ser isento novamente. Para instalar os apps que estavam isentos do modo de bloqueio total, chame getAlwaysOnVpnLockdownWhitelist()

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

Novos escopos de delegação

O Android 10 estende a lista de funções que um DPC pode delegar a outros apps 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 apresenta a nova classe DelegatedAdminReceiver para apps delegados. O sistema usa esse broadcast receiver para enviar para delegar apps. Apps a que foi delegada atividade de rede a geração de registros e a seleção de certificados devem implementar essa classe. Para adicionar a um app delegado, siga estas etapas:

  1. Adicionar uma subclasse de DelegatedAdminReceiver para o 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. Proteger o broadcast receiver com o BIND_DEVICE_ADMIN permissão.

O snippet a seguir mostra o manifesto de um único app delegado que lida com a geração de registros de rede e a seleção de certificados:

<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, administradores de contas de rede podem delegar o registro de rede a um app especializado.

Para recuperar registros de rede após a execução disponibiliza um lote, os apps delegados devem primeiro ser subclassificados DelegatedAdminReceiver (descrito anteriormente). Na subclasse, implemente a onNetworkLogsAvailable() seguindo as orientações em Recuperar registros.

Os apps delegados podem chamar o seguinte: 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. caso pretenda delegar para outro app. O app delegado precisa ativar e e coletar registros de rede. Depois que um DPC delega a geração de registros de rede, ele não recebe mais onNetworkLogsAvailable() .

Para saber como informar o registro de atividades de rede de um app delegado, leia a Registro de atividades de rede no guia para desenvolvedores.

Seleção de certificado

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

Para selecionar um alias de certificado, primeiro os apps delegados precisam ter uma subclasse DelegatedAdminReceiver (descrito anteriormente). Na subclasse, implemente a onChoosePrivateKeyAlias() e retornar um alias para um método ou, para solicitar que o usuário selecione um certificado, retorna null.

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

O Android 10 impede que apps e DPCs apliquem dispositivos legados admin. Recomendamos clientes e os parceiros fazem a transição para dispositivos totalmente gerenciados ou perfis de trabalho. O seguinte políticas geram uma SecurityException quando invocado por um administrador de dispositivo destinado ao Android 10:

.

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

Saiba mais sobre essas mudanças em Administrador do dispositivo descontinuação.

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 lançar recursos críticos. Chamadas de apps o benefício da API KeyChain de 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 pode consultar a complexidade do bloqueio de tela de um dispositivo ou perfil de trabalho. Apps que precisam de uma um bloqueio de tela mais forte pode direcionar o usuário para as configurações de bloqueio de tela do sistema, permitindo que atualizem 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 extras, opções que não atendem à complexidade especificada no extra da intent ficam esmaecidas. Os usuários podem escolha uma das opções de bloqueio de tela disponíveis ou saia da tela.

Prática recomendada:mostre uma mensagem no app antes de iniciar o sistema. página de bloqueio de tela. Quando o app for retomado, chame DevicePolicyManager.getPasswordComplexity() de novo. Se um bloqueio de tela mais forte ainda for necessário, restrinja o acesso em vez de solicitar repetidamente que os usuários atualizem suas 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. pela conexão VPN. Para adicionar um proxy HTTP, um app de VPN precisa configurar uma Instância do ProxyInfo com um host e uma porta, antes de ligar 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 fazer proxy de solicitações HTTP.

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

Modos de serviço de VPN

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

Os apps de VPN podem chamar estes VpnService: métodos 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 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 chamar KeyChain.choosePrivateKeyAlias(), o Android 10 e versões mais recentes dispositivos filtram a lista de certificados que um usuário pode escolher com base no emissores e principais algoritmos especificados na chamada.

Por exemplo, quando um servidor TLS envia uma solicitação de certificado como parte de um handshake de TLS, e o navegador chama KeyChain.choosePrivateKeyAlias(), apenas o prompt de seleção de certificado inclui opções que correspondem ao parâmetro emissores. Se nenhuma opção de correspondência for ou se não houver certificados instalados no dispositivo, o prompt de seleção não será exibido ao usuário.

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