Alterações de comportamento do Android 7.0

Junto com novos recursos e funcionalidades, o Android 7.0 inclui uma série de mudanças de comportamento do sistema e da API. Este documento destaca algumas das alterações principais que você deve entender e levar em consideração nos aplicativos.

Caso você já tenha um aplicativo para Android publicado, saiba que ele pode ser afetado pelas alterações da plataforma.

Bateria e memória

O Android 7.0 inclui mudanças de comportamento do sistema com o objetivo de melhorar a vida útil da bateria nos dispositivos e reduzir o uso de RAM. Essas alterações podem afetar o acesso do aplicativo aos recursos do sistema, bem como a forma com que ele interage com outros aplicativos por meio de determinadas intents explícitas.

Soneca

Introduzido no Android 6.0 (nível da API 23), o modo soneca aumenta a vida útil da bateria adiando atividades de CPU e rede quando um usuário deixa um dispositivo desconectado, parado e com a tela desativada. O Android 7.0 aprimora ainda mais o modo soneca aplicando um subconjunto de restrições de CPU e rede quando o dispositivo está desconectado e com a tela desativada, mas não necessariamente parado, como, por exemplo, quando o celular está no bolso do usuário.

Figura 1. Ilustração de como o modo soneca aplica um primeiro nível de restrições de atividade de sistema para aumentar a vida útil da bateria.

Quando o dispositivo estiver sendo alimentado pela bateria e a tela estiver desativada por um determinado período, o dispositivo entrará no modo de soneca e aplicará o primeiro subconjunto de restrições: O acesso do aplicativo à rede será desativado e os trabalhos e sincronizações serão adiados. Se o dispositivo permanecer parado por um determinado período após entrar no modo soneca, o sistema aplicará as demais restrições de soneca a PowerManager.WakeLock, aos alarmes AlarmManager e às verificações de GPS e Wi-Fi. Independentemente de as restrições de soneca serem aplicadas parcial ou totalmente, o sistema despertará o dispositivo para breves janelas de manutenção, quando os aplicativos poderão acessar a rede e executar todos os trabalhos/sincronizações adiados.

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

Note que a ativação da tela ou do dispositivo encerra o modo soneca e remove essas restrições de processamento. O comportamento adicional não afeta as recomendações e práticas recomendadas para a adaptação do aplicativo à versão anterior do modo soneca, introduzida no Android 6.0 (nível da API 23), como discutido em Otimização para soneca e App em espera. Você deve continuar seguindo essas recomendações, como o uso do Google Cloud Messaging (GCM) para enviar e receber mensagens, e começar a planejar atualizações para acomodar o 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 o uso de memória e o consumo de energia. Essa alteração é necessária porque transmissões implícitas iniciam aplicativos registrados frequentemente para escutá-los em segundo plano. A remoção dessas transmissões pode beneficiar consideravelmente o desempenho do dispositivo e a experiência do usuário.

Dispositivos móveis passam por alterações frequentes na conectividade, como a alternância entre Wi-Fi e dados móveis. No momento, os aplicativos podem monitorar alterações de conectividade registrando um receptor para a transmissão implícita CONNECTIVITY_ACTION no manifsto. Como vários aplicativos se registram para receber essa transmissão, uma única mudança de rede pode fazer com que todos despertem e processem a transmissão ao mesmo tempo.

De forma semelhante, em versões anteriores do Android, os aplicativos podiam se registrar para receber transmissões implícitas ACTION_NEW_PICTURE e ACTION_NEW_VIDEO de outros aplicativos, como a Câmera. Quando um usuário tira uma fotografia com o aplicativo Câmera, esses aplicativos são despertados para processar a transmissão.

Para atenuar esses problemas, o Android 7.0 aplica as seguintes otimizações:

• Os aplicativos voltados para o Android 7.0 não receberão transmissões CONNECTIVITY_ACTION, mesmo se houver código no manifesto solicitando a notificação desses eventos. Os aplicativos em execução ainda poderão escutar CONNECTIVITY_CHANGE no encadeamento principal se solicitarem a notificação com BroadcastReceiver.
• Os aplicativos não podem enviar nem receber transmissões de ACTION_NEW_PICTURE ou ACTION_NEW_VIDEO. Essa otimização afeta todos os aplicativos e não apenas os voltados para o Android 7.0.

