Alterações de comportamento do Android 7.0

Junto com novos recursos e funcionalidades, o Android 7.0 inclui uma variedade de mudanças de comportamento do sistema e da API. Este documento destaca algumas das principais mudanças que você precisa entender e considerar nos seus apps.

Se você já tiver publicado um app para Android, saiba que ele podem ser afetadas por essas mudanças na plataforma.

Bateria e memória

O Android 7.0 inclui mudanças de comportamento do sistema com o objetivo de melhorar a duração da bateria. de dispositivos e reduzindo o uso de RAM. Essas mudanças podem afetar o acesso do app aos recursos do sistema, além da forma como seu aplicativo interage com outros aplicativos via certas intents implícitas.

Soneca

Introduzido no Android 6.0 (API de nível 23), o modo soneca melhora a duração da bateria em adiar atividades de CPU e rede quando um usuário deixa um dispositivo desconectado parado e com a tela desligada. O Android 7.0 traz mais aprimoramentos do modo soneca aplicando um subconjunto de restrições de CPU e rede o dispositivo estiver desconectado com a tela desligada, mas não necessariamente parados, por exemplo, quando um celular está no bolso do usuário.

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

Figura 1. 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.

Quando um dispositivo está usando a energia da bateria e a tela esteve desligada por um determinado momento, o dispositivo entra no modo Soneca e aplica o primeiro subconjunto de restrições: desativa o acesso à rede do app e adia trabalhos e sincronizações. Se o dispositivo for parado por um determinado período após entrar no modo Soneca, o sistema aplica o outras restrições do recurso "Soneca" para PowerManager.WakeLock, AlarmManager alarmes, GPS e buscas por Wi-Fi. Independentemente se algumas ou todas as restrições do Soneca estão sendo aplicadas, o sistema ativa dispositivo por breves janelas de manutenção, durante as quais os aplicativos são permitidos acesso à rede e pode executar qualquer job/sincronização adiado.

Ilustração de como o modo Soneca aplica um segundo nível de restrições de atividade do sistema depois que o dispositivo ficar inativo por um determinado tempo

Figura 2. Ilustração de como o modo Soneca aplica um segundo nível de restrições de atividade do sistema após o dispositivo ficar inativo por um determinado período.

A ativação da tela ou do dispositivo encerra o modo Soneca e remove essas restrições de processamento. O comportamento adicional não afetar as recomendações e práticas recomendadas para adaptar seu aplicativo à do Soneca introduzida no Android 6.0 (nível 23 da API), conforme discutido em Como otimizar para os modos Soneca e App em espera. Você ainda deve siga essas recomendações, como usar o Firebase Cloud Messaging (FCM) para enviar e receber mensagens e começar a planejar atualizações para acomodar a comportamento adicional do modo Soneca.

Project Svelte: otimizações em segundo plano

O Android 7.0 remove três transmissões implícitas para ajudar a otimizar ambos. uso de memória e consumo de energia. Essa mudança é necessária porque o viés implícito transmissões frequentemente iniciam apps registrados para ouvi-las em segundo plano. A remoção dessas transmissões pode beneficiar muito o dispositivo desempenho e experiência do usuário.

Dispositivos móveis passam por mudanças frequentes na conectividade, como ao se mudar entre o Wi-Fi e os dados móveis. Atualmente, os apps podem monitorar alterações em a conectividade, registrando um receptor para a transmissão implícita CONNECTIVITY_ACTION na manifesto do aplicativo. Como muitos aplicativos se registram para receber essa transmissão, um único de rede pode fazer com que todos despertem e processem a transmissão em uma vez.

Da mesma forma, em versões anteriores do Android, os apps podiam se registrar para receber transmissões implícitas ACTION_NEW_PICTURE e ACTION_NEW_VIDEO de outros apps, como Câmera. Quando um usuário tira uma foto com o app Câmera, esses apps são ativados para processar a transmissão.

Para aliviar esses problemas, o Android 7.0 aplica o seguinte otimizações:

Se o app usar qualquer uma dessas intents, remova as dependências o mais rápido possível para que você possa segmentar dispositivos Android 7.0 corretamente. O framework do Android oferece várias soluções para reduzir a necessidade essas transmissões implícitas. Por exemplo, a API JobScheduler oferece um mecanismo robusto para programar operações de rede em condições específicas, como e ilimitada, sejam atendidos. É possível até usar JobScheduler para reagir a mudanças nos provedores de conteúdo.

Para mais informações sobre otimizações em segundo plano no Android 7.0 (nível da API), 24) e como adaptar seu app, consulte Segundo plano Otimizações.

Alterações nas permissões

O Android 7.0 inclui alterações nas permissões que podem afetar seu aplicativo.

Alterações nas permissões do sistema de arquivos

Para melhorar a segurança dos arquivos privados, o diretório privado de Os apps destinados ao Android 7.0 ou versões mais recentes têm acesso restrito (0700). Essa configuração impede o vazamento de metadados de arquivos particulares, como o tamanho ou existência. Essa alteração de permissão produz vários efeitos colaterais:

Compartilhamento de arquivos entre aplicativos

Para aplicativos destinados ao Android 7.0, o framework do Android aplica a política da API StrictMode que proíbe a exposição de URIs file:// fora do app. Se uma intent com um URI de arquivo sair do app, ele falhará com uma exceção FileUriExposedException.

Para compartilhar arquivos entre aplicativos, você precisa enviar um URI content://. e conceda uma permissão de acesso temporária ao URI. A maneira mais fácil de conceder essa permissão é usando a classe FileProvider. Para mais informações sobre permissões e compartilhamento de arquivos, consulte Como compartilhar arquivos.

Melhorias na acessibilidade

O Android 7.0 inclui mudanças destinadas a melhorar a usabilidade do para usuários com visão reduzida ou deficiente. Essas mudanças devem geralmente não exigem alterações de código no aplicativo. No entanto, revise esses recursos e testá-los com seu aplicativo para avaliar possíveis impactos para o usuário do usuário.

Zoom de tela

O Android 7.0 permite que os usuários definam o Tamanho da exibição, que aumenta ou reduz todos os elementos na tela, melhorando a acessibilidade do dispositivo para usuários com baixa visão. Os usuários não conseguem alterar o zoom da tela além do mínimo largura de sw320dp, que é a largura de um Nexus 4, um smartphone comum de tamanho médio.

Tela mostrando o tamanho sem zoom de um dispositivo com uma imagem do sistema Android 7.0
Tela mostrando o efeito do aumento do tamanho de exibição de um dispositivo com uma imagem do sistema Android 7.0

Figura 3. A tela à direita mostra o efeito Aumento do tamanho da tela de um dispositivo com uma imagem do sistema Android 7.0.

Quando a densidade do dispositivo mudar, o sistema notificará os aplicativos em execução no da seguinte maneira:

  • Se um aplicativo é direcionado ao nível de API 23 ou inferior, o sistema encerra automaticamente todos os processos em segundo plano. Isso significa que, se um usuário deixar como um app para abrir a tela Configurações e alterar a Tamanho da tela, o sistema encerra o app na mesma configuração como em uma situação de pouca memória. Se o app tiver algum processos, o sistema notifica esses processos sobre a mudança de configuração descritos em Manuseio Mudanças durante a execução, como se a orientação do dispositivo tivesse mudado.
  • Se um app for direcionado ao Android 7.0, todos os processos (primeiro e segundo plano) são notificados sobre a mudança de configuração descritos em Manuseio Alterações no ambiente de execução.

