Android 7.0 para desenvolvedores

O Android 7.0 Nougat introduz diversos novos recursos e possibilidades para usuários e desenvolvedores. Este documento destaca as novidades para os desenvolvedores.

Não deixe de conferir Mudanças de comportamento do Android 7.0 para conhecer as áreas em que as mudanças da plataforma podem afetar seus aplicativos.

Para saber mais dos recursos ao usuário do Android 7.0, acesse www.android.com.

Compatibilidade com várias janelas

No Android 7.0, introduzimos um recurso de multitarefa novo e muito solicitado na plataforma — a compatibilidade com várias janelas.

Agora os usuários podem abrir dois aplicativos na tela ao mesmo tempo.

• Em celulares e tablets com Android 7.0, os usuários agora podem executar dois aplicativos lado a lado ou um acima do outro em modo de tela dividida. Para redimensionar os aplicativos, os usuários podem arrastar o divisor entre eles.
• Em dispositivos Android TV, os aplicativos podem assumir o modo “imagem superposta”, o que permite continuar exibindo conteúdo enquanto o usuário navega ou interage com outros aplicativos.

A compatibilidade com várias janelas oferece novas formas de envolver os usuários, especialmente em tablets e outros dispositivos com telas maiores. Você pode até ativar o recurso de arrastar e soltar no aplicativo para permitir que os usuários arrastem conteúdo de ou para o aplicativo — uma ótima maneira de aprimorar a experiência do usuário.

É muito fácil adicionar compatibilidade com várias janelas a seu aplicativo e configurar como ele lidará com a exibição de várias janelas. Por exemplo: você pode especificar as dimensões mínimas permitidas para sua atividade, evitando que os usuários redimensionem a atividade para menos desse tamanho. Você também pode desativar a exibição de várias janelas para o aplicativo, o que garante que o sistema só mostrará o aplicativo em modo de tela cheia.

Para obter mais informações, consulte a documentação Compatibilidade com várias janelas para desenvolvedores.

Melhorias às notificações

Reformulamos as notificações no Android 7.0 para facilitar e agilizar o uso. Entre as alterações, temos:

• Atualização de modelos: Estamos atualizando os modelos de notificação para dar mais ênfase à imagem principal e do avatar. Os desenvolvedores poderão fazer uso dos novos modelos com ajustes mínimos no código.
• Personalização do estilo da mensagem: Para personalizar mais rótulos de interface do usuário associados às suas notificações, use a classe MessagingStyle. É possível configurar a mensagem, o título da conversa e a visualização do conteúdo.
• Notificações empacotadas: O sistema pode agrupar mensagens por assunto da mensagem, por exemplo, e exibir o grupo. Um usuário pode executar ações, como Dismiss ou Archive, nesse grupo. Se você já implementou notificações para o Android Wear, conhece com esse modelo.
• Resposta direta: Para aplicativos de comunicação em tempo real, o sistema Android aceita respostas em linha para que os usuários possam responder rapidamente a mensagens SMS ou de texto diretamente dentro da interface da notificação.
• Visualizações personalizadas: Duas novas APIs permitem usar decorações do sistema, como títulos e ações de notificação, durante o uso de visualizações personalizadas em notificações.

Figura 2. Notificações empacotadas e resposta direta.

Para saber como implementar os novos recursos, consulte o guia Notificações.

Compilação JIT/AOT orientada a perfil

No Android 7.0, adicionamos um compilador Just in Time (JIT) com perfis de código para ART, o que permite aprimorar constantemente o desempenho de aplicativos Android durante a execução. O compilador JIT complementa o compilador atual Ahead of Time (AOT) do ART e ajuda a aprimorar o desempenho em tempo de execução, economizar espaço de armazenamento e acelerar atualizações de aplicativos e do sistema.

A compilação orientada a perfil permite que o ART gerencie a compilação AOT/JIT de cada aplicativo de acordo com o uso real e com as condições no dispositivo. Por exemplo, o ART mantém um perfil dos principais métodos do aplicativo e pode pré-compilar e armazenar esses métodos em cache para obter o melhor desempenho. As outras partes do aplicativo não são compiladas até que sejam realmente utilizadas.

Além de aprimorar o desempenho para as principais partes do aplicativo, a compilação ajuda a reduzir o uso geral de recursos de RAM, inclusive os binários associados. Esse recurso é especialmente importante em dispositivos com pouca memória.

O ART gerencia a compilação orientada a perfil de forma a minimizar o impacto sobre a bateria do dispositivo. A execução da pré-compilação só acontece quando o dispositivo está ocioso e com a bateria sendo carregada, economizando tempo e carga com a execução antecipada dessa tarefa.

Caminho rápido para a instalação de aplicativos

Um dos benefícios mais perceptíveis do compilador JIT do ART é a velocidade de instalação dos aplicativos e das atualizações do sistema. Agora é possível instalar em segundos até aplicativos grandes, que exigiam muitos minutos para otimização e instalação no Android 6.0. As atualizações do sistema também ficaram mais rápidas, já que não existe mais a etapa de otimização.

Modo soneca em movimento...

O Android 6.0 introduziu o modo soneca: um modo do sistema que, para economizar bateria, adia atividades de CPU e rede dos aplicativos quando o dispositivo está ocioso, como quando está sobre a mesa ou em uma gaveta.