Se o seu aplicativo usar qualquer uma dessas intents, remova as dependências deles assim que possível para ajustá-los corretamente aos dispositivos Android 7.0. A estrutura do Android oferece diversas soluções para reduzir a necessidade dessas transmissões implícitas. Por exemplo, a JobScheduler API oferece um mecanismo robusto para agendar operações de rede quando se atende a condições específicas, como conexão a uma rede ilimitada. Você pode até usar JobScheduler para reagir a mudanças em provedores de conteúdo.

Para obter mais informações sobre otimizações em segundo plano no N e como adaptar seu aplicativo, consulte Otimizações em segundo plano.

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 aprimorar a segurança de arquivos privados, o diretório privado de aplicativos voltados para o Android 7.0 ou posteriores tem acesso restrito (0700). Essa configuração impede o vazamento de metadados de arquivos privados, como tamanho e existência. Essa alteração de permissão produz vários efeitos colaterais:

• O proprietário não deve mais relaxar as permissões para arquivos privados, e qualquer tentativa de fazer isso usando MODE_WORLD_READABLE e/ou MODE_WORLD_WRITEABLE acionará uma SecurityException.

  Observação: Até agora, essa restrição não foi implementada com pleno vigor. Aplicativos ainda podem modificar permissões para o diretório privado usando APIs nativas ou a API File. No entanto, o relaxamento de permissões para o diretório privado é enfaticamente desencorajado.

• A passagem de URIs file:// para fora do domínio do pacote pode deixar o receptor com um caminho inacessível. Sendo assim, tentativas de passar um URI file:// acionam uma FileUriExposedException. A forma recomendada para compartilhar conteúdo de um arquivo privado é usando FileProvider.
• O DownloadManager não consegue mais compartilhar arquivos armazenados de forma privada por nome de arquivo. Os aplicativos de legado podem acabar em um caminho inacessível quando acessam COLUMN_LOCAL_FILENAME. Aplicativos voltados para o Android 7.0 ou posterior acionam uma SecurityException quando tentam acessar COLUMN_LOCAL_FILENAME. Aplicativos de legado que definem o local de download como um local público usando DownloadManager.Request.setDestinationInExternalFilesDir() ou DownloadManager.Request.setDestinationInExternalPublicDir() ainda conseguem acessar o caminho em COLUMN_LOCAL_FILENAME, no entanto, este método é enfaticamente desencorajado. A forma preferencial de acessar um arquivo exposto pelo DownloadManager é usando ContentResolver.openFileDescriptor().

Compartilhamento de arquivos entre aplicativos

Para aplicativos voltados para o Android 7.0, a estrutura do Android atende à política de API StrictMode, que proíbe a exposição de URIs file:// fora do aplicativo. Se uma intent que contenha o URI de um arquivo sair o aplicativo, ele falhará com uma exceção FileUriExposedException.

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

Melhorias na acessibilidade

O Android 7.0 contém mudanças que visam aprimorar a facilidade de uso da plataforma para usuários com visão reduzida ou deficiente. Normalmente, essas mudanças não exigirão alterações de código no aplicativo. No entanto, analise esse recurso e teste-o em seu aplicativo para avaliar possíveis impactos na experiência do usuário.

Zoom de tela

O Android 7.0 permite que os usuários definam Display size, que amplia ou reduz todos os elementos na tela, melhorando a acessibilidade do dispositivo para usuários com visão deficiente. Os usuários não podem alterar o zoom da tela além da largura mínima de tela de sw320dp, que é a largura do Nexus 4, um aparelho comum de tamanho médio.

Figura 3. A tela à direita mostra o efeito de reduzir o Display size de um dispositivo executando uma imagem do sistema Android 7.0.

Quando a densidade do dispositivo mudar, o sistema notificará os aplicativos em execução das seguintes formas:

