Android 7.0 para desenvolvedores

O Android 7.0 Nougat introduz uma variedade de novos recursos e funções para usuários e desenvolvedores. Este documento destaca as novidades para os desenvolvedores.

Confira as Mudanças de comportamento do Android 7.0 para saber mais sobre as áreas em que as mudanças da plataforma podem afetar seus apps.

Para saber mais sobre os recursos para o consumidor do Android 7.0, visite www.android.com.

Suporte a várias janelas

No Android 7.0, apresentamos 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 smartphones e tablets com o Android 7.0, os usuários podem executar dois apps lado a lado ou um acima do outro no modo de tela dividida. Os usuários podem redimensionar os apps arrastando o divisor entre eles.
  • Em dispositivos Android TV, os apps podem ser colocados no modo picture-in-picture, o que permite que continuem mostrando conteúdo enquanto o usuário navega ou interage com outros apps.
Apps móveis executando no modo de tela dividida

Figura 1. Apps em execução no modo de tela dividida.

O suporte a várias janelas oferece novas maneiras de envolver os usuários, principalmente em tablets e outros dispositivos com telas maiores. Você pode até ativar o recurso de arrastar e soltar para permitir que os usuários arrastem conteúdo para dentro ou fora do app. Essa é uma ótima maneira de melhorar a experiência do usuário.

É simples adicionar suporte a várias janelas ao app e configurar como ele processa a exibição em várias janelas. Por exemplo, você pode especificar as dimensões mínimas permitidas para a atividade, impedindo que os usuários a redimensionem abaixo desse tamanho. Você também pode desativar a exibição em várias janelas para seu app, o que garante que o sistema o mostre apenas em modo de tela cheia.

Para mais informações, consulte a documentação para desenvolvedores sobre suporte a várias janelas.

Melhorias às notificações

No Android 7.0, reformulamos as notificações para torná-las mais fáceis e rápidas de usar. Entre as alterações, temos:

  • Atualizações de modelo: estamos atualizando os modelos de notificação para dar mais ênfase à imagem principal e ao avatar. Os desenvolvedores poderão aproveitar os novos modelos com ajustes mínimos no código.
  • Personalização do estilo de mensagens: você pode personalizar mais rótulos de interface do usuário associados às suas notificações usando a classe MessagingStyle. É possível configurar a mensagem, o título da conversa e a visualização do conteúdo.
  • Notificações agrupadas: o sistema pode agrupar mensagens, por exemplo, por tópico de mensagem, e mostrar o grupo. Um usuário pode realizar ações, como Dispensar ou Arquivar, nesses itens. Se você já implementou notificações para o Android Wear, já conhece esse modelo.
  • Resposta direta: para apps de comunicação em tempo real, o sistema Android oferece suporte a respostas inline para que os usuários possam responder rapidamente a um SMS ou mensagem de texto diretamente na interface de notificação.
  • Visualizações personalizadas: duas novas APIs permitem usar decorações do sistema, como cabeçalhos e ações de notificação, ao usar visualizações personalizadas em notificações.
Dispositivo móvel exibindo notificações de mensagens agrupadas
Dispositivo móvel exibindo notificação de mensagem única
Dispositivo móvel exibindo a resposta de mensagem inline na interface de notificação

Figura 2. Pacote de notificações 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 criação de perfil de código para o ART, que permite melhorar constantemente a performance de apps Android durante a execução. O compilador JIT complementa o compilador atual Ahead of Time (AOT) do ART e ajuda a melhorar a performance no momento da execução, economizar espaço de armazenamento e acelerar atualizações de apps e do sistema.

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

Além de melhorar o desempenho das principais partes do app, a compilação guiada por perfil ajuda a reduzir o uso geral de recursos de RAM, incluindo os binários associados. Esse recurso é especialmente importante em dispositivos com pouca memória.

O ART gerencia a compilação guiada por perfil de forma a minimizar o impacto na bateria do dispositivo. A pré-compilação é feita apenas quando o dispositivo está inativo e carregando, economizando tempo e bateria com a execução antecipada dessa tarefa.

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

Um dos benefícios mais tangíveis do compilador JIT do ART é a velocidade das instalações de apps e das atualizações do sistema. Até mesmo apps grandes que precisavam de vários minutos para otimização e instalação no Android 6.0 agora podem ser instalados em questão de segundos. As atualizações do sistema também são mais rápidas, porque não há mais uma etapa de otimização.