Agora, no Android 7.0, a Soneca deu um passo a frente para economizar bateria em todo lugar. Sempre que a tela ficar desligada por determinado tempo e o dispositivo estiver desconectado, a Soneca aplica um subconjunto de restrições de rede e de CPU conhecidas a aplicativos. Isso significa que os usuários podem economizar carga da bateria até quando carregam o dispositivo no bolso.

Figura 3. O modo soneca agora aplica restrições para aumentar a vida útil da bateria mesmo quando o dispositivo não está parado.

Pouco depois da desativação da tela com o dispositivo alimentado pela bateria, o modo soneca restringe o acesso à rede e adia trabalhos e sincronizações. Durante breves janelas de manutenção, os aplicativos podem acessar a rede, quando ocorre a execução de todos os trabalhos/sincronizações adiados. A ativação da tela ou do dispositivo encerra o modo soneca.

Quando o dispositivo voltar a ficar parado, com a tela desativada e alimentado por bateria por um período, o modo soneca aplicará as restrições de CPU e rede integralmente em PowerManager.WakeLock, alarmes do AlarmManager e verificações de GPS/Wi-Fi.

As práticas recomendadas para adaptar o aplicativo ao modo soneca são as mesmas para dispositivos parados ou em movimento. Portanto, se você já atualizou o aplicativo para processar o modo soneca corretamente, está tudo pronto. Se não, comece a adaptar o aplicativo para o modo soneca agora.

Project Svelte: Otimizações em segundo plano

O Project Svelte é uma iniciativa contínua para minimizar o uso de RAM pelo sistema e pelos aplicativos nos dispositivos Android existentes no ecossistema. No Android 7.0, o Project Svelte se concentra em otimizar a forma de execução dos aplicativos em segundo plano.

O processamento em segundo plano é parte essencial da maioria dos aplicativos. Quando tratado de forma correta, ele pode tornar a experiência do usuário incrível — imediata, rápida e contextual. Quando tratado de forma inadequada, o processamento em segundo plano pode consumir RAM (e bateria) desnecessária e afetar o desempenho do sistema para os outros aplicativos.

Desde o Android 5.0, JobScheduler é a forma preferida de executar trabalho em segundo plano de maneira benéfica para os usuários. Os aplicativos podem agendar trabalhos e permitir ao sistema executar otimizações com base em condições de memória, energia e conectividade. O JobScheduler oferece controle e simplicidade, e queremos que todos os aplicativos o usem.

Outra boa opção é o GCMNetworkManager, parte do Google Play Services, que oferece um agendamento de trabalhos semelhante, compatível com versões anteriores do Android.

Continuamos expandindo o JobScheduler e o GCMNetworkManager para atender a mais casos de uso — por exemplo, no Android 7.0, você já pode agendar trabalhos em segundo plano de acordo com mudanças nos provedores de conteúdo. Ao mesmo tempo, começamos a substituir alguns padrões mais antigos que podem reduzir o desempenho do sistema, especialmente em dispositivos com pouca memória.

No Android 7.0, estamos removendo três transmissões implícitas de uso comum —CONNECTIVITY_ACTION, ACTION_NEW_PICTURE e ACTION_NEW_VIDEO — eles podem despertar simultaneamente os processos em segundo plano de diversos aplicativos, aumentando o consumo de memória e bateria. Se o seu aplicativo receber essas transmissões, aproveite o Android 7.0 para migrar para o JobScheduler e as APIs relacionadas.

Consulte a documentação de Otimizações em segundo plano para obter mais detalhes.

SurfaceView

O Android 7.0 oferece movimento síncrono à classe SurfaceView, que fornece melhor desempenho de bateria do que TextureView em alguns casos: Ao renderizar vídeo ou conteúdo 3D, os aplicativos com posição de vídeo animado e rolagem usam menos energia com SurfaceView do que com TextureView.

A classe SurfaceView ativa mais composições de baixo consumo de bateria na tela porque consiste em hardware dedicado, separado do conteúdo da janela do aplicativo. Como resultado, ele faz menos cópias intermediárias do que TextureView.

A posição do conteúdo de um objeto SurfaceView agora é atualizada de forma síncrona com o conteúdo do aplicativo em questão. Um resultado dessa mudança é que conversões ou dimensionamentos simples de um vídeo reproduzido em um SurfaceView não gera mais barras pretas ao lado da visualização à medida que ela se move.

A partir do Android 7.0, recomendamos economizar energia usando SurfaceView em vez de TextureView.

Economia de dados

Normalmente, o custo de um plano de dados de celular ao longo da vida útil do dispositivo móvel excede o custo do próprio dispositivo. Para muitos usuários, os dados móveis são um recurso caro que vale a pena economizar.

O Android 7.0 introduz o modo de Economia de Dados, um novo serviço do sistema que ajuda a reduzir o uso de dados móveis pelos aplicativos em roaming, perto do fim do ciclo de cobrança ou em pacotes de dados pré-pagos pequenos. A Economia de Dados permite aos usuários controlar o uso de dados móveis e aos desenvolvedores oferecer serviços mais eficientes.

Quando um usuário ativa a Economia de Dados em Settings e o dispositivo está em uma rede tarifada, o sistema bloqueia o uso de dados em segundo plano e instrui os aplicativos a reduzir o uso de dados no primeiro plano sempre que possível — como, por exemplo, limitar a taxa de bits de streaming, reduzir a qualidade de imagens, adiar o armazenamento prévio otimista em cache e assim por diante. Os usuários podem colocar aplicativos específicos na lista de permissões para que eles possam usar dados tarifados em segundo plano, mesmo com a Economia de dados ativada.