• Se um aplicativo trabalha com API de nível 23 ou inferior, o sistema automaticamente elimina todos os processos em segundo plano. Isso significa que, se um usuário sair desse aplicativo para abrir a tela Settings e alterar a configuração Display size, o sistema eliminará o aplicativo da mesma forma que faria em uma situação de pouca memória. Se o aplicativo tiver processos em primeiro plano, o sistema notificará esses processos sobre a mudança de configuração, como descrito em Processamento de alterações em tempo de execução, como se a orientação do dispositivo tivesse mudado.
• Se um aplicativo trabalhar com o Android 7.0, todos os seus processos (em primeiro e segundo plano) serão notificados da mudança de configuração, como descrito em Processamento de alterações em tempo de execução.

A maioria dos aplicativos não precisa ser alterada para ser compatível com esse recurso, desde que os aplicativos sigam as práticas recomendadas do Android. Os itens específicos a serem verificados são:

• Teste o aplicativo em um dispositivo com largura de tela sw320dp e verifique se ele funciona adequadamente.
• Quando a configuração do dispositivo mudar, atualize todas as informações dependentes de densidade armazenadas no cache, como bitmaps em cache ou recursos carregados da rede. Verifique a ocorrência de alterações de configuração quando o aplicativo sair do estado pausado e retomar a execução.

  Observação: Se você armazenar em cache dados dependentes de configuração, recomendamos incluir metadados relevantes, como o tamanho de tela adequado ou a densidade de pixels desses dados. Salvar esses metadados permitirá que você decida se será necessário atualizar os dados armazenados em cache após uma mudança de configuração.

• Evite especificar dimensões com unidades px, pois elas não são redimensionadas de acordo com a densidade de tela. Em vez disso, especifique dimensões com unidades de pixel independente de densidade (dp).

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

Agora, o Android 7.0 inclui Configurações de visão na tela de boas-vindas, onde os usuários podem definir as configurações de acessibilidade a seguir em um novo dispositivo: Gesto de ampliação, tamanho da fonte, tamanho da tela e TalkBack. Essa alteração aumenta a visibilidade de erros relacionados a configurações de tela diferentes. Para avaliar o impacto do recurso, teste seus aplicativos com essas configurações ativadas. As configurações podem ser encontradas em Settings > Accessibility.

Aplicativos NDK vinculados a bibliotecas da plataforma

A partir do Android 7.0 o sistema impede que aplicativos vinculem-se dinamicamente a bibliotecas externas ao NDK, o que pode fazer o aplicativo falhar. Essa mudança de comportamento visa criar uma experiência consistente no aplicativo para todas as atualizações da plataforma e diferentes dispositivos. Embora seu código possa não estar vinculado a bibliotecas privadas, é possível que uma biblioteca estática de terceiro no seu aplicativo esteja fazendo isso. Sendo assim, todos os desenvolvedores devem verificar se seus aplicativos falham em dispositivos com Android 7.0. Se o aplicativo usar código nativo, você só deverá usar APIs públicas do NDK.

Seu aplicativo pode tentar acessar APIs privadas da plataforma de três maneiras:

• O aplicativo acessa bibliotecas privadas da plataforma diretamente. Você deve atualizá-lo para incluir sua própria cópia dessas bibliotecas ou usar as NDK APIs públicas.
• O aplicativo usa uma biblioteca de terceiro que acessa bibliotecas privadas da plataforma. Mesmo que você tenha certeza de que seu aplicativo não acessa bibliotecas privadas diretamente, é recomendável testá-lo quanto a esse cenário.
• O aplicativo referencia uma biblioteca não incluída no seu APK. Por exemplo, isso pode acontecer se você tentar usar sua própria cópia do OpenSSL, mas esquecer de inseri-lo no APK do aplicativo. O aplicativo pode funcionar normalmente em versões da plataforma Android que incluem libcrypto.so. Porém, o aplicativo pode falhar em versões mais recentes do Android que não incluem essa biblioteca (como o Android 6.0 e posteriores). Para resolver isso, certifique-se de agrupar todas as bibliotecas externas ao NDK ao APK.

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

Para reduzir o impacto que essa restrição pode produzir em aplicativos já lançados, um conjunto de bibliotecas que apresentam uso frequente — como libandroid_runtime.so, libcutils.so, libcrypto.so e libssl.so — estão temporariamente acessíveis no N para aplicativos que trabalham com APIs de nível 23 e inferiores. Se seu aplicativo carregar uma dessas bibliotecas, o logcat gerará um aviso e uma notificação aparecerá no dispositivo em questão para informar você. Se você vir esses avisos, deverá atualizar o aplicativo para incluir sua própria cópia dessas bibliotecas ou usar apenas NDK APIs públicas. Versões futuras da plataforma Android pode restringir o uso de todas as bibliotecas privadas e fazer seu aplicativo falhar.

