Esta página foi traduzida pela API Cloud Translation.

Novidades do Android 8.0

Esta página fornece uma visão geral dos novos recursos, mudanças de comportamento e APIs introduzidas no Android 8.0 (nível 26 da API) que afetam o Android em empresas.

Novos recursos e APIs

Tornamos os modos de gerenciamento do proprietário do perfil e do proprietário do dispositivo mais eficientes, produtivos e fáceis de provisionar do que nunca. Também ativamos um novo cenário de implantação: perfis de trabalho em dispositivos totalmente gerenciados. Esses e outros recursos são descritos nas seções a seguir.

Perfis de trabalho em dispositivos totalmente gerenciados

No Android 8.0, dispositivos totalmente gerenciados também podem ter perfis de trabalho. Com isso, as empresas podem separar apps e políticas, mantendo o controle e a visibilidade nos dois perfis. O proprietário do dispositivo atual ou um controlador de política de dispositivo (DPC) diferente pode criar o perfil gerenciado.

Com perfis de trabalho em dispositivos totalmente gerenciados, os proprietários de dispositivos podem:

Crie um perfil gerenciado sem interação do usuário chamando EXTRA_PROVISIONING_SKIP_USER_CONSENT.
Receba notificações quando usuários secundários ou perfis gerenciados forem criados ou removidos. Os callbacks são onUserAdded() e onUserRemoved().
Impeça que outros DPCs criem perfis gerenciados usando DISALLOW_ADD_MANAGED_PROFILE. Essa configuração é o padrão no Android 8.0 para proprietários de dispositivos em dispositivos recém-provisionados ou que receberam upgrade para o Android 8.0.
Os proprietários de dispositivos também podem impedir que os usuários removam perfis gerenciados usando DISALLOW_REMOVE_MANAGED_PROFILE.

Os proprietários de dispositivo e de perfil podem se comunicar entre si se forem do mesmo APK e forem afiliados. Consulte Afiliação do usuário abaixo.

Para informações mais detalhadas sobre como oferecer suporte a esse novo cenário de implantação, consulte a página dedicada para perfis de trabalho em dispositivos totalmente gerenciados.

Afiliação do usuário

Quando um proprietário do dispositivo e um proprietário de perfil representam a mesma organização:

Os proprietários do dispositivo e do perfil podem se comunicar entre si no mesmo APK. Talvez eles queiram compartilhar políticas ou status. Consulte Perfis de trabalho em dispositivos totalmente gerenciados acima.
Os recursos para todo o dispositivo, como registro ou modo de tarefa de bloqueio na lista de permissões, podem ser aplicados a usuários afiliados.

Os IDs de afiliação, vinculados a um perfil ou usuário, identificam organizações. Quando os códigos de afiliação são correspondentes, os usuários se tornam afiliados. Os proprietários de dispositivos e de perfis usam setAffiliationIds() para definir os IDs de afiliação. Representar organizações usando IDs de string longos e difíceis de adivinhar.

Novo acesso para usuários afiliados

Se todos os usuários e perfis secundários em um dispositivo forem afiliados ao proprietário do dispositivo, os seguintes recursos vão estar disponíveis:

Geração de registros de segurança usando setSecurityLoggingEnabled().
Registro de atividades de rede usando setNetworkLoggingEnabled().
Relatórios de bugs usando requestBugreport().

Antes, a geração de registros de segurança e os relatórios de bugs só estavam disponíveis para dispositivos de usuário único ou para dispositivos com apenas um perfil e um usuário.

O modo de tarefa de bloqueio está disponível para usuários secundários e perfis gerenciados quando afiliados ao proprietário do dispositivo pelo setLockTaskPackages(). Para informações mais detalhadas sobre a afiliação de usuários, consulte Usuários afiliados.

Exonerações de responsabilidade de provisionamento personalizado

Agora, os DPCs podem mostrar as próprias exonerações de responsabilidade aos usuários durante o provisionamento. Use EXTRA_PROVISIONING_DISCLAIMERS, EXTRA_PROVISIONING_DISCLAIMER_HEADER e EXTRA_PROVISIONING_DISCLAIMER_CONTENT para fornecer exonerações de responsabilidade em texto estilizado. As exonerações de responsabilidade personalizadas de um DPC aparecem na lista de termos recolhíveis.

Segurança

Os proprietários de perfis e de dispositivos podem usar o setRequiredStrongAuthTimeout() para configurar um tempo limite para desbloquear um dispositivo ou um perfil com um método de autenticação secundário, como impressões digitais ou agentes de confiança. Depois que o tempo limite expira, o usuário precisa desbloquear o dispositivo ou perfil usando um método de autenticação forte, como senha, PIN ou padrão.

Os proprietários de dispositivos e perfis podem redefinir as senhas do dispositivo e do perfil de trabalho com segurança usando o resetPasswordWithToken(). Para dispositivos com suporte à criptografia baseada em arquivos, essa API está disponível antes de um usuário desbloquear o dispositivo ou perfil, desde que o DPC reconheça criptografia.