O Android 7.0 estende o ConnectivityManager para oferecer aos aplicativos uma forma de recuperar as preferências do usuário para a Economia de Dados e monitorar as mudanças de preferências. Todos os aplicativos devem verificar se o usuário ativou a Economia de Dados e tentar limitar o uso de dados em primeiro e segundo planos.

Vulkan API

O Android 7.0 integra à plataforma o Vulkan™, uma nova API de renderização 3D. Como o OpenGL™ ES, o Vulkan é um padrão aberto de gráficos e renderização 3D oferecido pelo Khronos Group.

O Vulkan foi projetado desde o início para minimizar sobrecargas na CPU do driver e permitir que seu aplicativo controle a operação de GPU de forma mais direta. O Vulkan também oferece melhor paralelização ao permitir que vários encadeamento realizem trabalhos, como a construção de buffer de comando, de uma só vez.

As ferramentas de desenvolvimento e bibliotecas do Vulkan foram integradas ao Android 7.0DK. Elas contêm:

• Cabeçalhos
• Camadas de validação (bibliotecas de depuração)
• Compilador de sombreadores SPIR-V
• Biblioteca de compilação de sombreadores SPIR-V em tempo de execução

O Vulkan só está disponível para aplicativos em dispositivos com hardware com capacidade para Vulkan, como Nexus 5X, Nexus 6P e Nexus Player Estamos trabalhando em estreita cooperação com nossos parceiros para oferecer o Vulkan em mais dispositivos assim que possível.

Para obter mais informações, consulte a documentação da API.

Quick Settings Tile API

As Configurações Rápidas são uma forma popular e simples de expor as principais configurações e ações diretamente na aba de notificações. No Android 7.0, ampliamos o escopo das Configurações Rápidas para aumentar ainda mais a utilidade e a conveniência.

Adicionamos mais espaço para os blocos de Configurações Rápidas, que, para acessarem em uma área de exibição paginada, os usuários podem deslizar à direita ou à esquerda. Além disso, os usuários poderão controlar os blocos de Configurações Rápidas a exibir, bem como o local de exibição — para adicionar ou mover blocos, basta arrastar e soltar.

Para desenvolvedores, o Android 7.0 também adiciona uma API nova que permite definir os próprios blocos de Configurações rápidas para os usuários acessarem facilmente os principais controles e ações do seu aplicativo.

Os blocos de Configurações Rápidas estão reservados para controles ou ações urgentes ou frequentes, por isso não devem ser usados como atalhos para iniciar aplicativos.

Após definir os blocos, você pode disponibilizá-los aos usuários, que por sua vez podem adicioná-los às Configurações Rápidas usando o recurso de arrastar e soltar.

Para obter informações sobre a criação de um bloco de aplicativo, consulte a documentação para android.service.quicksettings.Tile na Referência da API, disponível para baixar.

Bloqueio de número

O Android 7.0 agora oferece suporte a bloqueio de números na plataforma e disponibiliza uma API de estrutura para que os provedores de serviço mantenham uma lista de números bloqueados. O aplicativo padrão de SMS, o aplicativo padrão de telefone e os aplicativos de provedor podem ler e gravar a lista de números bloqueados. Outros aplicativos não terão acesso à lista.

Ao oferecer o bloqueio de número como recurso padrão da plataforma, o Android oferece uma forma consistente de bloquear números para uma grande variedade de dispositivos. Alguns benefícios que podem ser aproveitados pelos aplicativos são:

• Números bloqueados para chamadas também são bloqueados para mensagens de texto
• Números bloqueados podem persistir entre várias redefinições e dispositivos por meio do recurso Backup e Restauração
• Vários aplicativos podem usar a mesma lista de números bloqueados

Além disso, a integração de aplicativos da operadora por meio do Android significa que as operadoras podem ler a lista de números bloqueados no dispositivo e executar um bloqueio no lado do servidor para o usuário, impedindo que chamadas e textos indesejados cheguem a ele por qualquer meio, como terminais de VoIP ou encaminhamento de telefones.

Para obter mais informações, consulte android.provider.BlockedNumberContract na Referência da API, disponível para baixar.

Triagem de chamadas

O Android 7.0 permite que o aplicativo de telefone padrão faça a triagem das chamadas recebidas. Para isso, o aplicativo de telefone implementa o novo CallScreeningService, que permite a execução de diversas ações com base nos Call.Details da chamada recebida, como:

• Rejeitar a chamada recebida
• Não incluir a chamada no registro de chamadas
• Não mostrar ao usuário a notificação da chamada

Para obter mais informações, consulte android.telecom.CallScreeningService na Referência da API, disponível para baixar.

Compatibilidade com diversas localidades, mais idiomas

O Android 7.0 agora permite aos usuários selecionar diversas localidades em Configurações para oferecer mais compatibilidade a casos de uso bilíngues. Os aplicativos podem usar uma API nova para obter as localidades selecionadas pelo usuário e oferecer experiências de usuário mais sofisticadas para usuários com diversas localidades — como, por exemplo, mostrar resultados de pesquisa em diversos idiomas e não oferecer a tradução de páginas da web que usam um idioma conhecido pelo usuário.

Com a compatibilidade com várias localidades, o Android 7.0 também amplia o número de idiomas disponíveis aos usuários. Ele oferece mais de 25 variantes para cada um dos idiomas mais comuns, como inglês, espanhol, francês e árabe. Além disso, oferece parcialmente mais de 100 novos idiomas.