Todos os aplicativos geram um erro em tempo de execução quando chamam uma API que não seja pública ou não esteja temporariamente acessível. O resultado é que System.loadLibrary e dlopen(3) retornam NULL, e isso pode fazer o aplicativo falhar. Revise o código do seu aplicativo para remover o uso de APIs privadas da plataforma e faça testes completos do aplicativo usando um dispositivo de visualização ou um emulador. Se não tiver certeza se o aplicativo usa bibliotecas privadas, verifique o logcat para identificar o erro em tempo de execução.

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

Bibliotecas	Nível da API em questão	Acesso em tempo de execução via vinculador dinâmico	Comportamento da N Developer Preview	Comportamento da versão final do N	Comportamento da plataforma Android futura
Pública do NDK	Qualquer	Acessível	Funciona como o esperado	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 e uma mensagem no dispositivo em questão.	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	Erro em tempo de execução
Privado (outro)	Qualquer	Restrito	Erro em tempo de execução	Erro em tempo de execução	Erro em tempo de execução

Verificar se o aplicativo usa bibliotecas privadas

Para ajudar você a identificar problemas ao carregar bibliotecas privadas, o logcat pode gerar um aviso ou erro em tempo de execução. Por exemplo, se seu aplicativo for voltado a APIs de nível 23 ou inferior e tentar acessar uma biblioteca privada em um dispositivo com Android 7.0, você pode ver um aviso semelhante ao a seguir:

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 mostram que biblioteca está tentando acessar uma Platform API privada, mas não farão o aplicativo falhar. Se o aplicativo trabalha com API de nível 24 ou posterior, no entanto, o logcat gera o seguinte erro em tempo de execução, podendo fazer seu aplicativo 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)

Você também pode ver essas saídas do logcat se o aplicativo usar bibliotecas de terceiros que se vinculem dinamicamente a APIs privadas da plataforma. A ferramenta readelf do Android 7.0DK permite gerar uma lista de todas as bibliotecas compartilhadas vinculadas dinamicamente de um determinado arquivo .so executando o comando a seguir:

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

Atualização do aplicativo

Veja algumas etapas que você pode seguir para resolver esses tipos de erro e garantir que o aplicativo não falhe em atualizações futuras da plataforma:

• Se o aplicativo usar bibliotecas privadas da plataforma, você deve atualizá-lo, incluindo sua própria cópia dessas bibliotecas ou usando as NDK APIs públicas.
• Se o aplicativo usar uma biblioteca de terceiro que acesse símbolos privados, contate o autor da biblioteca para atualizá-la.
• Certifique-se de agrupar todas as bibliotecas externas ao NDK ao APK.
• Use 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>.
  

• Use __system_property_get em vez do símbolo property_get privado de libcutils.so. Para tanto, use __system_property_get com o seguinte include:

  #include <sys/system_properties.h>
  

  Observação: A disponibilidade e os conteúdos as propriedades do sistema não foram testadas pelo CTS. Uma melhor solução seria evitar usar essa propriedades juntas.

• Use uma versão local do símbolo SSL_ctrl de libcrypto.so. Por exemplo, você deve vincular libcyrpto.a estaticamente no seu arquivo .so ou incluir uma versão vinculada dinamicamente do libcrypto.so de BoringSSL/OpenSSL e inseri-lo no APK.

Android for Work

O Android 7.0 contém mudanças para aplicativos voltados ao Android for Work, incluindo mudanças em instalação de certificados, redefinição de senha, gerenciamento de usuários secundários e acesso a identificadores de dispositivo. Se você estiver criando aplicativos para ambientes do Android for Work, examine essas mudanças e modifique o aplicativo conforme a necessidade.

