Android 7.0 para desenvolvedores

O Android 7.0 Nougat apresenta uma variedade de novos recursos e funcionalidades 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 saber mais sobre as áreas em que a plataforma muda podem afetar seus apps.

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

Suporte a várias janelas

No Android 7.0, estamos lançando um multitarefa na plataforma — suporte a 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 aplicativos lado a lado ou uma sobre a outra no modo de tela dividida. Os usuários podem redimensionar os aplicativos arrastando o divisor entre elas.
• Em dispositivos Android TV, os apps podem aparecer no modo picture-in-picture modo, permitindo que eles continuem a mostrar conteúdo enquanto o usuário navega ou interage com outros apps.

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

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

É muito fácil adicionar suporte a várias janelas ao seu app e configurar como ele lida com a exibição em várias janelas. Por exemplo, é possível especificar o tipo dimensões mínimas permitidas, 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 só exiba o aplicativo no modo de tela cheia.

Para mais informações, consulte Suporte a várias janelas na documentação do desenvolvedor.

Melhorias às notificações

Reformulamos as notificações no Android 7.0 para facilitar mais rápidos de usar. Entre as alterações, temos:

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

Figura 2. Pacote de notificações e resposta direta.

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

Compilação JIT/AOT orientada a perfil

No Android 7.0, adicionamos um compilador Just in Time (JIT) com código de acordo com o ART, o que permite melhorar constantemente o desempenho de Apps Android conforme são executados. O compilador JIT complementa o Compilador Ahead of Time (AOT) e ajuda a melhorar o desempenho de execução, economizar espaço de armazenamento e acelerar as atualizações de apps e do sistema.

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

Além de melhorar o desempenho para as principais partes do app, as campanhas ajuda a reduzir o consumo geral de RAM de um aplicativo, incluindo binários. 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 sobre o bateria do dispositivo. Ela faz a pré-compilação somente quando o dispositivo está inativo carregando, economizando tempo e bateria fazendo essa tarefa com antecedência.

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

Um dos benefícios mais tangíveis do compilador JIT do ART é a velocidade dos recursos e atualizações do sistema. Até mesmo apps grandes, que exigiam vários minutos para Otimizar e instalar no Android 6.0 agora podem ser instalados em 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 a apps Atividades de CPU e rede quando o dispositivo está inativo, como 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 apagada por um período e o dispositivo estiver 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 na bolsos.

Figura 3. O modo Soneca agora é ativado restrições para aumentar a duração da bateria mesmo quando o dispositivo não estiver parado.

Pouco tempo após a tela ser desativada enquanto o dispositivo está conectado à bateria, o modo Soneca restringe o acesso à rede e adia trabalhos e sincronizações. Durante uma breve manutenção os aplicativos têm permissão para acessar a rede e qualquer um dos jobs/sincronizações são executados. Ligar a tela ou conectar o dispositivo o dispositivo para sair do modo Soneca.

Quando o dispositivo ficar parado novamente, com a tela desligada e ligada à bateria por um tempo período, o modo Soneca aplica todas as restrições de CPU e rede ao PowerManager.WakeLock, aos alarmes AlarmManager e Buscas por GPS/Wi-Fi.

As práticas recomendadas para adaptar seu aplicativo à Soneca são as mesmas, independentemente de o dispositivo está se movendo ou não. Por isso, se você já atualizou o aplicativo para lidar com o Soneca, está tudo pronto. Caso contrário, comece a adaptar seu app para o modo Soneca.

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 no ecossistema. No Android 7.0, o Project O Svelte está focado em otimizar a forma de execução dos apps em segundo plano.

O processamento em segundo plano é parte essencial da maioria dos aplicativos. Quando tratado corretamente, podem tornar a experiência do usuário incrível: imediata, rápida e contextual. Quando não é executado corretamente, o processamento em segundo plano pode consumir RAM desnecessariamente (e bateria) e afetam o desempenho do sistema para outros apps.

Desde o Android 5.0, JobScheduler é o maneira preferida de realizar o trabalho em segundo plano de uma maneira que seja boa aos usuários. Os aplicativos podem agendar tarefas e permitir que o sistema otimize com base em de memória, energia e conectividade. O JobScheduler oferece controle e simplicidade, e queremos que todos os aplicativos a usem.

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