Para obter a lista de localidades definida pelo usuário, os aplicativos chamam LocaleList.GetDefault(). Para oferecer um maior número de localidades, o Android 7.0 está alterando a forma de resolver recursos. Não deixe de testar e verificar se seus aplicativos funcionam da forma esperada com a nova lógica de resolução de recursos.

Para saber mais sobre o novo comportamento de resolução de recursos e sobre as práticas recomendadas a adotar, consulte Compatibilidade com vários idiomas.

Novos emoticons

O Android 7.0 apresenta emoticons adicionais e recursos relacionados, como emoticons com diferentes tons de pele e suporte a seletores de variação. Se o seu aplicativo é compatível com emoticons, siga as instruções abaixo para fazer uso desses recursos próprios para emoticons.

• Verifique se o dispositivo contém um emoticon antes de inseri-lo. Para conferir os emoticons presentes na fonte do sistema, use o método hasGlyph(String).
• Verifique se um emoticon aceita seletores de variação. Os seletores de variação permitem apresentar determinados emoticons em cores ou preto e branco. Em dispositivos móveis, os aplicativos devem representar os emoticons em cores, e não em preto e branco. Porém, se o seu aplicativo exibe emoticons alinhados ao texto, ele deve usar a variação preto e branco. Para determinar se um emoticon tem variação ou não, use o seletor de variação. Para obter uma lista completa de caracteres com variação, consulte a seção sequências de variação de emoticons, na Documentação sobre variações em Unicode.
• Verifique se um emoticon funciona com tons de pele. O Android 7.0 permite aos usuários modificar a gosto o tom de pele renderizado de emoticons. Os aplicativos de teclado devem oferecer indicações visuais para emoticons que tenham diversos tons de pele e permitir aos usuários selecionar o tom preferido. Para determinar quais emoticons do sistema têm modificadores de tom de pele, use o método hasGlyph(String). Leia a Documentação do Unicode para determinar quais emoticons usam tons de pele.

ICU4J APIs no Android

Agora o Android 7.0 oferece um subconjunto de APIs ICU4J na estrutura do Android no pacote android.icu. A migração é fácil e geralmente exige apenas a mudança do namespace com.java.icu para android.icu. Se você já usa um pacote ICU4J nos seus aplicativos, a mudança para as APIs do android.icu disponibilizadas na estrutura do Android pode reduzir substancialmente o tamanho do APK.

Para saber mais sobre as APIs ICU4J no Android, consulte Suporte ao ICU4J.

WebView

Chrome + WebView, juntos

A partir do Chrome versão 51 do Android 7.0 e de posteriores, o Chrome APK do seu dispositivo é usado para fornecer e renderizar WebViews de sistema do Android. Essa abordagem otimiza o uso de memória do dispositivo e reduz a largura de banda necessária para manter a WebView atualizada (já que a WebView APK autônoma não será mais atualizada enquanto o Chrome estiver ativo).

Para escolher o provedor de WebView, ative as Opções do desenvolvedor e selecione Implementação de WebView. É possível usar qualquer versão compatível do Chrome (Dev, Beta ou estável) que esteja instalada no dispositivo ou a Webview APK autônoma para atuar como a implementação de WebView.

Multiprocesso

A partir da versão 51 do Chrome do Android 7.0, o WebView executará conteúdo da web em um processo de segurança separado quando a opção de desenvolvedor “Multiprocess WebView” estiver ativada.

Estamos buscando comentários e opiniões sobre compatibilidade e desempenho durante a execução no N antes de ativar o Multiprocess WebView em uma versão futura do Android. Nesta versão, esperam-se regressões no tempo de inicialização, no uso de memória total e no desempenho de renderização do software.

Conte-nos se você encontrar problemas inesperados no modo multiprocesso. Entre em contato com a equipe do WebView no rastreador de falhas do Chromium.

JavaScript executado antes do carregamento da página

A partir de aplicativos voltados para o Android 7.0, a definição do contexto do JavaScript ocorrerá ao carregar uma nova página. Atualmente, transfere-se o contexto para a primeira página carregada em uma nova instância de WebView.

Os desenvolvedores que desejam inserir JavaScript no WebView devem executar o script antes de a página começar a carregar.

Geolocalização em origens desprotegidas

A partir de aplicativos voltados ao Android 7.0, a API de geolocalização será permitida apenas de origens seguras (por HTTPS). Essa política tem como objetivo proteger as informações privadas dos usuários quando eles usarem uma conexão desprotegida.

Testes com WebView beta

A WebView é atualizada regularmente, por isso recomendamos usar o canal beta da WebView para testar com frequência a compatibilidade com seu aplicativo. Para começar a testar versões pré-lançadas da WebView no Android 7.0, baixe e instale o Chrome Dev ou o Chrome Beta e selecione-o como a implementação de WebView nas opções do desenvolvedor, conforme descrito acima. Relate problemas no rastreador de falhas do Chromium para os corrigirmos antes do lançamento de uma nova versão do WebView.

OpenGL™ ES 3.2 API

O Android 7.0 adiciona interfaces de estrutura e compatibilidade plataforma ao OpenGL ES 3.2, dentre elas:

• Todas as extensões do Pacote de extensão Android (AEP), exceto EXT_texture_sRGB_decode.
• Framebuffers de ponto flutuante para HDR e sombreamento adiado.
• Chamadas de desenho a BaseVertex para possibilitar melhor organização em lotes e transmissão.
• Controle robusto de acesso a buffers para reduzir a sobrecarga do WebGL.