• Você precisa instalar um instalador de certificado delegado antes que o DPC possa configurá-lo. Para aplicativos proprietários de perfil e dispositivo voltados para o N SDK, você deve instalar o instalador de certificado delegado antes de chamar o controlador de políticas do dispositivo (DPC) DevicePolicyManager.setCertInstallerPackage(). Se o instalador não estiver instalado, o sistema gerará uma IllegalArgumentException.
• As restrições de redefinição de senha de administradores do dispositivo agora se aplicam também a proprietários de perfil. Os administradores de dispositivo não podem mais usar DevicePolicyManager.resetPassword() para apagar senhas nem para alterar as já definidas. Os administradores de dispositivo ainda poderão definir uma senha, mas apenas em dispositivos sem senha, PIN ou padrão.
• Proprietários de dispositivo e perfil poderão gerenciar contas, mesmo se houver restrições definidas. Eles podem chamar as Account Management APIs, mesmo se houver restrições de usuário DISALLOW_MODIFY_ACCOUNTS implementadas.
• Os donos de dispositivo podem gerenciar usuários secundários com maior facilidade. Quando um dispositivo estiver sendo executado no modo de proprietário do dispositivo, a restrição DISALLOW_ADD_USER será ativada automaticamente. Isso impede que usuários criem usuários secundários não gerenciados. Além disso, os métodos CreateUser() e createAndInitializeUser() ficaram obsoletos e foram substituídos pelo novo método DevicePolicyManager.createAndManageUser().
• Os proprietários de dispositivo podem acessar identificadores de dispositivo. O proprietário do dispositivo pode acessar o endereço MAC Wi-Fi de um dispositivo usando DevicePolicyManagewr.getWifiMacAddress(). Se a rede Wi-Fi nunca foi ativada no dispositivo, esse método retornará o valor 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 mostra os aplicativos de trabalho em cinza para indicar que estão indisponíveis. Quando reativado, o modo de trabalho retorna ao comportamento normal.
• Ao instalar um arquivo PKCS nº 12 que contenha uma cadeia de certificados de cliente e a correspondente chave privada da IU de Settings, o certificado de CA da cadeia não será mais instalado no armazenamento de credenciais confiáveis. Isso não afetará o resultado do KeyChain.getCertificateChain() quando os aplicativos tentarem recuperar a cadeia de certificados de cliente posteriormente. Se necessário, o certificado de CA deve ser instalado separadamente no armazenamento de credenciais confiáveis pela IU de Settings, com um formato codificado DER em uma extensão de arquivo .crt ou .cer.
• A partir do Android 7.0, o cadastro e a armazenamento de impressão digital são gerenciados por usuário. Se o Cliente da política do dispositivo (DPC) de um proprietário de dispositivo visa trabalhar com um dispositivo N ou pré-N, o usuário ainda poderá ativar a impressão digital no dispositivo, mas aplicativos de trabalho não poderão acessá-la. Quando o DPC visar trabalhar com N e versões posteriores, o usuário poderá ativar a impressão digital especificamente para o perfil de trabalho acessando Settings > Security > Work profile security.
• Um novo status de criptografia ENCRYPTION_STATUS_ACTIVE_PER_USER é retornado por DevicePolicyManager.getStorageEncryptionStatus() para indicar que a criptografia está ativa e que a chave de criptografia está vinculada ao usuário. O novo status só será retornado se o DPC visar trabalhar com API de nível 24 e posteriores. Para aplicativos que visam trabalhar com APIs mais antigas, ENCRYPTION_STATUS_ACTIVE é retornado, mesmo que a chave de criptografia seja específica do usuário ou do perfil.
• No Android 7.0, diversos métodos que normalmente afetariam todo o dispositivo se comportariam de forma diferente se o dispositivo tivesse um perfil de trabalho instalado com um desafio de trabalho separado. Em vez de afetar todo o dispositivo, esses métodos aplicam-se somente ao perfil de trabalho (a lista completa de tais métodos está na documentação DevicePolicyManager.getParentProfileInstance()). Por exemplo, DevicePolicyManager.lockNow() bloqueia apenas o perfil de trabalho, em vez de todo o dispositivo. Para cada um desses métodos, você pode obter o comportamento anterior chamando o método da instância primária de DevicePolicyManager — você pode obter esse primário chamando DevicePolicyManager.getParentProfileInstance(). Então, por exemplo, se você chamar o método lockNow() da instância primária, todo o dispositivo será bloqueado.

Para obter mais informações sobre as mudanças no Android for Work no Android 7.0, consulte Atualizações no Android for Work.