Modo soneca em movimento...

O Android 6.0 introduziu o "Soneca", um modo de sistema que economiza bateria adiando atividades de CPU e rede dos apps quando o dispositivo está ocioso, por exemplo, quando está em uma mesa ou gaveta.

Agora, no Android 7.0, o recurso Soneca dá um passo adiante e economiza bateria em qualquer lugar. Sempre que a tela ficar desligada por um período e o dispositivo estiver desconectado, o recurso Soneca aplica um subconjunto das restrições conhecidas de CPU e rede aos apps. Isso significa que os usuários podem economizar bateria mesmo quando carregam os dispositivos no bolso.

Ilustração de como o modo Soneca aplica um primeiro nível de restrições de atividade do sistema para melhorar a duração da bateria

Figura 3. O recurso "Soneca" agora aplica restrições para melhorar a duração da bateria, mesmo quando o dispositivo não está parado.

Pouco depois que a tela é desligada enquanto o dispositivo está usando a bateria, o modo Soneca restringe o acesso à rede e adia jobs e sincronizações. Durante breves janelas de manutenção, os aplicativos têm acesso à rede e todos os jobs/sincronizações adiados são executados. Ligar a tela ou conectar o dispositivo faz com que ele saia do modo Soneca.

Quando o dispositivo estiver parado novamente, com a tela desligada e ligado na bateria por um período, o modo Soneca aplicará as restrições completas de CPU e rede em alarmes PowerManager.WakeLock, AlarmManager e buscas por GPS/Wi-Fi.

As práticas recomendadas para adaptar seu app ao modo Soneca são as mesmas, esteja o dispositivo em movimento ou não. Portanto, se você já atualizou o app para processar o recurso Soneca, está tudo pronto. Caso contrário, comece a adaptar seu app para o modo Soneca agora.

Project Svelte: otimizações em segundo plano

O Project Svelte é um esforço contínuo para minimizar o uso de RAM pelo sistema e pelos apps em todos os dispositivos Android do ecossistema. No Android 7.0, o Project Svelte se concentra em otimizar a maneira como os apps são executados 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 baseada no contexto. Quando não é feito corretamente, o processamento em segundo plano pode consumir RAM (e bateria) desnecessariamente e afetar o desempenho do sistema para outros apps.

Desde o Android 5.0, JobScheduler é a maneira preferencial de trabalhar em segundo plano de uma forma benéfica para os usuários. Os apps podem agendar jobs e permitir que o sistema otimize com base em condições de memória, energia e conectividade. O JobScheduler oferece controle e simplicidade, e queremos que seja usado por todos os apps.

Outra boa opção é o GCMNetworkManager, parte do Google Play Services, que oferece agendamento de tarefas semelhante com compatibilidade em versões legadas do Android.

Continuamos estendendo JobScheduler e GCMNetworkManager para atender a mais seus casos de uso. Por exemplo, no Android 7.0, agora é possível programar trabalhos em segundo plano com base em mudanças nos provedores de conteúdo. Ao mesmo tempo, estamos começando a descontinuar alguns dos 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 usadas com frequência (CONNECTIVITY_ACTION, ACTION_NEW_PICTURE e ACTION_NEW_VIDEO), já que elas podem ativar os processos em segundo plano de vários apps de uma só vez e consumir memória e bateria. Se seu app estiver recebendo esses pacotes, aproveite o Android 7.0 para migrar para JobScheduler e APIs relacionadas.

Confira a documentação Otimizações em segundo plano para mais detalhes.

SurfaceView

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

A classe SurfaceView permite composições mais eficientes em termos de bateria na tela, porque ela é composta por hardware dedicado, separado do conteúdo da janela do app. 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 app em questão Um resultado dessa mudança é que traduções ou escalas simples de um vídeo reproduzido em um SurfaceView não geram mais barras pretas ao lado da visualização à medida que ela se move.

A partir do Android 7.0, é altamente recomendável economizar energia usando SurfaceView em vez de TextureView.

Economia de dados

Economia de dados nas configurações

Figura 4. Economia de dados em Configurações.