A API da estrutura do OpenGL ES 3.2 no Android 7.0 é fornecida pela classe GLES32. Ao usar o OpenGL ES 3.2, não deixe de usar o rótulo <uses-feature> e o atributo android:glEsVersion para declarar o requisito no arquivo manifesto.

Para obter mais informações sobre o uso de OpenGL ES, inclusive como verificar a versão do OpenGL ES compatível do dispositivo no tempo de execução, consulte o guia da OpenGL ES API.

Gravação do Android TV

O Android 7.0 adiciona a capacidade de gravar e reproduzir conteúdo de serviços de entrada do Android TV por meio de novas APIs de gravação. Criados usando as APIs atuais de time-shifting, os serviços de entrada de TV podem controlar quais dados de canal são gravados e como as sessões gravadas são salvas, bem como gerenciar a interação do usuário com o conteúdo gravado.

Para obter mais informações, consulte Android TV Recording APIs.

Android for Work

O Android for Work adiciona vários recursos e APIs para dispositivos que executam o Android 7.0. Veja a seguir alguns destaques — para obter uma lista completa das mudanças, consulte atualizações no Android for Work.

Desafio de segurança de perfil de trabalho

Proprietários de perfis que trabalham com o N SDK podem especificar um desafio de segurança em separado para aplicativos em execução no perfil de trabalho. O desafio de trabalho é exibido quando um usuário tenta abrir qualquer aplicativo de trabalho. O preenchimento correto do desafio de segurança desbloqueia e, se necessário, descriptografa o perfil de trabalho. Para proprietários de perfil, ACTION_SET_NEW_PASSWORD solicita que o usuário defina um desafio de trabalho e ACTION_SET_NEW_PARENT_PROFILE_PASSWORD um bloqueio de dispositivo.

Para definir políticas de senha distintas para o desafio de trabalho (como o comprimento mínimo do PIN ou se é permitido usar a impressão digital para desbloquear o perfil), os proprietários de perfil também podem usar setPasswordQuality(), setPasswordMinimumLength() e métodos relacionados. Para definir o bloqueio de dispositivo, o proprietário de perfil também pode usar a instância de DevicePolicyManager que o novo método getParentProfileInstance() retorna. Além disso, para personalizar a tela de credenciais do desafio de trabalho, os proprietários de perfil podem usar os novos métodos setOrganizationColor() e setOrganizationName().

Desativar o trabalho

Os usuários podem alternar o modo de trabalho em dispositivos com um perfil de trabalho. Quando o modo de trabalho está desativado, o usuário gerenciado é encerrado temporariamente, o que desativa os aplicativos, a sincronização em segundo plano e as notificações do perfil de trabalho. Isso abrange o aplicativo proprietário do perfil. Quando o modo de trabalho está desativado, o sistema exibe um ícone de status persistente para lembrar ao usuário que não é possível iniciar aplicativos de trabalho. A tela de início indica que não é possível acessar os aplicativos e widgets de trabalho.

Always on VPN

Os proprietários de dispositivo e perfil podem garantir que os aplicativos de trabalho se conectem sempre por meio de uma VPN especificada. O sistema inicia automaticamente a VPN após a inicialização do dispositivo.

Os novos métodos DevicePolicyManager são setAlwaysOnVpnPackage() e getAlwaysOnVpnPackage().

Como os serviços de VPN podem ser vinculados diretamente pelo sistema sem interação com aplicativos, os clientes de VPN precisam processar novos pontos de entrada para o Always on VPN. Da mesma forma que antes, os serviços são indicados ao sistema por um filtro de intent correspondente à ação android.net.VpnService.

Além disso, os usuários podem definir manualmente clientes do Always on VPN que implementam métodos VPNService no usuário principal usando Settings>More>Vpn. A opção de ativar Always on VPN em Settings está disponível somente se o cliente da VPN trabalha com API de nível 24.

Provisionamento personalizado

Os aplicativos podem personalizar os fluxos de provisionamento do proprietário do perfil e do dispositivo com cores e logos corporativos. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR personaliza a cor do fluxo. DevicePolicyManager.EXTRA_PROVISIONING_LOGO_URI personaliza o fluxo com um logotipo corporativo.

Aprimoramentos na acessibilidade

O Android 7.0 agora oferece Configurações de visão diretamente na tela de boas-vindas na instalação de novos dispositivos. Assim, os usuários podem descobrir e configurar recursos de acessibilidade no dispositivo muito mais facilmente, inclusive gesto de ampliação, tamanho da fonte, tamanho da tela e TalkBack.

Com o posicionamento mais destacado desses recursos de acessibilidade, os usuários ficarão mais propensos a experimentar o aplicativo com os recursos ativados. Não deixe de testar antecipadamente os aplicativos com essas configurações ativas. Para ativá-las, acesse Configurações > Acessibilidade.

Além disso, os serviços de acessibilidade no Android 7.0 podem ajudar usuários com deficiências motoras a tocar na tela. A nova API permite criar serviços com recursos como acompanhamento de face, acompanhamento de olho e varredura de pontos, entre outros, para atender às necessidades desses usuários.

Para obter mais informações, consulte android.accessibilityservice.GestureDescription na Referência da API, disponível para baixar.

Inicialização direta