Continuamos estendendo o JobScheduler e GCMNetworkManager para conhecer mais seus casos de uso. Por exemplo, no Android 7.0, agora é possível programar em segundo plano funcionam com base nas mudanças dos provedores de conteúdo. Ao mesmo tempo, estamos começando a descontinuam 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 usadas com frequência — CONNECTIVITY_ACTION, ACTION_NEW_PICTURE e ACTION_NEW_VIDEO, já que eles podem ativar o processos em segundo plano de vários apps de uma só vez e sobrecarregar a memória e a bateria. Se seu aplicativo estiver recebendo esses, aproveite o Android 7.0 para migram para JobScheduler e APIs relacionadas.

Dê uma olhada no Plano de fundo Documentação sobre otimizações para mais detalhes.

SurfaceView

O Android 7.0 traz movimento síncrono para a SurfaceView. classe, o que melhora o desempenho da bateria do que TextureView em certos casos: ao renderizar vídeos ou Conteúdo 3D, aplicativos com rolagem e posição de vídeo animado usam menos energia com SurfaceView do que com TextureView.

A classe SurfaceView permite uma composição mais econômica em porque ele é composto por hardware dedicado, separado do hardware o conteúdo da janela. Como resultado, ele torna menos intermediários cópias de TextureView.

A posição do conteúdo de um objeto SurfaceView agora é atualizada de forma síncrona. com o conteúdo do aplicativo. Um resultado dessa mudança é que a simplicidade traduções ou escalas de um vídeo em exibição em uma SurfaceView não produz 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

Figura 4. Economia de dados nas 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 uma recurso caro que querem economizar.

O Android 7.0 apresenta o modo de Economia de dados, um novo serviço do sistema que ajuda a reduzir uso de dados móveis por apps, seja em roaming, perto do fim do ciclo de faturamento ou em um pequeno pacote de dados pré-pago. A Economia de dados permite que os usuários controlem como os apps usam dados móveis e permite que os desenvolvedores forneçam serviços mais eficientes quando dados A Economia está ativada.

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

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

Vulkan API

O Android 7.0 integra à plataforma o VulkanTM, uma nova API de renderização 3D. Gostei OpenGLTM ES, o Vulkan é um padrão aberto para gráficos 3D e renderização mantida pelo Grupo Khronos.

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. Vulkan. também possibilita um melhor carregamento em paralelo, permitindo que várias linhas de execução executem como a construção do buffer de comando de uma só vez.

Ferramentas de desenvolvimento e bibliotecas do Vulkan são integradas ao SDK do Android 7.0. Eles 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 aplicativos 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 levar o Vulkan para mais dispositivos o mais rápido possível.

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

Quick Settings Tile API

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

As Configurações rápidas são uma forma simples e conhecida de expor as principais configurações e ações, diretamente da aba de notificações. No Android 7.0, aumentamos o escopo Configurações rápidas para torná-la ainda mais útil e conveniente.

Adicionamos mais espaço para blocos adicionais de Configurações rápidas, que os usuários podem acessar em uma área de exibição paginada deslizando para a esquerda ou direita. Nós também permite que os usuários controlem quais blocos das Configurações rápidas aparecem e onde estão exibidos — os usuários podem adicionar ou mover blocos arrastando e soltando-os.

Para desenvolvedores, o Android 7.0 também adiciona uma nova API que permite definir as próprias Blocos de Configurações rápidas para facilitar o acesso dos usuários aos principais controles e ações do app.

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

Depois de definir seus blocos, você pode mostrá-los aos usuários, que podem adicionar até as Configurações rápidas arrastando e soltando.

Para informações sobre como criar um bloco de apps, 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 oferece uma Framework para permitir que os provedores de serviços mantenham uma lista de números bloqueados. A 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 tornar o bloqueio de números um recurso padrão da plataforma, o Android oferece uma maneira consistente de oferecer suporte ao bloqueio de números em uma ampla gama 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 os dispositivos com o recurso Restaurar recurso
• Vários aplicativos podem usar a mesma lista de números bloqueados

Além disso, a integração do app da operadora pelo Android significa que 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 até ele por qualquer meio, como endpoint VOIP ou telefones de encaminhamento.

Para obter 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 smartphone app faz isso implementando o novo CallScreeningService, que permite que o app do smartphone execute uma série de ações com base em 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 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 em "Configurações", para oferecer melhor suporte a casos de uso bilíngues. Os apps podem usar uma nova API para obter as localidades selecionadas pelo usuário e oferecer recursos experiências do usuário 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á conhece.

