O Android 7.0 Nougat introduz vários 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 na plataforma podem afetar seus apps.
Para saber mais sobre os recursos do Android 7.0 para os usuários, acesse www.android.com.
Suporte a várias janelas
No Android 7.0, apresentamos um novo e muito solicitado recurso de multitarefas 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 se colocar no modo picture-in-picture, o que permite que continuem mostrando conteúdo enquanto o usuário navega ou interage com outros apps.
![Apps para dispositivos móveis em execução no modo de tela dividida](https://developer.android.com/static/images/android-7.0/mw-portrait.png?authuser=6&hl=pt)
Figura 1. Apps em execução no modo de tela dividida.
O suporte a várias janelas oferece novas maneiras de engajar 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 de ou para o app. Essa é uma ótima maneira de melhorar a experiência do usuário.
É simples adicionar suporte a várias janelas ao seu app e configurar como ele lida com 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 redimensionem a atividade abaixo desse tamanho. Você também pode desativar a exibição em várias janelas para o app, o que garante que o sistema o mostre somente no 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
. Você pode 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. O usuário pode executar ações, como Dispensar ou Arquivar, nesses itens. Se você já implementou notificações para o Android Wear, conhece esse modelo.
- Resposta direta: para apps de comunicação em tempo real, o sistema Android é compatível com respostas inline para que os usuários possam responder rapidamente a um SMS ou uma mensagem de texto diretamente na interface de notificações.
- 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](https://developer.android.com/static/images/android-7.0/notifications-1.png?authuser=6&hl=pt)
![Dispositivo móvel exibindo notificação de mensagem única](https://developer.android.com/static/images/android-7.0/notifications-3.png?authuser=6&hl=pt)
![Dispositivo móvel exibindo resposta de mensagem inline na interface de notificação](https://developer.android.com/static/images/android-7.0/notifications-2.png?authuser=6&hl=pt)
Figura 2. Notificações agrupadas 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 ART, que permite melhorar constantemente o desempenho de apps Android conforme eles são executados. O compilador JIT complementa o compilador atual Ahead of Time (AOT, na sigla em inglês) 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 do app e pode pré-compilar e armazenar em cache esses métodos para ter o 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 ajudada a reduzir o consumo geral 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 desse trabalho.
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 apenas uma questão de segundos. As atualizações do sistema também são mais rápidas, já que 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 de apps quando o dispositivo está inativo, como quando ele 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 fica desligada por um período e o dispositivo é desconectado, o modo Soneca aplica um subconjunto das restrições conhecidas de CPU e rede a 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](https://developer.android.com/static/images/android-7.0/doze-diagram-1.png?authuser=6&hl=pt)
Figura 3. O modo 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 é desativada enquanto o dispositivo está usando a bateria, o modo Soneca restringe o acesso à rede e adia trabalhos 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 à bateria por um
período, o modo soneca vai aplicar todas as restrições de CPU e rede aos alarmes PowerManager.WakeLock
, AlarmManager
e
verificações de GPS/Wi-Fi.
As práticas recomendadas para adaptar o app ao modo Soneca são as mesmas, independentemente de o dispositivo estar em movimento ou não. Portanto, se você já atualizou o app para processar o modo 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 por 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 corretamente, ele pode tornar a experiência do usuário incrível: imediata, rápida e sensível ao 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 executar trabalhos em segundo plano de maneira benéfica
para os usuários. Os apps podem agendar jobs e permitir que o sistema otimize com base nas
condições de memória, energia e conectividade. O JobScheduler oferece controle e simplicidade, e queremos que todos os apps o usem.
Outra boa opção é o
GCMNetworkManager
, parte do Google Play Services, que
oferece programação de jobs semelhante com compatibilidade entre versões legadas do
Android.
Continuamos estendendo JobScheduler
e
GCMNetworkManager
para atender a mais
casos de uso. Por exemplo, no Android 7.0, agora é possível programar trabalhos em segundo plano
com base nas mudanças nos provedores de conteúdo. Ao mesmo tempo, começamos a
descontinuar alguns dos padrões mais antigos, que podem reduzir o desempenho do sistema,
especialmente em dispositivos com pouca memória.
Vamos remover três transmissões implícitas usadas com frequência no Android 7.0,
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 sobrecarregar a memória e a bateria. Se
seu app estiver recebendo esses dados, aproveite o Android 7.0 para
migrar para o JobScheduler
e APIs relacionadas.
Consulte a documentação Otimizações em segundo plano para ver mais detalhes.
SurfaceView
O Android 7.0 traz movimento síncrono para a classe SurfaceView
, que oferece melhor desempenho de bateria
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
.
SurfaceView
permite composições mais eficientes em
bateria na tela, já que ela é composta em hardware dedicado, separadamente 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 uma SurfaceView
não produzem mais barras pretas ao lado da visualização conforme 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](https://developer.android.com/static/images/android-7.0/datasaver.png?authuser=6&hl=pt)
Figura 4. Economia de dados nas Configurações.
Normalmente, o custo do plano de dados móveis ao longo da vida útil de um dispositivo móvel excede o custo do próprio dispositivo. Para muitos usuários, os dados móveis são um recurso caro que querem economizar.
O Android 7.0 introduz o modo Economia de dados, um novo serviço do sistema que ajuda a reduzir o uso de dados da rede celular pelos apps, seja em roaming, perto do final do ciclo de faturamento ou em um pacote de dados pré-pago pequeno. A Economia de dados oferece aos usuários controle sobre como os apps usam dados móveis e permite que os desenvolvedores ofereçam serviços mais eficientes quando a Economia de dados está ativada.
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 que usem 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 o ConnectivityManager
para oferecer aos apps uma
maneira de recuperar as
preferências do usuário para a Economia de dados 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 o 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 mantidos 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 possibilita melhor paralelização, permitindo que várias linhas de execução realizem trabalhos como a construção do buffer de comando de uma só vez.
As ferramentas e bibliotecas de desenvolvimento 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](https://developer.android.com/static/images/android-7.0/quicksettings.png?authuser=6&hl=pt)
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, ampliamos o escopo das Configurações rápidas para torná-las ainda mais úteis e convenientes.
Adicionamos mais espaço para outros 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 aos usuários controlar quais blocos de Configurações rápidas aparecem e onde eles são mostrados. Para adicionar ou mover blocos, basta arrastá-los e soltá-los.
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 seu app.
Os blocos das Configurações rápidas estão reservados para controles ou ações que são urgentes ou usados com frequência. Eles não devem ser usados como atalhos para a inicialização de um app.
Depois de definir seus blocos, é possível mostrá-los aos 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
para 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 na 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 maneira consistente de apps oferecer suporte ao 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 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, com a integração do app da operadora pelo Android, as operadoras podem ler a lista de números bloqueados no dispositivo e realizar um bloqueio do lado do serviço para o usuário, impedindo que chamadas e textos indesejados cheguem até ele por qualquer meio, como um endpoint de VoIP ou encaminhamento de telefones.
Para mais informações, 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 o app execute várias ações com base no
Call.Details
de uma 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 mais informações, 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 conhecer as localidades selecionadas pelo usuário e oferecer experiências mais sofisticadas para usuários de várias localidades. Por exemplo, mostrar resultados da pesquisa em vários idiomas e não oferecer a tradução de páginas da Web em idiomas que o usuário já conhece.
Junto com o suporte a várias localidades, o Android 7.0 também expande 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. Ela 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 como resolve 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 a vários idiomas.
Novos emoticons
O Android 7.0 apresenta emojis adicionais e recursos relacionados, incluindo emojis com tons de pele e suporte a seletores de variação. Se seu app é compatível com emojis, siga as diretrizes abaixo para aproveitar esses recursos relacionados a emojis.
-
Verifique se o dispositivo contém um emoji antes de inserir.
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 que você apresente 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 com o 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 (em inglês) da documentação Unicode sobre variações.
-
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 o tom que preferirem. 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
uma simples mudança 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 gerar 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 da versão 51 do Chrome 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 de memória no dispositivo e também reduz a largura de banda necessária para manter a WebView atualizada, já que o APK independente da WebView não será mais atualizado enquanto o Chrome permanecer ativado.
Você pode escolher seu provedor de WebView ativando as Opções do desenvolvedor e selecionando Implementação de WebView. Você pode usar qualquer versão compatível do Chrome (Dev, Beta ou Stable) instalada no seu dispositivo ou o APK independente do WebView para atuar como implementação do WebView.
Multiprocesso
A partir da versão 51 do Chrome no Android 7.0, a WebView executará conteúdo da Web em um processo de sandbox separado quando a opção de desenvolvedor "Multiprocess WebView" estiver ativada.
Estamos procurando feedback sobre compatibilidade e desempenho do tempo de execução no N antes de ativar o WebView multiprocesso 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 de 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. Atualmente, 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ça a ser carregada.
Geolocalização em origens desprotegidas
A partir de apps destinados ao Android 7.0, a API de geolocalização só será permitida em origens seguras (por HTTPS). Essa política tem como objetivo proteger as informações privadas dos usuários quando eles usarem uma conexão sem segurança.
Testes com WebView beta
A WebView é atualizada regularmente. Por isso, recomendamos que você teste a compatibilidade com seu app com frequência 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 e instale o Chrome Dev ou Beta e selecione-o como a implementação de WebView em "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 da 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 de 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, incluindo como verificar a versão compatível do OpenGL ES de um dispositivo no momento da 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. Com base nas APIs de time-shifting, os serviços de entrada de TV podem controlar quais dados de canal são gravados, como as sessões gravadas são salvas e gerenciar a interação do usuário com o conteúdo gravado.
Para mais informações, consulte APIs Recording 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 de recursos, consulte Lista de recursos do Android Enterprise.
Desafio de segurança de perfil de trabalho
Os proprietários de perfis voltados para o SDK N
podem especificar um desafio de segurança separado para apps em execução no
perfil de trabalho. O desafio de trabalho é exibido quando um usuário tenta abrir
qualquer app de trabalho. A conclusão bem-sucedida do desafio de segurança desbloqueia e, se necessário, descriptografa o
perfil de trabalho. Para proprietários de perfis,
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 perfis podem definir políticas de senha diferentes para o desafio de trabalho
(como 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 perfis 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 do 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. A tela de início indica que os apps e widgets de trabalho não podem ser acessados.
Always on VPN
Os proprietários de dispositivos e perfis podem garantir que os apps de trabalho sempre se conectem 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
apps, 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 ativada 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 à API de nível 24.
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 Configurações de visão diretamente na tela de boas-vindas para configuração de novos dispositivos. Isso facilita muito a descoberta e a configuração de recursos de acessibilidade nos dispositivos, incluindo gesto de ampliação, tamanho da fonte, tamanho da tela e TalkBack.
Com esses recursos de acessibilidade ficando mais proeminentes, seus usuários ficam mais propensos a testar o app com eles ativados. Teste 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, de olhos e de pontos, entre outros, para atender às necessidades desses usuários.
Para mais informações, 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 em suspensão, alarmes registrados, mensagens e 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 a 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 de apps 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 inicia em um modo restrito com acesso
apenas a dados criptografados do dispositivo e sem acesso geral a apps ou dados.
Se quiser executar componentes nesse modo, você pode 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 os 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.
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 em um armazenamento de chaves protegido por hardware 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 armazenadas 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, precisa utilizar essa ferramenta, principalmente se for usar as chaves para verificar informações sensíveis no seu 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 no ambiente de execução confiável (TEE) do dispositivo. A ferramenta também permite usar 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 mais um nível de segurança que protege o par de chaves, mesmo se alguém acessar acesso root ao dispositivo ou comprometer a segurança da plataforma Android em execução nele.
Observação : apenas um pequeno número de dispositivos com o Android 7.0
oferece suporte à confirmação de chaves no nível do hardware. Todos os outros dispositivos com o Android 7.0
usam a confirmação de chaves no nível do software. Antes de verificar as propriedades
das chaves protegidas por hardware de um dispositivo em um ambiente de produção, confira
se o dispositivo tem suporte ao atestado de chaves no nível do hardware. Para
isso, verifique se a cadeia de certificados de atestado contém um certificado
raiz assinado pela chave raiz de atestado do Google e se o
elemento attestationSecurityLevel
na estrutura de dados de descrição
de chaves está definido para o nível de segurança TrustedEnvironment.
Para mais informações, consulte a documentação do desenvolvedor sobre Atestado de chaves.
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 no 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 certificadoras (CA) são confiáveis para as conexões seguras. Por exemplo, confiar em certificados autoassinados particulares ou em um conjunto restrito de ACs públicas.
- Substituições somente em depuração. Permite que um desenvolvedor 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 certificadoras (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 ACs adicionadas pelo usuário precisam usar a Configuração de segurança de rede para especificar como as CAs do usuário são confiáveis.
Esquema de assinatura de APK v2
O Android 7.0 introduz o Esquema de assinatura do APK v2, um novo esquema de assinatura de apps que oferece instalações mais rápidas 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 do APK v2 e o esquema de assinatura tradicional, que usa a assinatura JAR.
Embora seja recomendado aplicar o Esquema de assinatura de APK v2 ao seu app, esse 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 da
versão:
android { ... defaultConfig { ... } signingConfigs { release { storeFile file("myreleasekey.keystore") storePassword "password" keyAlias "MyReleaseKey" keyPassword "password" v2SigningEnabled false } } }
Cuidado : se você assinar o 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 o app com 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 assinatura de 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 muito a forma como seu aplicativo acessa 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 seu 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 para desenvolvedores sobre 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
no sistema e no app em foco. O sistema recuperará 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 fazer
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 de 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 o usuário está usando um mouse ou touchpad para interagir com objetos de 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 de longa duração, porque o sistema limita os mecanismos de sistema em chip quando os componentes do dispositivo atingem o limite de temperatura. Essa flutuação representa um desafio para desenvolvedores que criam apps de alto desempenho e longa duração.
Para solucionar essas limitações, o Android 7.0 inclui suporte ao modo de desempenho sustentado, permitindo que OEMs ofereçam dicas sobre recursos de desempenho de dispositivos 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 durante longos períodos.
Os desenvolvedores de aplicativos podem testar essa nova API no Android 7.0 somente em dispositivos Nexus 6P. Para usar esse recurso, defina a sinalização de janela de desempenho sustentado para a janela que você quer executar no modo de desempenho sustentado. Defina essa flag 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 à plataforma e otimizações para um novo Modo RV, permitindo que os desenvolvedores criem experiências de RV de alta qualidade em dispositivos móveis para os usuários. Há várias melhorias de desempenho, incluindo o acesso a um núcleo exclusivo da CPU 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. Mais importante, 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 o SDK de RV do Google para Android.
Melhorias nos serviços de impressão
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:
- É possível definir um ícone de um ID de recurso chamando
setIconResourceId()
. - Você pode mostrar um ícone da rede chamando
setHasCustomPrinterIcon()
e definindo um callback para quando o ícone for solicitado usandoonRequestCustomPrinterIcon()
.
Além disso, você pode fornecer uma atividade por impressora para exibir mais
informações chamando setInfoIntent()
.
Para indicar o progresso e o status dos trabalhos de impressão na notificação, chame 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 Pub/Sub de streaming para transferir informações 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 IU
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 maior granularidade é possível porque
o sistema pode coletar dados para interações específicas no app. O sistema
não precisa capturar um resumo global do desempenho do app
nem limpar nenhum estado global. Use 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 selecionassem 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 possam 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ários, virtuais ou não.
Para mais informações sobre como abrir arquivos virtuais, consulte Abrir arquivos virtuais no guia de frameworks de acesso ao armazenamento.