Durante a vida útil de um dispositivo móvel, o custo de um plano de dados móveis normalmente excede o custo do próprio dispositivo. Para muitos usuários, os dados móveis são um recurso caro que eles querem economizar.

O Android 7.0 apresenta o modo de Economia de dados, um novo serviço do sistema que ajuda a reduzir o uso de dados da rede celular por apps, seja em roaming, perto do fim do ciclo de faturamento ou em um pacote de dados pré-pago pequeno. A Economia de dados permite que os usuários controlem a forma como os apps usam dados móveis e que os desenvolvedores ofereçam um serviço mais eficiente quando esse recurso estiver ativado.

Quando um usuário ativa a Economia de dados nas Configurações e o dispositivo está em uma rede limitada, o sistema bloqueia o uso de dados em segundo plano e sinaliza aos apps para usar menos dados em primeiro plano sempre que possível, por exemplo, limitando a taxa de bits para streaming, reduzindo a qualidade da imagem, adiando o armazenamento em cache otimista e assim por diante. Os usuários podem permitir que apps específicos usem dados limitados em segundo plano, mesmo quando a Economia de dados estiver ativada.

O Android 7.0 estende a ConnectivityManager para oferecer aos apps uma maneira de recuperar as preferências da Economia de dados do usuário e monitorar as mudanças de preferências. Todos os apps precisam verificar se o usuário ativou a Economia de dados e tentar limitar o uso de dados em primeiro e segundo plano.

Vulkan API

O Android 7.0 integra a VulkanTM, uma nova API de renderização em 3D, à plataforma. Assim como o OpenGLTM ES, o Vulkan é um padrão aberto para gráficos e renderização 3D mantido pelo Khronos Group.

O Vulkan foi projetado do zero para minimizar a sobrecarga da CPU no driver e permitir que seu aplicativo controle a operação da GPU de forma mais direta. O Vulkan também permite um melhor paralelismo, permitindo que várias linhas de execução 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 SDK do Android 7.0. Elas incluem:

  • 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 apps em dispositivos com hardware compatível com Vulkan, como Nexus 5X, Nexus 6P e Nexus Player. Estamos trabalhando em estreita colaboração com nossos parceiros para levar o Vulkan a mais dispositivos o mais rápido possível.

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

Quick Settings Tile API

Blocos de Configurações rápidas na aba de notificações

Figura 5. Blocos de Configurações rápidas na aba de notificações.

As Configurações rápidas são uma maneira conhecida e simples de expor as principais configurações e ações diretamente na aba de notificações. No Android 7.0, expandimos o escopo das Configurações rápidas para torná-las ainda mais úteis e convenientes.

Adicionamos mais espaço para os blocos de Configurações rápidas, que os usuários podem acessar em uma área de exibição paginada deslizando para a esquerda ou direita. Também permitimos que os usuários controlem quais blocos de Configurações rápidas aparecem e onde eles são exibidos. Eles podem adicionar ou mover blocos apenas arrastando e soltando.

Para desenvolvedores, o Android 7.0 também adiciona uma nova API que permite definir seus próprios blocos de Configurações rápidas para oferecer aos usuários acesso fácil aos principais controles e ações do app.

Os blocos das Configurações rápidas são reservados para controles ou ações que são necessários urgentemente ou usados com frequência e não podem ser usados como atalhos para iniciar um app.

Depois de definir os blocos, você pode exibi-los para os usuários, que podem adicioná-los às Configurações rápidas usando o recurso de arrastar e soltar.

Para saber mais sobre como criar um bloco de app, consulte a documentação de referência de Tile.

Bloqueio de número

O Android 7.0 agora oferece suporte ao bloqueio de números na plataforma e fornece uma API de framework para permitir que os provedores de serviços mantenham uma lista de números bloqueados. O app de SMS padrão, o app de telefone padrão e os apps de operadora podem ler e gravar a lista de números bloqueados. Outros aplicativos não terão acesso à lista.

Ao tornar o bloqueio de número um recurso padrão da plataforma, o Android oferece uma forma consistente de bloqueio de números em 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
  • Os números bloqueados podem persistir entre as redefinições e dispositivos pelo recurso "Backup e restauração"
  • Vários aplicativos podem usar a mesma lista de números bloqueados

