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.
![Dispositivos móveis executando apps no modo de tela dividida](https://developer.android.google.cn/static/images/android-7.0/mw-portrait.png?authuser=19&hl=pt)
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.
![Dispositivo móvel mostrando notificações de mensagens agrupadas](https://developer.android.google.cn/static/images/android-7.0/notifications-1.png?authuser=19&hl=pt)
![Dispositivo móvel exibindo notificação de mensagem única](https://developer.android.google.cn/static/images/android-7.0/notifications-3.png?authuser=19&hl=pt)
![Dispositivo móvel exibindo a resposta de mensagem inline na interface de notificação](https://developer.android.google.cn/static/images/android-7.0/notifications-2.png?authuser=19&hl=pt)
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.
![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.google.cn/static/images/android-7.0/doze-diagram-1.png?authuser=19&hl=pt)
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
.
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
![Economia de dados nas Configurações](https://developer.android.google.cn/static/images/android-7.0/datasaver.png?authuser=19&hl=pt)
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
![Blocos de Configurações rápidas na aba de notificações](https://developer.android.google.cn/static/images/android-7.0/quicksettings.png?authuser=19&hl=pt)
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.
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 usandoonRequestCustomPrinterIcon()
.
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.