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](https://developer.android.google.cn/static/images/android-7.0/doze-diagram-1.png?authuser=0000&hl=pt-br)
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](https://developer.android.google.cn/static/images/android-7.0/doze-diagram-2.png?authuser=0000&hl=pt-br)
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:
- Os apps destinados ao Android 7.0 (API de nível 24) e versões mais recentes não receberão
transmissões
CONNECTIVITY_ACTION
se declararem o broadcast receiver no manifesto. Os apps ainda receberão transmissõesCONNECTIVITY_ACTION
se registrarem oBroadcastReceiver
noContext.registerReceiver()
e esse contexto ainda for válido. - O sistema não envia mais transmissões
ACTION_NEW_PICTURE
ouACTION_NEW_VIDEO
. Essa otimização afeta todos os aplicativos, não apenas aqueles destinados ao Android 7.0.
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:
-
O proprietário não pode mais relaxar as permissões de arquivos particulares.
e tentar fazer isso usando
MODE_WORLD_READABLE
e/ouMODE_WORLD_WRITEABLE
vai acionarSecurityException
Observação:essa restrição ainda não foi aplicada totalmente. Os apps ainda podem modificar as permissões para o diretório privado usando APIs nativas ou da API
File
. No entanto, recomendamos fortemente desencorajar o relaxamento de permissões para o diretório privado. -
A transmissão de URIs
file://
para fora do domínio do pacote pode deixar o receptor com um caminho inacessível. Portanto, as tentativas de passar um O URIfile://
aciona umFileUriExposedException
. A forma recomendada de compartilhar conteúdo de um arquivo particular está usando oFileProvider
. -
O dispositivo
DownloadManager
não pode mais compartilhar de forma particular os arquivos armazenados por nome de arquivo. Os aplicativos legados podem acabar caminho inacessível ao acessarCOLUMN_LOCAL_FILENAME
. Segmentação por aplicativos O Android 7.0 ou versões mais recentes acionam umaSecurityException
quando tentando acessarCOLUMN_LOCAL_FILENAME
. Apps legados que definem o local do download como um local público usandoDownloadManager.Request.setDestinationInExternalFilesDir()
ouDownloadManager.Request.setDestinationInExternalPublicDir()
ainda pode acessar o caminhoCOLUMN_LOCAL_FILENAME
, no entanto, não é recomendado. A maneira preferencial de acessar um arquivo exposto porDownloadManager
está usandoContentResolver.openFileDescriptor()
.
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](https://developer.android.google.cn/static/images/android-7.0/screen-zoom-1.png?authuser=0000&hl=pt-br)
![Tela mostrando o efeito do aumento do tamanho de exibição de um dispositivo com uma imagem do sistema Android 7.0](https://developer.android.google.cn/static/images/android-7.0/screen-zoom-2.png?authuser=0000&hl=pt-br)
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
egetJNIEnv
delibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
- Usar
__system_property_get
em vez doproperty_get
particular delibcutils.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
delibcrypto.so
. Por exemplo, vincule estaticamentelibcyrpto.a
em seu arquivo.so
ou inclua uma versão vinculada dinamicamente delibcrypto.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á umaIllegalArgumentException
: - 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étodosCreateUser()
e Os métodoscreateAndInitializeUser()
foram descontinuados. o novoDevicePolicyManager.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 denull
. - 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 porDevicePolicyManager.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: ODevicePolicyManager.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 doDevicePolicyManager
você pode conseguir esse familiar responsável chamandoDevicePolicyManager.getParentProfileInstance()
. Por exemplo, se você chamar olockNow()
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ãoWRITE_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 geraTransactionTooLargeExceptions
novamente comoRuntimeExceptions
, em vez de registrá-las ou suprimi-las silenciosamente. Um um exemplo comum é armazenar dados demaisActivity.onSaveInstanceState()
, o que faz com queActivityThread.StopInfo
gere umaRuntimeException
quando o app é direcionado ao Android 7.0. -
Se um app postar tarefas de
Runnable
em umaView
e aView
não estiver anexado a uma janela, o sistema coloca a tarefaRunnable
em fila com oView
; a tarefaRunnable
não é executada até que oView
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, oRunnable
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 tarefaRunnable
.
- Se um app postou em uma
-
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 esperarSTATUS_PENDING_USER_ACTION
como o status de retorno quando invocamPackageInstaller.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.