Além disso, com a integração de apps da operadora pelo Android, as operadoras podem ler a lista de números bloqueados no dispositivo e realizar o bloqueio do lado do serviço para impedir que chamadas e mensagens de texto indesejadas cheguem ao usuário por qualquer meio, como um endpoint VOIP ou encaminhamento de telefones.

Para saber mais, consulte a documentação de referência para BlockedNumberContract.

Triagem de chamadas

O Android 7.0 permite que o aplicativo de telefone padrão faça a triagem das chamadas recebidas. O app para telefone faz isso implementando o novo CallScreeningService, que permite que ele execute várias ações com base no Call.Details da chamada recebida, por exemplo:

  • 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 saber mais, consulte a documentação de referência para CallScreeningService.

Compatibilidade com diversas localidades, mais idiomas

O Android 7.0 agora permite que os usuários selecionem várias localidades nas Configurações para oferecer melhor suporte a casos de uso bilíngues. Os apps podem usar uma nova API para descobrir as localidades selecionadas pelo usuário e oferecer experiências mais sofisticadas para usuários de várias localidades, como mostrar resultados da pesquisa em vários idiomas e não oferecer a tradução de páginas da Web em um idioma que o usuário já conheça.

Junto com o suporte a várias localidades, o Android 7.0 também amplia a variedade de idiomas disponíveis para os usuários. Ele oferece mais de 25 variantes para cada um dos idiomas mais usados, como inglês, espanhol, francês e árabe. Ele também adiciona suporte parcial a mais de 100 novos idiomas.

Os apps podem receber a lista de localidades definidas pelo usuário chamando LocaleList.GetDefault(). Para oferecer suporte ao maior número de localidades, o Android 7.0 está mudando a forma de resolver recursos. Não deixe de testar e verificar se seus apps funcionam como esperado com a nova lógica de resolução de recursos.

Para saber mais sobre o novo comportamento de resolução de recursos e as práticas recomendadas que você precisa seguir, consulte Suporte multilíngue.

Novos emoticons

O Android 7.0 apresenta emojis adicionais e recursos relacionados, incluindo emojis com diferentes tons de pele e suporte a seletores de variação. Se o app oferecer suporte a emojis, siga as diretrizes abaixo para aproveitar esses recursos relacionados a emojis.

  • Verifique se o dispositivo contém um emoji antes de inseri-lo. Para verificar quais emojis estão presentes na fonte do sistema, use o método hasGlyph(String).
  • Verifique se um emoji é compatível com seletores de variação. Os seletores de variação permitem apresentar determinados emojis 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. No entanto, se o app exibe emojis alinhados ao texto, ele precisa usar a variação em preto e branco. Para determinar se um emoticon tem variação ou não, use o seletor de variação. Para ver uma lista completa de caracteres com variações, consulte a seção sequências de variação de emoji da documentação sobre variações em Unicode.
  • Confira se um emoji é compatível com tons de pele. O Android 7.0 permite que os usuários modifiquem o tom de pele renderizado de emojis como quiserem. Os apps de teclado precisam oferecer indicações visuais para emojis que tenham vários tons de pele e permitir que os usuários selecionem a sua preferência. Para determinar quais emojis do sistema têm modificadores de tom de pele, use o método hasGlyph(String). Você pode determinar quais emojis usam tons de pele lendo a documentação do Unicode.

ICU4J APIs no Android

O Android 7.0 agora oferece um subconjunto de APIs ICU4J no framework do Android no pacote android.icu. A migração é fácil e geralmente envolve simplesmente mudar do namespace com.java.icu para android.icu. Se você já usa um pacote ICU4J nos seus apps, a mudança para as APIs android.icu fornecidas no framework do Android pode produzir uma economia significativa no tamanho do APK.

Para saber mais sobre as APIs ICU4J do Android, consulte Suporte a ICU4J.

WebView

Chrome + WebView, juntos

A partir do Chrome versão 51 no Android 7.0 e versões mais recentes, o APK do Chrome no seu dispositivo é usado para fornecer e renderizar WebViews do sistema Android. Essa abordagem melhora o uso da memória no dispositivo e também reduz a largura de banda necessária para manter o WebView atualizado, já que o APK independente do WebView não será mais atualizado enquanto o Chrome permanecer ativado.