Ao bloquear um perfil de trabalho em um dispositivo com suporte à criptografia baseada em arquivos, o lockNow(int) pode remover as chaves de criptografia primárias do perfil de trabalho usando FLAG_EVICT_CREDENTIAL_ENCRYPTION_KEY. As chaves de criptografia também serão removidas se o usuário desativar o perfil de trabalho.

Além disso, os proprietários de dispositivos podem usar setNetworkLoggingEnabled() para ativar a geração de registros de rede de consultas DNS e conexões TCP iniciadas em dispositivos da empresa. Para mais informações, consulte Geração de registros de atividades de rede.

Os proprietários de perfis podem restringir quais pacotes do usuário principal podem observar notificações do perfil de trabalho. Chame setPermittedCrossProfileNotificationListeners() para definir os pacotes da lista de permissões que recebem eventos usando um NotificationListenerService. Definir os listeners permitidos como null (padrão) desativa a lista de permissões e todos os pacotes podem detectar notificações. Para limitar eventos a pacotes do sistema, transmita um Set vazio. Para conferir os apps que não podem acessar as notificações do perfil de trabalho, os usuários podem tocar em Configurações > Apps e notificações > Acesso especial para apps > Acesso a notificações.

Por fim, os proprietários de perfis e de dispositivos podem recuperar informações sobre as atualizações pendentes do sistema disponíveis em um dispositivo usando getPendingSystemUpdate().

Delegação da API App Management

Com a delegação de API, os proprietários de dispositivos e perfis podem transferir o gerenciamento de apps para outros apps. A classe DevicePolicyManager oferece métodos para gerenciar os escopos de delegação que os proprietários do dispositivo e do perfil podem conceder a um pacote:

O método setDelegatedScopes() permite que os proprietários de dispositivos e perfis concedam acesso a APIs privilegiadas para outros apps.
O método getDelegatedScopes() retorna os escopos concedidos a um pacote.
O getDelegatePackages() retorna os pacotes que têm um escopo.

A tabela abaixo mostra como vários métodos no DevicePolicyManager são organizados em diferentes escopos:

Tabela 1. Correspondência entre escopos e métodos de política de dispositivo

Grupo	Métodos
`DELEGATION_CERT_INSTALL`	`installKeyPair()` `removeKeyPair()` `installCaCert()` `uninstallCaCert()`
`DELEGATION_APP_RESTRICTIONS`	`getApplicationRestrictionsManagingPackage()` `setApplicationRestrictionsManagingPackage()`
`DELEGATION_BLOCK_UNINSTALL`	`setUninstallBlocked()`
`DELEGATION_PERMISSION_GRANT`	`getPermissionPolicy()` `setPermissionPolicy()` `getPermissionGrantState()`
`DELEGATION_PACKAGE_ACCESS`	`isApplicationHidden()` `setApplicationHidden()` `isPackageSuspended()` `setPackagesSuspended()`
`DELEGATION_ENABLE_SYSTEM_APP`	`enableSystemApp()`

Serviços em segundo plano de longa duração

Os proprietários de dispositivos e perfis podem criar uma subclasse DeviceAdminService para criar serviços em segundo plano. O sistema Android tenta manter o serviço em execução enquanto o usuário está em execução. Se você quiser executar tarefas periódicas, use o JobScheduler antes de criar um serviço em segundo plano.

Como controlar o serviço de backup

Os proprietários de dispositivos podem ativar ou desativar o Android Backup Service usando novos métodos no DevicePolicyManager. Ative e desative o serviço de backup usando setBackupServiceEnabled(). Verifique o status do serviço de backup usando isBackupServiceEnabled().

Configuração de proxy do Wi-Fi

Os proprietários de dispositivos e de perfis podem configurar servidores proxy HTTP para redes Wi-Fi. Use um arquivo PAC ou configurações manuais para configurar um servidor proxy para cada rede Wi-Fi. Para definir ou remover o proxy de uma WifiConfiguration, chame o método setHttpProxy(). Para ver as configurações de proxy, chame getHttpProxy().

Caixas de diálogo com explicações sobre recursos desativados pelo administrador

Seu app precisa mostrar uma explicação útil para os usuários que tentam usar um recurso desativado pelo administrador. Todos os apps agora podem usar createAdminSupportIntent() para criar uma intent que mostra uma caixa de diálogo de explicação quando transmitida para startActivity(Intent). As intents incluem explicações personalizadas e localizadas para câmeras e capturas de tela desativadas e todas as restrições UserManager.

Restringindo Bluetooth

Os proprietários de dispositivos podem desativar o Bluetooth, o que afeta todos os usuários e perfis no dispositivo. Para desativar o Bluetooth, adicione a restrição de usuário DISALLOW_BLUETOOTH.