A maioria dos apps não precisa fazer alterações para oferecer suporte a esse recurso, desde que que os apps sigam as práticas recomendadas do Android. Os itens específicos a serem verificados são:

  • Testar o app em um dispositivo com largura de tela sw320dp e verificar se ele funciona adequadamente.
  • Quando a configuração do dispositivo mudar, atualize as configurações informações armazenadas em cache, como bitmaps em cache ou recursos carregados da em uma rede VPC. Verificar se há mudanças de configuração quando o app é retomado do modo pausado estado.

    Observação: se você armazenar em cache dados dependentes de configuração, uma boa ideia incluir metadados relevantes, como a tela apropriada ou a densidade de pixels desses dados. Salvar esses metadados permite que você decida se é preciso atualizar os dados armazenados em cache após uma configuração mudar.

  • Evite especificar dimensões com unidades px, pois elas não são redimensionadas com densidade da tela. Em vez disso, especifique dimensões com valores independentes de densidade de pixels (dp).

Configurações de visão no assistente de configuração

O Android 7.0 inclui Configurações de visão na tela inicial, onde os usuários podem definir as seguintes configurações de acessibilidade em um novo dispositivo: Gesto de ampliação, Tamanho da fonte, Tamanho de exibição e TalkBack. Essa mudança aumenta a visibilidade de bugs relacionados a diferentes configurações de tela. Para o impacto desse recurso, teste seus aplicativos com essas ativadas. As configurações estão disponíveis em Configurações > Acessibilidade (link em inglês).

Aplicativos NDK vinculados a bibliotecas da plataforma

A partir do Android 7.0, o sistema impede que aplicativos vinculem dinamicamente em bibliotecas não NDK, o que pode causar falhas no app. Essa mudança comportamento visa criar uma experiência de aplicativo consistente em todas as atualizações da plataforma e dispositivos diferentes. Mesmo que seu código não esteja vinculado bibliotecas privadas, é possível que uma biblioteca estática de terceiros na sua aplicativo poderia fazer isso. Portanto, todos os desenvolvedores devem verificar para que os aplicativos não falhem em dispositivos com o Android 7.0. Caso seu app use código nativo, use somente APIs públicas do NDK.

Seu app pode tentar acessar a plataforma particular de três maneiras APIs:

  • O aplicativo acessa bibliotecas privadas da plataforma diretamente. Você deve atualizar que o app inclua a própria cópia dessas bibliotecas ou use as APIs públicas do NDK.
  • O app usa uma biblioteca de terceiros que acessa a plataforma particular bibliotecas. Mesmo que você tenha certeza de que o app não acessa bibliotecas privadas diretamente, você ainda deve testar seu app para esse cenário.
  • O aplicativo referencia uma biblioteca não incluída no seu APK. Para exemplo, isso pode acontecer se você tentar usar sua própria cópia do OpenSSL, mas se esqueceu de agrupá-lo com o APK do app. O app pode ser executado normalmente nas versões da plataforma Android que inclui libcrypto.so. No entanto, o app pode falhar em versões mais recentes do Android que não incluem essa biblioteca (por exemplo, Android 6.0 e mais recentes). Para corrigir isso, agrupe todos suas bibliotecas não NDK pelo seu APK.

Os apps não podem usar bibliotecas nativas não incluídas no NDK porque elas podem mudar ou ser removidas entre diferentes versões do Android. A alternar de OpenSSL para BoringSSL é um exemplo dessa mudança. Além disso, porque não há requisitos de compatibilidade para bibliotecas de plataforma incluídos no NDK, diferentes dispositivos podem oferecer níveis distintos de compatibilidade.

Para reduzir o impacto dessa restrição nas atuais aplicativos já lançados, um conjunto de bibliotecas que recebem uso significativo, como libandroid_runtime.so, libcutils.so. libcrypto.so e libssl.so, estão temporariamente Acessível no Android 7.0 (nível 24 da API) para apps direcionados ao nível 23 da API ou mais baixo. Se o seu app carregar uma dessas bibliotecas, o logcat vai gerar um aviso. e um aviso será exibido no dispositivo de destino para notificá-lo. Se você vir esses avisos, atualize o app para incluir uma cópia própria desses ou só usam as APIs públicas do NDK. Versões futuras do Android pode restringir totalmente o uso de bibliotecas privadas e fazer com que seus falhar.