Para escolher seu provedor de WebView, ative as "Opções do desenvolvedor" e selecione Implementação do WebView. Você pode usar qualquer versão compatível do Chrome (Dev, Beta ou Stable) instalada no seu dispositivo ou o APK do Webview independente para atuar como a implementação do WebView.

Multiprocesso

A partir do Chrome versão 51 no Android 7.0, o WebView executará conteúdo da Web em um processo de sandbox separado quando a opção do desenvolvedor "Multiprocess WebView" estiver ativada.

Estamos procurando feedback sobre compatibilidade e desempenho em tempo de execução no N antes de ativar o WebView de vários processos em uma versão futura do Android. Nessa versão, são esperadas regressões no tempo de inicialização, no uso total de memória e no desempenho da renderização do software.

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

JavaScript executado antes do carregamento da página

A partir de apps destinados ao Android 7.0, o contexto do JavaScript será redefinido quando uma nova página for carregada. No momento, o contexto é transferido para a primeira página carregada em uma nova instância da WebView.

Os desenvolvedores que querem injetar JavaScript no WebView precisam executar o script depois que a página começar a carregar.

Geolocalização em origens desprotegidas

A partir de apps destinados ao Android 7.0, a API Geolocation só será permitida em origens seguras (por HTTPS). Esta política foi criada para proteger as informações particulares dos usuários quando eles estiverem usando uma conexão não segura.

Testes com WebView beta

A WebView é atualizada regularmente. Por isso, recomendamos testar com frequência a compatibilidade com seu app usando o Canal Beta da WebView. Para começar a testar versões de pré-lançamento do WebView no Android 7.0, faça o download do Chrome Dev ou do Chrome Beta e instale-o como a implementação do WebView nas opções do desenvolvedor, conforme descrito acima. Informe os problemas usando o rastreador de bugs do Chromium para que possamos corrigi-los antes do lançamento de uma nova versão do WebView.

API OpenGLTM ES 3.2

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ões do 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 do framework para OpenGL ES 3.2 no Android 7.0 é fornecida com a classe GLES32. Ao usar o OpenGL ES 3.2, declare o requisito no arquivo de manifesto usando a tag <uses-feature> e o atributo android:glEsVersion.

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

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, além de gerenciar a interação do usuário com o conteúdo gravado.

Para mais informações, consulte APIs de gravação do Android TV.

Android for Work

O Android for Work adiciona vários recursos e APIs novos para dispositivos com o Android 7.0. Confira alguns destaques abaixo. Para conferir uma lista completa dos recursos, consulte a Lista de recursos do Android Enterprise.

Desafio de segurança de perfil de trabalho

Os proprietários de perfis voltados ao SDK do N podem especificar um desafio de segurança separado para aplicativos em execução no perfil de trabalho. O desafio de trabalho é exibido quando um usuário tenta abrir qualquer app 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 solicita que o usuário defina um bloqueio de dispositivo.

Os proprietários de perfil podem definir políticas de senha diferentes para o desafio de trabalho (por exemplo, quanto tempo o PIN precisa ter ou se uma impressão digital pode ser usada para desbloquear o perfil) usando setPasswordQuality(), setPasswordMinimumLength() e métodos relacionados. O proprietário do perfil também pode definir o bloqueio do dispositivo usando a instância DevicePolicyManager retornada pelo novo método getParentProfileInstance(). Além disso, os proprietários de perfil podem personalizar a tela de credenciais do desafio de trabalho usando 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 apps, a sincronização em segundo plano e as notificações do perfil de trabalho. Isso inclui o aplicativo de proprietário do perfil. Quando o modo de trabalho está desativado, o sistema mostra um ícone de status persistente para lembrar o usuário de que não é possível iniciar apps de trabalho. Ela indica que os apps e widgets de trabalho não podem ser acessados.

Always on VPN

Os proprietários de dispositivos e de perfis podem garantir que os apps de trabalho se conectem sempre por uma VPN especificada. O sistema inicia automaticamente essa 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 o app, os clientes de VPN precisam processar novos pontos de entrada para a VPN sempre ativa. Como antes, os serviços são indicados ao sistema por um filtro de intent correspondente à ação android.net.VpnService.

Os usuários também podem definir manualmente os clientes de VPN sempre ativa que implementam métodos VPNService usando Settings>More>Vpn. A opção para ativar a VPN sempre ativa em "Configurações" estará disponível somente se o cliente VPN for direcionado ao nível 24 da API.