A inicialização direta diminui o tempo de inicialização do dispositivo e permite que aplicativos registrados tenham funcionamento limitado, mesmo após uma inicialização inesperada. Por exemplo: se um dispositivo criptografado reinicializar durante o sono do usuário, alarmes registrados, mensagens e chamadas recebidas agora poderão continuar notificando o usuário normalmente. Isso também significa que serviços de acessibilidade poderão estar disponíveis imediatamente após uma reinicialização.

A inicialização direta se beneficia da criptografia baseada em arquivos do Android 7.0 para permitir políticas de criptografia detalhadas para dados do sistema e dos aplicativos. O sistema usa uma série de dispositivos criptografados para selecionar dados do sistema e dados de aplicativo registrados explicitamente. Por padrão, um armazenamento criptografado por credencial é usado para todos os outros dados de sistema, dados de usuário, aplicativos e dados de aplicativo.

Na inicialização, o sistema começa em modo restrito, com acesso somente a dados criptografados do dispositivo e sem acesso geral a aplicativos ou dados. Se você tiver componentes que deseja executar nesse modo, configure um sinalizador no manifesto para registrá-los. Após a reinicialização, o sistema transmite a intent LOCKED_BOOT_COMPLETED para ativar componentes registrados. O sistema garante que os dados de aplicativos registrados criptografados pelo dispositivo estejam disponíveis antes do desbloqueio. Todos os outros dados ficarão indisponíveis até o usuário confirmar as credenciais da tela de bloqueio para descriptografá-los.

Para obter mais informações, consulte Inicialização direta.

Confirmação de chaves

O Android 7.0 oferece a confirmação de chave, um novo recurso de segurança que ajuda a garantir que os pares de chave armazenados dentro do armazenamento de chaves apoiado por hardware do dispositivo protejam adequadamente as informações sigilosas que o aplicativo usa. Com esse recurso, você ganha mais confiança de que seu aplicativo interage com chaves armazenadas em hardware seguro, mesmo ao acessar por raiz o dispositivo que executa o aplicativo. Se você usar chaves do armazenamento de chaves apoiado por hardware no seu aplicativo, use esse recurso principalmente se usar as chaves para verificar informações sigilosas do seu aplicativo.

A confirmação de chaves permite verificar se um par de chaves RSA ou EC foi criado e armazenado em um armazenamento de chaves apoiado por hardware do dispositivo dentro do ambiente de execução confiável do dispositivo (TEE). O recurso também permite usar um serviço externo ao dispositivo, como o servidor de retaguarda do seu aplicativo, para determinar e verificar com precisão os usos e a validade do par de chaves. Esses recursos criam um nível de segurança adicional que protege o par de chaves, mesmo se alguém acessar por raiz o dispositivo ou comprometer a segurança da plataforma Android executada no dispositivo.

Observação: Poucos dispositivos que executam o Android 7.0 são compatíveis com a confirmação de chaves no nível de hardware. Todos os demais dispositivos com Android 7.0 usam a confirmação de chaves no nível de software. Antes de verificar as propriedades das chaves protegidas por hardware de um dispositivo em um ambiente de produção, certifique-se de que o dispositivo ofereça suporte à confirmação de chaves no nível do hardware. Para isso, verifique se a cadeia de certificados de confirmação contém um certificado raiz assinado pela chave raiz de confirmação do Google e que o elemento attestationSecurityLevel na estrutura de dados de descriptografia de chaves seja definido para o nível de segurança TrustedEnvironment.

Para saber mais, consulte a documentação Confirmação de chaves para desenvolvedores.

Configuração de segurança de rede

No Android 7.0, os aplicativos podem personalizar o comportamento de conexões protegidas (HTTPS, TLS) de forma segura, sem modificação no código, com a Configuração de segurança de rede declarativa em vez de APIs programáticas propensas a erro (por exemplo, X509TrustManager).

Recursos compatíveis:

• Âncoras de confiança personalizadas. Permite que um aplicativo personalize quais autoridades de certificado (CA) são confiáveis para as conexões seguras. Por exemplo: confiar em certificados autoassinados privados ou um restrito conjunto de CAs públicas.
• Substituições apenas em depuração. Permite que um desenvolvedor de aplicativos depure conexões seguras do aplicativo com segurança, sem adicionar riscos à base instalada.
• Cancelamento do uso de tráfego de texto simples. Permite que um aplicativo seja protegido contra o uso acidental de tráfego de texto simples.
• Fixação de certificados. Um recurso avançado que permite que os aplicativos limitem quais chaves de servidor são confiáveis para conexões seguras.

Para obter mais configurações, consulte Configuração de segurança de rede.

Autoridade de certificação confiável padrão

Por padrão, os aplicativos direcionados ao Android 7.0 confiam apenas em certificados fornecidos pelo sistema e não confiam mais em Autoridades de certificado (CA) adicionadas pelo usuário. Os aplicativos direcionados ao Android N que querem confiar em CAs adicionadas pelo usuário devem usar a Configuração de segurança de rede para especificar como confiar nas CAs de usuário.

Esquema de assinatura de APK v2

O Android 7.0 apresenta o esquema de assinatura de APK v2, um novo esquema de assinatura de aplicativo que oferece instalações mais rápidas e maior proteção contra alterações não autorizadas de arquivos APK. Por padrão, o Android Studio 2.2 e o plug-in do Android para Gradle 2.2 assinam seu aplicativo com o esquema de assinatura de APK v2 e o esquema tradicional, que usa assinaturas JAR.