Todos os aplicativos geram um erro de tempo de execução quando chamam uma API que não é público nem temporariamente acessível. O resultado é que System.loadLibrary e dlopen(3) retornam NULL, e isso pode causar falhas no app. Revise seu o código do app para remover o uso de APIs de plataformas privadas e testar completamente os apps Usar um dispositivo ou emulador com o Android 7.0 (nível 24 da API). Se você for não tem certeza se o app usa bibliotecas privadas, verifique o logcat para identificar o erro de execução.

A tabela a seguir descreve o comportamento que você deve esperar ver em uma dependendo do uso de bibliotecas nativas privadas e da API de destino nível (android:targetSdkVersion).

Bibliotecas Nível desejado da API Acesso em tempo de execução via vinculador dinâmico Comportamento do Android 7.0 (API de nível 24) Comportamento da plataforma Android futura
Pública do NDK Alguma Acessível Funciona como o esperado Funciona como o esperado
Privado (bibliotecas privadas temporariamente acessíveis) 23 ou inferior Temporariamente acessível Funciona como o esperado, mas você recebe um aviso do logcat. Erro em tempo de execução
Privado (bibliotecas privadas temporariamente acessíveis) 24 ou superior Restrito Erro em tempo de execução Erro em tempo de execução
Privado (outro) Alguma Restrito Erro em tempo de execução Erro em tempo de execução

Verificar se o aplicativo usa bibliotecas privadas

Para ajudar a identificar problemas ao carregar bibliotecas privadas, o logcat pode gerar uma ou erro de tempo de execução. Por exemplo, se o app for direcionado ao nível 23 da API ou inferior e tenta acessar uma biblioteca privada em um dispositivo com o Android 7.0, é possível que você veja um aviso semelhante ao seguinte: 

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Esses avisos do Logcat informam qual biblioteca está tentando acessar um API de plataforma privada, mas não causará falha no app. Se o app é direcionado a uma API de nível 24 ou superior. No entanto, o logcat gera o seguinte: erro de tempo de execução e seu app poderá falhar: 

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Essas saídas do logcat também podem ser exibidas se o app usar bibliotecas de terceiros. que se vinculam dinamicamente a APIs de plataforma particular. A ferramenta readelf na O Android 7.0DK permite gerar uma lista de todos os itens compartilhados bibliotecas de um determinado arquivo .so executando o seguinte comando: 

aarch64-linux-android-readelf -dW libMyLibrary.so

Atualizar o app

Aqui estão alguns passos que você pode seguir para corrigir esses tipos de erros e garantir que o app não falhe em futuras atualizações da plataforma:

  • Caso seu aplicativo use bibliotecas de plataforma privadas, atualize-o para incluir a própria cópia dessas bibliotecas ou usar as APIs públicas do NDK.
  • Caso seu app use uma biblioteca de terceiros que acesse símbolos particulares, entre em contato com autor da biblioteca para atualizá-la.
  • Certifique-se de agrupar todas as bibliotecas externas ao NDK ao APK.
  • Use as funções JNI padrão em vez de getJavaVM e getJNIEnv de libandroid_runtime.so: 
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
  • Usar __system_property_get em vez do property_get particular de libcutils.so. Para fazer isso, use __system_property_get. incluindo: 
    #include <sys/system_properties.h>

    Observação: a disponibilidade e o conteúdo das propriedades do sistema são não testados com o CTS. Uma solução melhor seria evitar o uso propriedades.

  • Use uma versão local do símbolo SSL_ctrl de libcrypto.so. Por exemplo, vincule estaticamente libcyrpto.a em seu arquivo .so ou inclua uma versão vinculada dinamicamente de libcrypto.so da BoringSSL/OpenSSL e empacotada no seu APK.

Android for Work