Provisionamento personalizado

Um aplicativo pode personalizar os fluxos de provisionamento do proprietário do perfil e do dispositivo com cores e logotipos 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 as configurações de visão diretamente na tela de boas-vindas para a configuração de novos dispositivos. Isso facilita a descoberta e a configuração dos recursos de acessibilidade nos dispositivos, incluindo gesto de ampliação, tamanho da fonte, tamanho da tela e TalkBack.

Com um posicionamento mais proeminente desses recursos de acessibilidade, os usuários ficam mais propensos a testar o app com eles ativados. Não deixe de testar seus apps antecipadamente com essas configurações ativadas. Você pode ativá-las em Configurações > Acessibilidade.

Ainda no Android 7.0, os serviços de acessibilidade agora podem ajudar usuários com deficiências motoras a tocar na tela. A nova API permite criar serviços com recursos como rastreamento facial, ocular e por ponto, para atender às necessidades desses usuários.

Para saber mais, consulte a documentação de referência para GestureDescription.

Inicialização direta

A inicialização direta melhora os tempos de inicialização do dispositivo e permite que apps registrados tenham funcionalidade limitada, mesmo após uma reinicialização inesperada. Por exemplo, se um dispositivo criptografado for reinicializado enquanto o usuário estiver dormindo, os alarmes registrados, as mensagens e as chamadas recebidas agora poderão continuar notificando o usuário normalmente. Isso também significa que os serviços de acessibilidade também podem estar disponíveis imediatamente após uma reinicialização.

A inicialização direta aproveita a criptografia baseada em arquivos do Android 7.0 para ativar políticas de criptografia detalhadas para dados do sistema e do app. O sistema usa um armazenamento criptografado pelo dispositivo para selecionar dados do sistema e dados do app registrados explicitamente. Por padrão, um armazenamento criptografado por credencial é usado para todos os outros dados do sistema, dados do usuário, apps e dados do app.

Na inicialização, o sistema começa em modo restrito com acesso apenas a dados criptografados pelo dispositivo e sem acesso geral a apps ou dados. Se você quiser executar componentes nesse modo, poderá registrá-los definindo uma sinalização no manifesto. Após a reinicialização, o sistema ativa os componentes registrados transmitindo a intent LOCKED_BOOT_COMPLETED. O sistema garante que dados de apps registrados criptografados pelo dispositivo estejam disponíveis antes do desbloqueio. Todos os outros dados ficarão indisponíveis até que o usuário confirme as credenciais da tela de bloqueio para descriptografá-los.

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

Atestado de chaves

O Android 7.0 introduz o atestado de chaves, uma nova ferramenta de segurança que ajuda a garantir que os pares de chaves armazenados no armazenamento de chaves protegido por hardware de um dispositivo protejam corretamente as informações sensíveis usadas pelo app. Ao usar essa ferramenta, você ganha mais confiança de que seu app vai interagir com chaves que residem em hardware seguro, mesmo que o dispositivo que executa o app tenha acesso root. Se você usa chaves do keystore protegido por hardware nos seus apps, use essa ferramenta, principalmente se usa as chaves para verificar informações sensíveis no app.

A confirmação de chaves permite verificar se um par de chaves RSA ou EC foi criado e armazenado em um keystore protegido por hardware de um dispositivo dentro do ambiente de execução confiável (TEE) do dispositivo. A ferramenta também permite que você use um serviço fora do dispositivo, como o servidor de back-end do app, para determinar e verificar fortemente os usos e a validade do par de chaves. Esses recursos oferecem um nível adicional de segurança que protege o par de chaves, mesmo que alguém aplique acesso root ao dispositivo ou comprometa a segurança da plataforma Android executada nele.

Observação : apenas alguns dispositivos que executam o Android 7.0 oferecem suporte à confirmação de chaves no nível do hardware. Todos os outros dispositivos que executam o 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, confira se o dispositivo é compatível com a 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 se o elemento attestationSecurityLevel na estrutura de dados de descrição da chave está definido como o nível de segurança TrustedEnvironment.

Para mais informações, consulte a documentação do desenvolvedor sobre Atestado de chave.

Configuração de segurança de rede