Junto com o suporte a várias localidades, o Android 7.0 também amplia o número de idiomas disponíveis para os usuários. Ele oferece mais de 25 variantes para cada uma das opções idiomas como inglês, espanhol, francês e árabe. Ele também adiciona suporte 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 é mudando a forma de resolver recursos. Não deixe de testar e verificar se seus apps funcionando 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ê deve seguir, consulte Suporte multilíngue.

Novos emoticons

O Android 7.0 introduz emojis adicionais e recursos relacionados a emojis, incluindo: emojis em tons de pele e compatibilidade com variações seletores. Se o app é compatível com emojis, siga as diretrizes abaixo para aproveitar esses recursos relacionados a emojis.

• Verifique se o dispositivo tem um emoji antes de inserir. Para verificar quais emojis estão presentes no fonte do sistema, use o método hasGlyph(String).
• Verifique se um emoji é compatível com seletores de variação. Com os seletores de variação, você pode alguns emojis coloridos ou em 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 seu aplicativo exibe emojis alinhados com o 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 uma lista completa de caracteres com variações, consulte o seção de sequências de variação de emojis do Documentação de Unicode sobre variações.
• Confira se um emoji aceita tons de pele. O Android 7.0 permite que os usuários modifiquem a tom de pele renderizado dos emojis de acordo com sua preferência. Os aplicativos de teclado precisam oferecer recursos indicações de emojis que têm diversos tons de pele e devem permitir que os usuários selecionar o tom de pele que preferem. Para determinar quais emojis do sistema têm modificadores de tom de pele, use hasGlyph(String). . Você pode determinar quais emojis usam tons de pele lendo os Documentação do Unicode (link em inglês).

ICU4J APIs no Android

O Android 7.0 agora oferece um subconjunto de APIs ICU4J no framework do Android na o pacote android.icu. A migração é fácil e envolve principalmente basta mudar do namespace com.java.icu para android.icu. Se você já usa um pacote ICU4J no seu apps, alternando para as APIs android.icu fornecidas na instalação pode gerar economias significativas no tamanho do APK.

Para saber mais sobre as APIs ICU4J do Android, consulte Suporte ao 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 a memória uso no próprio dispositivo e também reduz a largura de banda necessária para manter WebView atualizado, já que o APK do WebView independente não será mais atualizado enquanto o Chrome permanecer ativado).

Para escolher seu provedor de WebView, ative "Opções do desenvolvedor" e Selecione Implementação do WebView. Você pode usar qualquer A versão do Google Chrome (Dev, Beta ou Stable) instalada no seu dispositivo ou a APK autônomo do WebView para atuar como 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 em sandbox separado quando a opção de desenvolvedor "Multiprocess WebView" está ativado.

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

Se você encontrar problemas inesperados no modo multiprocesso, gostaríamos de saber mais a respeito. para resolvê-los com rapidez. Entre em contato com a equipe do WebView no rastreador de bugs do Chromium.

JavaScript executado antes do carregamento da página

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

Os desenvolvedores que quiserem injetar JavaScript no WebView devem executar o depois que a página começar a carregar.

Geolocalização em origens desprotegidas

A partir dos aplicativos destinados ao Android 7.0, a API de geolocalização será permitido em origens seguras (sobre HTTPS). Essa política tem como objetivo proteger informações privadas dos usuários quando eles estiverem usando uma conexão sem segurança.

Testes com WebView beta