O Android 7.0 contém mudanças para aplicativos destinados ao Android for Work, incluindo: mudanças na instalação do certificado, redefinição de senha, usuário secundário gerenciamento e acesso a identificadores de dispositivos. Se você está criando aplicativos para Android for Work, analise essas mudanças e modifique seu app adequadamente.

  • Você precisa instalar um instalador de certificado delegado antes que o DPC possa configurar reimplantá-lo. Para apps de proprietários de dispositivos e perfis destinados ao Android 7.0 (nível 24 da API), instale o instalador de certificado delegado antes da política do dispositivo chamadas de controlador (DPC) DevicePolicyManager.setCertInstallerPackage(): Se o instalador ainda não estiver instalado, o sistema gerará uma IllegalArgumentException:
  • As restrições de redefinição de senha para administradores do dispositivo agora se aplicam ao perfil donos. Os administradores do dispositivo não podem mais usar DevicePolicyManager.resetPassword() para limpar ou mudar senhas as que já foram definidas. Os administradores do dispositivo ainda podem definir uma senha, mas apenas quando o dispositivo não tem senha, PIN ou padrão.
  • Proprietários de dispositivos e perfis podem gerenciar contas mesmo se restrições forem definido. Proprietários de dispositivos e de perfil podem chamar as APIs Account Management mesmo que haja restrições de usuário de DISALLOW_MODIFY_ACCOUNTS em vigor.
  • Os donos de dispositivo podem gerenciar usuários secundários com maior facilidade. Quando um dispositivo é em execução no modo "Proprietário do dispositivo", a restrição DISALLOW_ADD_USER é definido automaticamente. Isso impede que os usuários criem instâncias secundárias não gerenciadas usuários. Além disso, os métodos CreateUser() e Os métodos createAndInitializeUser() foram descontinuados. o novo DevicePolicyManager.createAndManageUser() as substitui.
  • Os proprietários de dispositivo podem acessar identificadores de dispositivo. Um proprietário de dispositivo pode acessar Endereço MAC Wi-Fi de um dispositivo, usando DevicePolicyManager.getWifiMacAddress(): Se o Wi-Fi nunca tiver foi ativado no dispositivo, esse método retorna um valor de null.
  • A configuração modo de trabalho controla o acesso a aplicativos de trabalho. Quando o modo de trabalho está desativado, A tela de início do sistema está esmaecida para indicar que os apps de trabalho estão indisponíveis. Ativando modo de trabalho novamente restaura o comportamento normal.
  • Ao instalar um arquivo PKCS no 12 que contém uma cadeia de certificados do cliente e a chave privada correspondente da interface de configurações, o certificado de CA na não está mais instalada no armazenamento de credenciais confiáveis. Isso não não afetam o resultado de KeyChain.getCertificateChain() quando os apps tentam recuperar o cliente cadeia de certificados. Se necessário, instale o certificado de CA ao armazenamento de credenciais confiáveis pela interface de configurações separadamente, com um formato codificado DER em uma extensão de arquivo .crt ou .cer.
  • A partir do Android 7.0, o registro e o armazenamento de impressão digital são gerenciados por usuário. Se o cliente Device Policy (DPC) do proprietário do perfil segmentar o nível da API 23 (ou anterior) em um dispositivo com Android 7.0 (API de nível 24), o usuário ainda será possível definir uma impressão digital no dispositivo, mas os aplicativos de trabalho não poderão acessar impressão digital do dispositivo. Quando o DPC segmenta o nível de API 24 e superior, o usuário pode definir impressão digital específica para o perfil de trabalho em Configurações > Segurança > Segurança do perfil de trabalho.
  • O novo status de criptografia ENCRYPTION_STATUS_ACTIVE_PER_USER é retornado por DevicePolicyManager.getStorageEncryptionStatus() para indicam que a criptografia está ativa e que a chave de criptografia está vinculada à usuário. O novo status só será retornado se o DPC visar trabalhar com API de nível 24 e posteriores. Para apps destinados a níveis anteriores de API, ENCRYPTION_STATUS_ACTIVE é retornado, mesmo que a chave de criptografia seja específica para o usuário ou perfil.
  • No Android 7.0, vários métodos que normalmente afetam toda a dispositivo se comportam de forma diferente se o dispositivo tiver um perfil de trabalho instalado com um e um desafio de trabalho separado. Em vez de afetar todo o dispositivo, esses se aplicam somente ao perfil de trabalho. (A lista completa de tais métodos é na documentação de DevicePolicyManager.getParentProfileInstance(). Por exemplo: O DevicePolicyManager.lockNow() bloqueia apenas o perfil de trabalho, em vez de bloquear todo o dispositivo. Para cada um desses métodos, é possível obter a versão do cliente chamando o método na instância pai do DevicePolicyManager você pode conseguir esse familiar responsável chamando DevicePolicyManager.getParentProfileInstance(). Por exemplo, se você chamar o lockNow() da instância pai , o dispositivo inteiro é bloqueado.

Retenção de anotações

O Android 7.0 resolve um problema em que a visibilidade das anotações foi ignorada. Esse problema permitiu que o ambiente de execução acessasse anotações que não deveriam ter sido conseguir fazer. Dentre essas anotações, estão:

  • VISIBILITY_BUILD: deveria ser visível apenas no momento da criação.
  • VISIBILITY_SYSTEM: deveria estar visível no momento da execução, mas apenas para o do sistema.

Se seu aplicativo se baseou nesse comportamento, adicione uma política de retenção que deve ficam disponíveis no ambiente de execução. Para isso, use @Retention(RetentionPolicy.RUNTIME).

Mudanças na configuração padrão de TLS/SSL

O Android 7.0 faz as seguintes mudanças na configuração padrão de TLS/SSL usados por apps para HTTPS e outro tráfego TLS/SSL:

  • Os pacotes de criptografia RC4 estão desativados.
  • Os pacotes de criptografia CHACHA20-POLY1305 estão ativados.

A desativação do RC4 por padrão pode causar falhas no HTTPS ou TLS/SSL conectividade quando o servidor não negocia pacotes modernos de criptografia. A correção preferencial é melhorar a configuração do servidor para permitir uma e pacotes de criptografia mais modernos. Idealmente, TLSv1.2 e AES-GCM precisam ser ativados, e os pacotes de criptografia Forward Secrecy (ECDHE) precisam estar ativado e preferível.

Uma alternativa é modificar o app para usar um SSLSocketFactory personalizado para se comunicar com o servidor. A fábrica precisa ser projetada para criar SSLSocket instâncias com alguns dos pacotes de criptografia exigidos pelo servidor ativados além dos pacotes de criptografia padrão.

Observação:essas mudanças não estão relacionadas ao WebView.

Apps destinados ao Android 7.0

Essas mudanças de comportamento se aplicam exclusivamente a apps direcionados Android 7.0 (nível 24 da API) ou mais recente Apps compilados com o Android 7.0, ou definir targetSdkVersion como Android 7.0 ou posterior precisa modificar para oferecer suporte a esses comportamentos de forma adequada, quando aplicável.

Mudanças em serialização

O Android 7.0 (API de nível 24) corrigiu um bug no cálculo do valor serialVersionUID em que não correspondeu à especificação.

Classes que implementam Serializable e não especificar um campo serialVersionUID explícito, poderá uma mudança no serialVersionUID padrão, o que causaria uma exceção gerada ao tentar desserializar instâncias da classe que foram serializados em uma versão anterior ou serializados por um app direcionado a uma versão anterior para a versão anterior. A mensagem de erro será semelhante a esta: 

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Para corrigir esses problemas, é preciso adicionar um campo serialVersionUID ao qualquer classe afetada com o valor de stream classdesc serialVersionUID da mensagem de erro, por exemplo: 1234 pol. neste caso. Essa mudança adere a todas as recomendações de práticas recomendadas para escrever código de serialização e funcionará em todas as versões do Android.

O bug específico que foi corrigido estava relacionado à presença de métodos inicializadores, como <clinit>. De acordo com as a presença ou ausência de um método inicializador estático na afetará o serialVersionUID padrão calculado para essa classe. Antes da correção do bug, o cálculo também verificava a superclasse em busca de um inicializador estático se uma classe não tiver um.

Para esclarecer, essa mudança não afeta apps direcionados a níveis de API 23 ou anteriores, classes que tenham um campo ou classes serialVersionUID que têm um método inicializador estático.

Outros pontos importantes

  • Quando um app é executado no Android 7.0, mas é direcionado a um nível de API mais baixo, e o usuário mudar o tamanho da tela, o processo do app será encerrado. O app precisa conseguir lidar adequadamente com esse cenário. Caso contrário, ela falhará quando o usuário a restaura de Recents.

    Teste o app para garantir para que esse comportamento não ocorra. Você pode fazer isso causando uma falha idêntica ao encerrar o app manualmente pelo DDMS.

    Os apps destinados ao Android 7.0 (nível 24 da API) e versões mais recentes não são feitos automaticamente eliminado em mudanças de densidade; No entanto, ainda podem responder mal mudanças na configuração.

  • Os aplicativos no Android 7.0 devem ser capazes de processar corretamente mudanças de configuração, e não deve falhar em inicializações subsequentes. Você pode verificar o comportamento do app alterando o tamanho da fonte (Configuração > Tela > Tamanho da fonte) e, em seguida, restaurar o app em Recents.
  • Devido a um bug em versões anteriores do Android, o sistema não sinalizou a gravação para um soquete TCP na linha de execução principal como uma violação do modo estrito. O Android 7.0 corrige esse problema. Os apps que apresentam esse comportamento agora geram uma android.os.NetworkOnMainThreadException. Em geral, não é recomendável realizar operações de rede na linha de execução principal, porque essas operações geralmente têm alta latência que causa ANRs e instabilidade.
  • A família de métodos Debug.startMethodTracing() agora é padronizada como armazenar as saídas no diretório específico do pacote no armazenamento compartilhado e não no nível superior, do cartão SD. Isso significa que os apps não precisam mais solicitar a permissão WRITE_EXTERNAL_STORAGE para usar essas APIs.
  • Muitas APIs de plataforma começaram a verificar se grandes payloads estão sendo enviados em Binder transações, e o o sistema gera TransactionTooLargeExceptions novamente como RuntimeExceptions, em vez de registrá-las ou suprimi-las silenciosamente. Um um exemplo comum é armazenar dados demais Activity.onSaveInstanceState(), o que faz com que ActivityThread.StopInfo gere uma RuntimeException quando o app é direcionado ao Android 7.0.
  • Se um app postar tarefas de Runnable em uma View e a View não estiver anexado a uma janela, o sistema coloca a tarefa Runnable em fila com o View; a tarefa Runnable não é executada até que o View está anexado a uma janela. Esse comportamento corrige os seguintes bugs:
    • Se um app postou em uma View de uma linha de execução diferente da pretendida linha de execução de IU da janela, o Runnable poderá ser executado na linha de execução errada.
    • Se a tarefa Runnable tiver sido postada de uma conversa que não seja uma linha de execução de looper, o app poderá expor a tarefa Runnable.
  • Se um app no Android 7.0 com DELETE_PACKAGES tenta excluir um pacote, mas outro aplicativo o instalou, o sistema exige a confirmação do usuário. Nesse cenário, os apps precisam esperar STATUS_PENDING_USER_ACTION como o status de retorno quando invocam PackageInstaller.uninstall().
  • O provedor JCA Crypto foi descontinuado porque só tem SHA1PRNG, é criptograficamente fraco. Os apps não podem mais usar O SHA1PRNG para (sem segurança) derivar chaves, porque esse provedor não está mais disponíveis. Para mais informações, acesse o blog poste "Criptografia" de segurança provedor descontinuado no Android N.