A aplicação do esquema de assinatura de APK v2 ao aplicativo é recomendável, mas opcional. Se o aplicativo não compila adequadamente ao usar o esquema de assinatura de APK v2, você poderá desativá-lo. O processo de desativação faz com que o Android Studio 2.2 e o plug-in do Android para Gradle 2.2 assinem o aplicativo usando apenas o esquema de assinatura tradicional. Para assinar apenas com o esquema tradicional, abra o arquivo do nível de módulo build.gradle e adicione a linha v2SigningEnabled false à configuração de assinatura de sua versão:

  android {
    ...
    defaultConfig { ... }
    signingConfigs {
      release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
        v2SigningEnabled false
      }
    }
  }

Atenção: Se você assinar o aplicativo usando o esquema de assinatura de APK v2 e fizer novas alterações posteriormente, a assinatura do aplicativo será invalidada. Por esse motivo, use ferramentas como zipalign antes de assinar o aplicativo usando o esquema de assinatura de APK v2, não depois.

Para obter mais informações, leia os documentos do Android Studio que descrevem como assinar um aplicativo no Android Studio e como configurar o arquivo de programação para assinar aplicativos usando o plug-in do Android para Gradle.

Acesso a diretórios com escopo

No Android 7.0, os aplicativos podem usar novas APIs para solicitar acesso a determinados diretórios do armazenamento externo, inclusive diretórios em mídias removíveis, tais como cartões SD. As novas APIs simplificam consideravelmente o acesso do aplicativo a diretórios de armazenamento externo padrão, como o diretório Pictures. Os aplicativos, como os aplicativos de fotografia, podem usar essas APIs em vez de READ_EXTERNAL_STORAGE, que concedem acesso a todos os diretórios de armazenamento, ou da Estrutura de acesso ao armazenamento, que faz o usuário navegar até o diretório.

Além disso, as novas APIs simplificam as etapas executadas pelo usuário para conceder ao aplicativo acesso ao armazenamento externo. Com as novas APIs, o sistema usa uma IU de permissões simples que detalha claramente o diretório ao qual o aplicativo está solicitando acesso.

Para obter mais informações, consulte a documentação Acessos a diretório com escopo para desenvolvedores.

Auxiliar de atalhos do teclado

No Android 7.0, o usuário pode pressionar Meta + / para acionar uma tela de atalhos de teclado que exibe todos os atalhos disponíveis do sistema e do aplicativo em questão. O sistema recupera esses atalhos automaticamente a partir do menu do aplicativo, se houver. Você também pode fornecer suas próprias listas de atalhos adaptados para a tela. Para isso, substitua o novo método Activity.onProvideKeyboardShortcuts(), conforme descrito na Referência da API, disponível para baixar.

Observação: A tecla Meta não está presente em todos os teclados: em teclados Macintosh, é a tecla Command; nos teclados Windows, é a tecla Windows; e nos teclados Pixel C e Chrome OS, é a tecla Search.

Para acionar o auxiliar de atalhos de teclado em qualquer ponto do aplicativo, chame Activity.requestKeyboardShortcutsHelper() para a atividade correspondente.

Custom Pointer API

O Android 7.0 introduz a Custom Pointer API, que permite personalizar a aparência, a visibilidade e o comportamento do ponteiro. Esse recurso é muito útil quando um usuário está usando mouse ou touchpad para interagir com objetos da IU. O ponteiro padrão usa um ícone comum. Essa API também contém funções avançadas, como alterar a aparência do ícone do ponteiro com base em movimentos específicos de mouse e de touchpad.

Para definir um ícone para o ponteiro, modifique o método onResolvePointerIcon() da classe View. Esse método usa um objeto PointerIcon para apresentar o ícone que corresponde a um evento de movimento específico.

Sustained Performance API

O desempenho pode oscilar drasticamente em aplicativos executados por muito tempo porque o sistema aciona os mecanismos de “sistema em um chip” quando os componentes do dispositivo atingem o limite de temperatura. Esta oscilação representa um desafio para desenvolvedores de aplicativos, que criam aplicativos de alto desempenho e longa duração.

Para tratar dessas limitações, o Android 7.0 tem compatibilidade opcional com o modo de desempenho sustentado, permitindo que OEMs ofereçam dicas sobre recursos de desempenho dos dispositivos para aplicativos de longa duração. Os desenvolvedores de aplicativos podem usar essas dicas para ajustar os aplicativos para um nível de desempenho previsível e consistente em longos períodos de tempo.

Os desenvolvedores de aplicativos só podem testar essa nova API do Android 7.0 em dispositivos Nexus 6P. Para usar esse recurso, configure a janela de sinalização de desempenho sustentado para a janela que você quer executar em modo de desempenho sustentado. Para configurar essa sinalização, use o método Window.setSustainedPerformanceMode(). O sistema desativará esse modo automaticamente quando a janela não estiver mais em foco.

Compatibilidade com RV

O Android 7.0 adiciona compatibilidade de plataformas e otimizações para um novo Modo de RV, que dá aos desenvolvedores a capacidade de projetar experiências de RV de alta qualidade em dispositivos móveis para os usuários. Há diversas melhorias de desempenho, inclusive o acesso a um núcleo exclusivo da CPU para aplicativos de RV. Dentro dos aplicativos, é possível aproveitar o rastreamento inteligente da cabeça e notificações estéreo que trabalham para a RV. Mais importante: o Android 7.0 oferece gráficos de latência muito baixa. Para obter informações completas sobre a criação de aplicativos de RV para Android 7.0, consulte o Google VR SDK para Android.