Os proprietários de dispositivos e de perfis podem impedir que os usuários enviem arquivos por Bluetooth usando o DISALLOW_BLUETOOTH_SHARING. O recebimento de arquivos não é afetado. Quando definido pelo proprietário do dispositivo, DISALLOW_BLUETOOTH_SHARING se aplica a todos os usuários no dispositivo. Essa configuração é o padrão no Android 8.0 para novos perfis e perfis já existentes em dispositivos que fizeram upgrade para o Android 8.0.

Mudanças de comportamento

Se você está criando apps para empresas, incluindo DPCs, analise as mudanças de comportamento a seguir no Android 8.0 e modifique seu app de acordo com elas.

Como remover usuários

Os proprietários de dispositivos podem remover usuários secundários e perfis gerenciados usando removeUser(), mesmo que DISALLOW_REMOVE_USER esteja ativado.

Segurança

Autenticação

As mudanças abaixo entraram em vigor na classe DevicePolicyManager:

O método lockNow() só bloqueia o perfil de trabalho se um desafio de trabalho separado estiver ativo.
O método resetPassword() não está mais disponível para DPCs que atuam como proprietários de dispositivos ou de perfis e são direcionados ao Android 8.0. Se chamado, uma exceção de segurança será gerada. Em vez disso, os DPCs precisam usar resetPasswordWithToken().
Observação : os DPCs destinados ao Android 7.1.1 (nível 25 da API) ou versões anteriores, assim como os DPCs com apenas privilégios de administrador do dispositivo, não são afetados por essa mudança.
Em dispositivos com suporte à criptografia baseada em arquivos, a isActivePasswordSufficient() não fica disponível antes de o usuário desbloquear o dispositivo pela primeira vez após uma reinicialização. Se chamado antes do usuário desbloquear o dispositivo, uma exceção será gerada.

Dados de perfis de trabalho bloqueados

O Android 8.0 inclui mudanças na interface do usuário para separar dados de um perfil de trabalho bloqueado.

As notificações de apps no perfil de trabalho agora podem ocultar o conteúdo deles. Antes, a gaveta de notificações mostrava o conteúdo de apps de trabalho de um perfil de trabalho bloqueado.
A tela Recentes agora mostra um painel simples para executar apps em um perfil de trabalho bloqueado. O painel simples e colorido contém o ícone e o nome de um app. Antes, as atividades ou tarefas de um perfil de trabalho bloqueado mostravam uma visualização na tela Recentes.

Integridade do dispositivo

A sinalização ENSURE_VERIFY_APPS agora é uma restrição global de usuário. Se algum usuário no dispositivo tiver essa restrição, a verificação de app será aplicada a todos os usuários no dispositivo. Por exemplo, se um proprietário de perfil definir a restrição no perfil de trabalho, a verificação de apps será aplicada no perfil pessoal do usuário.
O método onSystemUpdatePending() agora é invocado para proprietários de perfil e de dispositivos.
Ao usar a classe SystemUpdatePolicy, a política de adiamento não se aplica mais aos patches de segurança. Portanto, os patches de segurança não podem mais ser adiados. No entanto, o comportamento de outros tipos de política, como automática e com janelas, não é afetado.
Os proprietários de dispositivos podem acionar uma redefinição para a configuração original usando wipeData(), mesmo que DISALLOW_FACTORY_RESET esteja ativado.

VPN sempre ativa

O Android 8.0 inclui mudanças na interface do usuário para ajudar os usuários a entender o status das conexões VPN sempre ativadas:

Quando as conexões VPN sempre ativadas são desconectadas ou não conseguem se conectar, os usuários veem uma notificação não dispensável. Tocar na notificação mostra as configurações da VPN. A notificação desaparece quando a VPN é reconectada ou o usuário desativa a opção de VPN sempre ativa.
A VPN sempre ativada permite que o usuário do dispositivo bloqueie qualquer conexão de rede que não use a VPN. Ao ativar essa opção, o app Configurações avisa ao usuário que ele não terá uma conexão de Internet até que a VPN se conecte. As configurações solicitam que o usuário continue ou cancele.

O VpnService dos apps de VPN agora precisa chamar o método startForeground() após o lançamento. Como o sistema Android inicia o serviço de um app de VPN diretamente, a transição para o primeiro plano é responsabilidade do app. O Android 8.0 encerra os apps de VPN que não fazem a transição do serviço de VPN para o primeiro plano.

Callbacks de senha

Os callbacks de mudança de senha de DeviceAdminReceiver agora incluem um parâmetro user para identificar o usuário ou o perfil a que a senha pertence. As novas assinaturas de método são:

A implementação padrão de cada novo método chama a versão anterior, descartando o argumento do usuário. O Android 8.0 descontinua os métodos anteriores.

Delegação da API App Management

Os seguintes métodos na classe DevicePolicyManager foram descontinuados:

Além disso, agora é possível delegar um único escopo a vários pacotes. Em outras palavras, os proprietários de dispositivos e de perfis podem conceder acesso de dois pacotes diferentes ao mesmo conjunto de APIs simultaneamente.