O WebView é atualizado regularmente, por isso recomendamos testar 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 Chrome Dev ou Chrome Beta e selecione-o como a implementação de WebView em opções do desenvolvedor, conforme descrito acima. Informe problemas no Chromium rastreador de bugs para que possamos corrigi-los antes que uma nova versão do WebView seja lançada. lançado.

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 Android Extension Pack (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 com o GLES32. Ao usar o OpenGL ES 3.2, não se esqueça de declarar a requisito no seu 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 o comportamento compatível com o OpenGL ES no momento da execução, consulte o guia da API do OpenGL ES.

Gravação do Android TV

O Android 7.0 adiciona a capacidade de gravar e reproduzir conteúdo da entrada do Android TV serviços com as novas APIs de gravação. Criação com base em time-shifting atual As APIs, os serviços de entrada de TV podem controlar quais dados de canais podem ser gravados, sessões gravadas são salvas e gerenciam a interação do usuário com o conteúdo gravado.

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

Android for Work

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

Desafio de segurança de perfil de trabalho

Proprietários de perfis que segmentam o SDK N é possível especificar um desafio de segurança separado para aplicativos em execução no o perfil de trabalho. O desafio de trabalho aparece quando um usuário tenta abrir para qualquer app de trabalho. A conclusão bem-sucedida do desafio de segurança desbloqueia e o descriptografa, se necessário. Para os proprietários de perfis, ACTION_SET_NEW_PASSWORD solicita que o usuário defina um trabalho desafio e ACTION_SET_NEW_PARENT_PROFILE_PASSWORD comandos que o usuário defina um bloqueio para o dispositivo.

Os proprietários de perfis podem definir políticas de senha distintas para o desafio de trabalho (por exemplo, qual o tamanho do PIN ou se uma impressão digital pode ser usada) para desbloquear o perfil) usando o setPasswordQuality(), setPasswordMinimumLength() e métodos relacionados. O perfil O proprietário também pode definir o bloqueio do dispositivo usando o 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 as novas setOrganizationColor() e setOrganizationName().

Desativar perfil de trabalho

Os usuários podem alternar o modo de trabalho em dispositivos com um perfil de trabalho. Quando o modo de trabalho for o usuário gerenciado é encerrado temporariamente, o que desativa o perfil de trabalho apps, sincronização em segundo plano e notificações. Isso inclui o proprietário do perfil para o aplicativo. Quando o modo de trabalho está desativado, o sistema mostra um status persistente para lembrar o usuário de que não é possível iniciar apps de trabalho. O acesso rápido indica que aplicativos 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 se conectem sempre. por uma VPN específica. O sistema inicia automaticamente a VPN após a inicializações 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 um app os clientes VPN precisam lidar com novos pontos de entrada para a VPN sempre ativa. Conforme 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 clientes VPN sempre ativa que implementam VPNService de métodos usando Configurações > Mais > VPN. A opção de ativar a VPN sempre ativa em "Configurações" estará disponível apenas se o cliente VPN segmentar o nível 24 da API.

Provisionamento personalizado

Um aplicativo pode personalizar o provisionamento do proprietário do perfil e do proprietário do dispositivo com cores e logotipos corporativos. DevicePolicyManager.EXTRA_PROVISIONING_MAIN_COLOR personaliza 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 novos configuração do dispositivo. Isso torna muito mais fácil para os usuários descobrir e configurar recursos de acessibilidade nos dispositivos, incluindo gesto de ampliação, fonte tamanho da tela, tamanho da tela e TalkBack.

Com o posicionamento mais proeminente desses recursos de acessibilidade, os usuários têm mais chances de testar seu app com eles ativados. Não deixe de testar seus apps cedo com essas configurações ativadas. Eles podem ser ativados em Configurações > Acessibilidade.

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

Para obter mais informações, consulte a documentação de referência para GestureDescription:

Inicialização direta

A inicialização direta melhora o tempo de inicialização do dispositivo e permite que registros os apps têm funcionalidade limitada, mesmo após uma reinicialização inesperada. Por exemplo, se um dispositivo criptografado é reinicializado enquanto o usuário está em suspensão, Alarmes registrados, mensagens e chamadas recebidas agora podem continuar a notificar o usuário normalmente. Isso também significa que os serviços de acessibilidade também podem ser imediatamente após a reinicialização.

A inicialização direta aproveita a criptografia baseada em arquivos no 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 explicitamente dados de apps registrados. Por padrão, um armazenamento criptografado por credencial é usado para todos outros dados do sistema, dados do usuário, apps e dados de apps.

Na inicialização, o sistema abre em um modo restrito com acesso a somente dados criptografados do dispositivo e sem acesso geral a apps ou dados. Se quiser executar componentes nesse modo, você pode registrar definindo uma flag no manifesto. Após a reinicialização, o sistema é ativado componentes registrados transmitindo o LOCKED_BOOT_COMPLETED intenção. O sistema garante que os dados de apps registrados criptografados pelo dispositivo estejam disponíveis antes do desbloqueio. Todos os outros dados ficam indisponíveis até que o usuário confirme o bloqueio credenciais da tela para descriptografá-lo.

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