Melhorias nos serviços de impressão

No Android 7.0, agora os desenvolvedores de serviços de impressão podem exibir informações adicionais sobre impressoras e trabalhos de impressão individuais.

Ao listar impressoras individuais, agora um serviço de impressão pode definir ícones por impressora de duas maneiras:

• É possível definir um ícone de um ID de recurso chamando PrinterInfo.Builder.setResourceIconId()
• É possível exibir um ícone da rede chamando PrinterInfo.Builder.setHasCustomPrinterIcon() e definindo um retorno de chamada para quando o ícone for solicitado usando android.printservice.PrinterDiscoverySession.onRequestCustomPrinterIcon()

Além disso, você pode fornecer atividade por impressora para exibir informações adicionais chamando PrinterInfo.Builder.setInfoIntent().

É possível indicar o progresso e o status de trabalhos de impressão na notificação de trabalhos de impressão chamando android.printservice.PrintJob.setProgress() e android.printservice.PrintJob.setStatus() respectivamente.

Para obter mais informações sobre estes métodos, consulte a Referência da API, disponível para baixar.

FrameMetricsListener API

A FrameMetricsListener API permite que um aplicativo monitore o desempenho de renderização da IU. Para oferecer esse recurso, a API expõe uma Pub/Sub API em streaming para transferir sincronização de quadro à janela atual do aplicativo. Os dados retornados são equivalentes aos que adb shell dumpsys gfxinfo framestats exibe, mas não estão mais limitados a 120 quadros.

É possível usar o FrameMetricsListener para medir o desempenho da IU em termos de interação na produção sem conexão USB. Essa API permite a coleta de dados com granularidade muito maior do que adb shell dumpsys gfxinfo. A maior granularidade é possível porque o sistema pode coletar dados para determinadas interações no aplicativo. O sistema não precisa capturar um resumo geral do desempenho do aplicativo nem apagar nenhum estado geral. É possível usar esse recurso para reunir dados de desempenho e capturar regressões no desempenho da IU para casos de uso reais dentro do aplicativo.

Para monitorar uma janela, implemente o método de retorno de chamada FrameMetricsListener.onMetricsAvailable() e registre-o nessa janela. Para obter mais informações, consulte a documentação da classe FrameMetricsListener na Referência da API, disponível para baixar.

A API fornece um objeto FrameMetrics, que contém dados de quadro que o subsistema de renderização relata para vários marcos no ciclo de vida de um quadro. As métricas aceitas são: UNKNOWN_DELAY_DURATION, INPUT_HANDLING_DURATION, ANIMATION_DURATION, LAYOUT_MEASURE_DURATION, DRAW_DURATION, SYNC_DURATION, COMMAND_ISSUE_DURATION, SWAP_BUFFERS_DURATION, TOTAL_DURATION e FIRST_DRAW_FRAME.

Arquivos virtuais

Em versões anteriores do Android, o aplicativo podia usar a estrutura de acesso ao armazenamento para que os usuários selecionassem arquivos de contas de armazenamento em nuvem, como o Google Drive. No entanto, não é possível representar arquivos que não tenham uma representação direta de código de bytes — os arquivos precisam fornecer um fluxo de entrada.

O Android 7.0 adiciona o conceito de arquivos virtuais à estrutura de acesso ao armazenamento. O recurso de arquivos virtuais permite que o DocumentsProvider retorne URIs de documentos que possam ser usados com intents ACTION_VIEW, mesmo que não haja nenhuma representação direta de código de bytes. O Android 7.0 também lhe permite oferecer formatos alternativos para arquivos de usuário, virtuais ou não.

Para obter o URI para um documento virtual em seu aplicativo, é preciso criar uma Intent para abrir a IU do seletor de arquivos. Como um aplicativo não consegue abrir um arquivo virtual diretamente usando o método openInputStream(), seu aplicativo não receberá arquivos virtuais se você não incluir a categoria CATEGORY_OPENABLE.

Depois que o usuário fizer uma seleção, o sistema chamará o método onActivityResult(). O aplicativo pode recuperar o URI do arquivo virtual e obter um fluxo de resultados, como demonstrado no fragmento de código abaixo.

  // Other Activity code ...

  final static private int REQUEST_CODE = 64;

  // We listen to the OnActivityResult event to respond to the user's selection.
  @Override
  public void onActivityResult(int requestCode, int resultCode,
    Intent resultData) {
      try {
        if (requestCode == REQUEST_CODE &&
            resultCode == Activity.RESULT_OK) {

            Uri uri = null;

            if (resultData != null) {
                uri = resultData.getData();

                ContentResolver resolver = getContentResolver();

                // Before attempting to coerce a file into a MIME type,
                // check to see what alternative MIME types are available to
                // coerce this file into.
                String[] streamTypes =
                  resolver.getStreamTypes(uri, "*/*");

                AssetFileDescriptor descriptor =
                    resolver.openTypedAssetFileDescriptor(
                        uri,
                        streamTypes[0],
                        null);

                // Retrieve a stream to the virtual file.
                InputStream inputStream = descriptor.createInputStream();
            }
        }
      } catch (Exception ex) {
        Log.e("EXCEPTION", "ERROR: ", ex);
      }
  }

Para obter mais informações sobre como acessar arquivos de usuário, consulte o guia da estrutura de acesso ao armazenamento.