Retenção de anotações

O Android 7.0 resolve um problema em que a visibilidade das anotações foi ignorada. Esse problema ativou o tempo de execução para acessar anotações que não deveria acessar. Dentre essas anotações, estão:

• VISIBILITY_BUILD: que só deveria estar visível em tempo de compilação.
• VISIBILITY_SYSTEM: que deveria estar visível em tempo de execução, mas apenas para o sistema em questão.

Se o seu aplicativo se baseou neste comportamento, adicione uma política de retenção para anotações que seja disponibilizada em tempo de execução. É possível fazer isso usando @Retention(RetentionPolicy.RUNTIME).

Outros pontos importantes

• Quando um aplicativo for executado no Android 7.0, mas for voltado a uma API de nível menor e o usuário alterar o tamanho da tela, o processo do aplicativo será eliminado. O aplicativo deverá ser capaz de processar corretamente esse cenário. Caso contrário, ele falhará quando o usuário restaurá-lo em Recents.

  Você deve testar o aplicativo para garantir que esse comportamento não ocorra. É possível fazer isso causando uma falha idêntica ao eliminar o aplicativo manualmente pelo DDMS.

  Aplicativos voltados para o N e versões posteriores não serão eliminados automaticamente em mudanças de densidade. No entanto, podem continuar respondendo a alterações de configurações de forma não ideal.

• Os aplicativos no Android 7.0 devem ser capazes de processar corretamente mudanças de configuração e não devem falhar em inicializações subsequentes. Você pode verificar o comportamento do aplicativo alterando o tamanho da fonte (Setting > Display > Font size) e depois restaurando o aplicativo em Recents.
• Devido a um erro em versões anteriores do Android, o sistema não sinaliza gravações em um soquete TCP no encadeamento principal como violações estritas de modo. O Android 7.0 corrige esse problema. Os aplicativos que exibem esse comportamento agora acionam uma android.os.NetworkOnMainThreadException. Geralmente, a realização de operações de rede no encadeamento principal é uma má ideia porque essas operações geralmente têm alta latência no final, causando ANRs e problemas.
• Agora, por padrão, a família de métodos Debug.startMethodTracing() armazena os resultados no diretório específico do pacote no armazenamento compartilhado, e não no nível mais alto do cartão SD. Isso significa que os aplicativos não precisam mais solicitar a permissão WRITE_EXTERNAL_STORAGE para usar estas APIs.
• Muitas Plataform APIs começaram a verificar grandes cargas úteis enviadas por meio de transações de Binder, e o sistema agora gera TransactionTooLargeExceptions novamente como RuntimeExceptions, em vez de registrá-las ou suprimi-las silenciosamente. Um exemplo comum é armazenar dados demais em Activity.onSaveInstanceState(), o que faz com que ActivityThread.StopInfo gere uma RuntimeException quando seu aplicativo trabalha com Android 7.0.
• Se um aplicativo publica tarefas Runnable para uma View e esta View não está anexada a uma janela, o sistema coloca a tarefa Runnable em fila com a View. A tarefa Runnable não é executada até que a View esteja anexada a uma janela. Este comportamento corrige os seguintes erros:
  • Se um aplicativo publicasse em uma View de um encadeamento que não fosse o encadeamento de IU da janela pretendida, o Runnable poderia acabar sendo executado no encadeamento errado.
  • Se a tarefa Runnable fosse publicada a partir de um encadeamento que não fosse um encadeamento de looper, o aplicativo poderia expor a tarefa Runnable.
• Se um aplicativo no Android 7.0 com permissão DELETE_PACKAGES tentar excluir um pacote instalado por outro aplicativo, o sistema solicitará a confirmação do usuário. Nesse cenário, os aplicativos devem esperar STATUS_PENDING_USER_ACTION como o status de retorno ao invocar PackageInstaller.uninstall().
• O provedor de JCA, Crypto, está obsoleto porque seu único algoritmo, SHA1PRNG, é fraco em termos de criptografia. Os aplicativos não podem mais usar o SHA1PRNG para (de forma não segura) derivar chaves, porque esse provedor não está mais disponível. Para saber mais, veja a publicação Provedor de segurança "Crypto" obsoleto no Android N do blogue.