Atestado de chaves

O Android 7.0 introduz a confirmação de chaves, uma nova ferramenta de segurança que ajuda os pares de chaves armazenados em um espaço protegido por hardware keystore para proteger adequadamente as informações sensíveis que seu app usa. Com essa ferramenta, você tem mais confiança de que seu app interage com chaves que residem em hardware seguro, mesmo se o dispositivo que executa seu app tem acesso root. Se você usar chaves do armazenamento de chaves protegido por hardware nos seus aplicativos, use essa ferramenta, principalmente se você 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 criados e armazenados em um keystore protegido por hardware no próprio dispositivo de execução confiável (TEE). A ferramenta também permite usar uma 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 cria acesso root no dispositivo ou compromete a segurança da plataforma Android em execução; no dispositivo.

Observação : apenas um pequeno número de dispositivos com o Android 7.0 oferecer suporte ao atestado de chaves no nível do hardware; Todos os outros dispositivos com Android 7.0 use o atestado de chaves no nível do software. Antes de verificar as propriedades de chaves protegidas por hardware de um dispositivo em um ambiente de produção, precisa garantir que o dispositivo ofereça suporte ao atestado de chaves no nível do hardware. Para faça isso, verifique se a cadeia de certificados de atestado contém uma certificado assinado pela chave raiz de atestado do Google e que a Elemento attestationSecurityLevel na classe key description esteja definida para o campo de segurança TrustedEnvironment nível

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

Configuração de segurança de rede

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

Recursos compatíveis:

• Âncoras de confiança personalizadas. Permite que um aplicativo personalize qual As autoridades certificadoras (CA) são confiáveis para conexões seguras. Para por exemplo, confiar em certificados autoassinados particulares ou em um conjunto restrito de CAs públicas.
• Substituições somente de depuração. Permite que um desenvolvedor de aplicativos depure com segurança conexões seguras do aplicativo sem adicionar riscos aos aplicativos base
• Desativação do tráfego de texto não criptografado. Permite que um aplicativo se proteja contra uso acidental de tráfego de texto simples.
• Fixação de certificados. Um recurso avançado que permite que um aplicativo limitam quais chaves de servidor são confiáveis para conexões seguras.

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

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

Por padrão, os apps destinados ao Android 7.0 só confiam em certificados fornecidos pelo sistema. e não confiar mais em autoridades certificadoras (CA) adicionadas pelo usuário. Apps destinados ao Android 7.0 (API de nível 24) que desejam confiar em CAs adicionadas pelo usuário devem usar o Configuração de segurança de rede para especificar como as CAs de usuário devem ser 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 app que oferece instalações mais rápidas e mais proteção contra ameaças às mudanças nos arquivos APK. Por padrão, o Android Studio 2.2 e o O plug-in para Gradle 2.2 assina o app usando o esquema de assinatura de APK v2 e o esquema de assinatura tradicional, que usa a assinatura JAR.

Recomendamos aplicar o Esquema de assinatura de APK v2 ao seu app, mas esse novo não é obrigatório. Se o app não for criado corretamente ao usar o APK esquema de assinatura v2, poderá desativar o novo esquema. Processo de desativação faz com que o Android Studio 2.2 e o plug-in do Android para Gradle 2.2 assinem seu 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 à assinatura de lançamento configuração:

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

Cuidado : se você assinar seu app usando um APK Esquema de assinatura v2 e faça outras mudanças no app, a assinatura dele é invalidado. Por isso, use ferramentas como zipalign antes de assinar seu app usando o esquema de assinatura de APK v2, não depois.

Para mais informações, 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 aplicativos podem usar novas APIs para solicitar acesso a aplicativos externos de armazenamento, inclusive diretórios em mídias removíveis, como SD cards. As novas APIs simplificam muito a forma como seu aplicativo acessa os padrões diretórios de armazenamento externo, como Pictures. Aplicativos como aplicativos de fotos, podem usar essas APIs em vez de READ_EXTERNAL_STORAGE, que concede acesso a todo o armazenamento ou pelo Framework de acesso ao armazenamento, que fazem o usuário navegar até diretório.

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

Para mais informações, consulte a Com escopo Directory Access (em inglês).

Auxiliar de atalhos do teclado