No Android 7.0, os apps podem personalizar o comportamento de conexões seguras (HTTPS, TLS) com segurança, sem nenhuma modificação de código, usando a Configuração de segurança de rede declarativa em vez de usar as APIs programáticas convencionais propensas a erros (por exemplo, X509TrustManager).

Recursos compatíveis:

  • Âncoras de confiança personalizadas. Permite que um aplicativo personalize quais autoridades de certificação (CA, na sigla em inglês) são confiáveis para as conexões seguras. Por exemplo, confiar em certificados autoassinados particulares ou um conjunto restrito de CAs públicas.
  • Substituições apenas em depuração. Permite que um desenvolvedor de apps depure conexões seguras do aplicativo com segurança, sem adicionar riscos à base instalada.
  • Desativação do tráfego de texto não criptografado. Permite que um aplicativo seja protegido contra o uso acidental de tráfego de texto não criptografado.
  • Fixação de certificados. Um recurso avançado que permite que um aplicativo limite quais chaves de servidor são confiáveis para conexões seguras.

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

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

Por padrão, os apps direcionados ao Android 7.0 confiam apenas em certificados fornecidos pelo sistema e não confiam mais em autoridades de certificação (CA, na sigla em inglês) adicionadas pelo usuário. Os apps destinados ao Android 7.0 (nível 24 da API) que querem confiar em CAs adicionadas pelo usuário precisam usar a Configuração de segurança de rede para especificar como as CAs de usuário são confiáveis.

Esquema de assinatura de APK v2

O Android 7.0 introduz o Esquema de assinatura de APK v2, um novo esquema de assinatura de apps que oferece tempos de instalação mais rápidos e mais proteção contra alterações não autorizadas em arquivos APK. Por padrão, o Android Studio 2.2 e o Plug-in do Android para Gradle 2.2 assinam seu app usando o esquema de assinatura de APK v2 e o esquema de assinatura tradicional, que usa a assinatura JAR.

Embora seja recomendável aplicar o Esquema de assinatura de APK v2 ao seu app, o novo esquema não é obrigatório. Se o app não for criado corretamente ao usar o Esquema de assinatura de APK v2, você poderá desativar o novo esquema. 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 app usando apenas o esquema de assinatura tradicional. Para assinar apenas com o esquema tradicional, abra o arquivo build.gradle do módulo e adicione a linha v2SigningEnabled false à configuração de assinatura de lançamento:

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

Cuidado : se você assinar seu app usando o Esquema de assinatura de APK v2 e fizer outras mudanças no app, a assinatura será invalidada. Por esse motivo, use ferramentas como zipalign antes de assinar seu app usando o Esquema de assinatura de APK v2, não depois.

Para saber mais, leia os documentos do Android Studio que descrevem como assinar um app no Android Studio e como configurar o arquivo de build para assinar apps usando o plug-in do Android para Gradle.

Acesso a diretórios com escopo

No Android 7.0, os apps podem usar novas APIs para solicitar acesso a diretórios de armazenamento externo específicos, incluindo diretórios em mídia removível, 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. Apps como apps de fotos podem usar essas APIs em vez de READ_EXTERNAL_STORAGE, que concede acesso a todos os diretórios de armazenamento, ou ao framework de acesso ao armazenamento, que faz o usuário navegar até o diretório.

Além disso, as novas APIs simplificam as etapas que um usuário segue para conceder acesso ao armazenamento externo ao app. Quando você usa as novas APIs, o sistema usa uma interface de permissões simples que detalha claramente a qual diretório o aplicativo está solicitando acesso.

Para mais informações, consulte a documentação do desenvolvedor Acesso a diretório com escopo.

Auxiliar de atalhos do teclado

No Android 7.0, o usuário pode pressionar Meta + / para acionar uma tela Keyboard Shortcuts que mostra todos os atalhos disponíveis do sistema e do app em foco. O sistema recupera esses atalhos automaticamente do menu do app, se houver. Você também pode fornecer suas próprias listas de atalhos ajustados para a tela. Para isso, substitua o método onProvideKeyboardShortcuts().

Observação:a tecla Meta não está presente em todos os teclados: em um teclado Macintosh, é a tecla Command, no teclado do Windows, é a tecla Windows e, no Pixel C e nos teclados do ChromeOS, é a tecla Pesquisa.