No Android 7.0, o usuário pode pressionar Meta + / para acionar uma Tela de Atalhos do teclado que mostra todos os atalhos disponíveis do sistema e do aplicativo em foco. O sistema recupera essas atalhos automaticamente no menu do app, caso existam. Você pode também fornecem listas próprias de atalhos para a tela. Você pode fazer isso substituindo o método onProvideKeyboardShortcuts().

Observação:a tecla Meta não está presente em todos Teclados: em um teclado Macintosh, é a tecla Command, no teclado do Windows, é a tecla Windows e na No Pixel C e nos teclados do ChromeOS, ela é a tecla de pesquisa.

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

Custom Pointer API

O Android 7.0 apresenta a API Custom Pointer, que permite personalizar a aparência, visibilidade e comportamento do ponteiro. Esse recurso especialmente útil quando um usuário está usando um mouse ou touchpad para interagir com objetos da interface do usuário. 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 onResolvePointerIcon() da classe View. Esse método usa uma objeto PointerIcon para desenhar o ícone que corresponde a um evento de movimento específico.

Sustained Performance API

O desempenho pode variar drasticamente em aplicativos de longa duração, porque a do sistema limita os mecanismos system on chip conforme os componentes do dispositivo atingem limites de temperatura. Essa flutuação representa um movimento alvo para o aplicativo desenvolvedores que criam apps de alto desempenho e longa duração.

Para lidar com essas limitações, o Android 7.0 inclui suporte para modo de desempenho sustentado, que permite que OEMs deem dicas sobre de desempenho máximo do dispositivo para apps de longa duração. Desenvolvedores de apps pode usar essas dicas para ajustar os aplicativos um nível consistente de desempenho do dispositivo por longos períodos.

Os desenvolvedores de aplicativos podem testar essa nova API no Android 7.0 em Somente dispositivos Nexus 6P. Para usar esse recurso, definir a flag de 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 automaticamente desativa esse modo quando a janela não está mais em foco.

Compatibilidade com RV

O Android 7.0 adiciona suporte de plataforma e otimizações a um novo Modo RV para permitir que os desenvolvedores criar experiências de RV em dispositivos móveis de alta qualidade para os usuários. Existem vários fatores como o acesso a um núcleo exclusivo da CPU para apps de RV. Dentro dos aplicativos, é possível aproveitar o rastreamento inteligente da cabeça, e notificações estereoscópicas que funcionam para RV. Mais importante ainda, o Android 7.0 oferece gráficos com latência muito baixa. Para ver informações completas sobre como criar 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 informações adicionais sobre impressoras e trabalhos de impressão individuais.

Ao listar impressoras individuais, agora um serviço de impressão pode definir uma por impressora ícones 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 definir uma chamada de retorno para quando o ícone for solicitado usando onRequestCustomPrinterIcon().

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

É possível indicar o progresso e o status no trabalho de impressão a notificação chamando setProgress() e setStatus(), respectivamente.

API Frame Metrics

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

Use a API Frame Metrics para medir a interface no nível da interação. desempenho na produção sem uma conexão USB. Esta API permite a coleta de dados com granularidade muito maior do que adb shell dumpsys gfxinfo: Essa granularidade maior é possível porque O sistema pode coletar dados para interações específicas no app. o sistema não precisam capturar um resumo global ou limpar qualquer estado global. Você pode usar isso capacidade de 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 a OnFrameMetricsAvailableListener.onFrameMetricsAvailable() método de callback e registrá-lo nessa janela.

A API fornece um objeto FrameMetrics, que contém dados de tempo que o subsistema de renderização relata 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

Em versões anteriores do Android, o app podia usar a API Storage Access Framework para permitir que os usuários selecionem arquivos das contas de armazenamento em nuvem, como o Google Drive. No entanto, não havia como representar arquivos não tenham uma representação direta de bytecode; todos os arquivos precisavam fornecer um fluxo de entrada.

O Android 7.0 adiciona o conceito de arquivos virtuais ao painel Storage Access de machine learning. Com o recurso de arquivos virtuais, DocumentsProvider para retornar URIs de documentos que podem ser usada com uma intent ACTION_VIEW, mesmo que não tenham uma representação direta de bytecode. O Android 7.0 também permite e fornecer formatos alternativos para arquivos do usuário, virtuais ou não.

Para mais informações sobre como abrir arquivos virtuais, consulte Abra arquivos virtuais no Guia de frameworks de acesso ao armazenamento.