Para acionar o auxiliar de atalhos de teclado em qualquer lugar do app, chame requestShowKeyboardShortcuts() na atividade relevante.

Custom Pointer API

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

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

Sustained Performance API

O desempenho pode variar drasticamente em apps executados por muito tempo, porque o sistema limita os mecanismos de sistema em chip quando os componentes do dispositivo atingem o limite de temperatura. Essa flutuação apresenta um alvo móvel para desenvolvedores de aplicativos que criam aplicativos de alto desempenho e longa duração.

Para resolver essas limitações, o Android 7.0 inclui suporte ao modo de desempenho sustentado, permitindo que os OEMs forneçam dicas sobre os recursos de desempenho do dispositivo para apps de longa duração. Os desenvolvedores podem usar essas dicas para ajustar os apps para um nível de desempenho do dispositivo previsível e consistente em longos períodos.

Os desenvolvedores de apps podem testar essa nova API no Android 7.0 somente em dispositivos Nexus 6P. Para usar esse recurso, defina a sinalização da janela de desempenho sustentado para a janela que você quer executar no modo de desempenho sustentado. Defina essa sinalização usando o método Window.setSustainedPerformanceMode(). O sistema desativa esse modo automaticamente quando a janela não está mais em foco.

Compatibilidade com RV

O Android 7.0 adiciona suporte de plataforma e otimizações para um novo Modo de RV que permite aos desenvolvedores criar experiências de RV para dispositivos móveis de alta qualidade para os usuários. Há várias melhorias de desempenho, incluindo o acesso a um núcleo da CPU exclusivo para apps de RV. Dentro dos seus apps, você pode aproveitar o rastreamento inteligente da cabeça e as notificações estéreo que funcionam para RV. O mais importante é que o Android 7.0 oferece gráficos de latência muito baixa. Para ver informações completas sobre a criação de apps de RV para o Android 7.0, consulte SDK de RV do Google para Android.

No Android 7.0, os desenvolvedores de serviços de impressão agora podem exibir mais informações 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:

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

Você pode indicar o progresso e o status dos trabalhos de impressão na notificação deles chamando setProgress() e setStatus(), respectivamente.

API Frame Metrics

A API Frame Metrics permite que um app monitore o desempenho de renderização da interface. A API fornece esse recurso expondo uma API de streaming do Pub/Sub para transferir informações de marcação de tempo de frame para a janela atual do app. Os dados retornados são equivalentes aos que adb shell dumpsys gfxinfo framestats exibe, mas não se limitam aos últimos 120 frames.

É possível usar a API Frame Metrics para medir o desempenho da interface no nível da interação na produção sem uma conexão USB. Essa API permite a coleta de dados com uma granularidade muito maior do que adb shell dumpsys gfxinfo. Essa granularidade maior é possível porque o sistema pode coletar dados de interações específicas no app. Ele não precisa capturar um resumo global do desempenho do app nem limpar qualquer estado global. É possível usar esse recurso para coletar dados de desempenho e capturar regressões no desempenho da interface para casos de uso reais em um app.

Para monitorar uma janela, implemente o método de callback OnFrameMetricsAvailableListener.onFrameMetricsAvailable() e o registre nessa janela.

A API fornece um objeto FrameMetrics, que contém dados de tempo que o subsistema de renderização informa para vários marcos no ciclo de vida de um frame. 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

Nas versões anteriores do Android, seu app podia usar o framework de acesso ao armazenamento para permitir que os usuários selecionem arquivos de contas de armazenamento em nuvem, como o Google Drive. No entanto, não havia como representar arquivos que não tivessem uma representação direta de bytecode. Cada arquivo precisava fornecer um stream de entrada.

O Android 7.0 adiciona o conceito de arquivos virtuais ao Framework de acesso ao armazenamento. O recurso de arquivos virtuais permite que DocumentsProvider retorne URIs de documentos que podem ser usados com uma intent ACTION_VIEW, mesmo que não tenham uma representação direta de bytecode. O Android 7.0 também permite oferecer formatos alternativos para arquivos de usuário, virtuais ou não.

Para mais informações sobre como abrir arquivos virtuais, consulte Abrir arquivos virtuais no guia do Frameworks de acesso ao armazenamento.