O Android 10 inclui mudanças de comportamento do sistema atualizadas que podem afetar seu app.
As mudanças listadas nesta página se aplicam exclusivamente a apps destinados à
API 29 ou mais recente. Se o app definir targetSdkVersion
como "29" ou
mais recentes, modifique o app para oferecer suporte a esses comportamentos
quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam todos os apps. em execução no Android 10.
Observação : além das mudanças listadas nesta página, o Android 10 introduziu várias mudanças e restrições relacionadas à privacidade, incluindo: o seguinte:
- Armazenamento com escopo
- Acesso ao número de série do dispositivo USB
- Capacidade de ativar, desativar e configurar o Wi-Fi
- Permissões de localização para APIs de conectividade
Essas mudanças, que afetam os apps direcionados ao nível 29 da API ou mais recente, melhorar a privacidade do usuário. Para saber mais sobre como oferecer suporte a essas mudanças, consulte Alterações de privacidade.
Atualizações para restrições de interface não SDK
Para garantir a estabilidade e a compatibilidade do app, a plataforma começou a restringir quais interfaces não SDK que seu app pode usar no Android 9 (nível 28 da API). O Android 10 inclui listas atualizadas de interfaces não SDK restritas com base na colaboração com desenvolvedores Android e os testes internos mais recentes. Nosso objetivo é garantir que as alternativas públicas estejam disponíveis antes de restringirmos as interfaces não SDK.
Caso seu app não seja destinado ao Android 10 (nível 29 da API), algumas dessas mudanças pode não afetá-lo imediatamente. No entanto, embora atualmente seja possível usar algumas interfaces não SDK (dependendo do nível da API de destino do app), o uso de qualquer método ou campo não SDK sempre apresenta um alto risco de corromper o app.
Se você não souber se o app usa interfaces externas ao SDK, será possível testar seu app para descobrir. Se ele depende de interfaces não SDK, comece a planejar uma migração para alternativas SDK. No entanto, entendemos que alguns apps têm casos de uso válidos para interfaces não SDK. Se você não encontrar uma alternativa para usar uma interface externa ao SDK para um recurso no seu app, é necessário solicitar uma nova API pública.
Para saber mais, consulte Atualizações para restrições de interface não SDK no Android 10. e consulte Restrições para interfaces que não são SDK.
Memória compartilhada
O Ashmem alterou o formato dos mapas dalvik em /proc/<pid>/maps, afeta os apps que analisam diretamente o arquivo de mapas. Os desenvolvedores de apps precisam testar o formato /proc/<pid>/maps em dispositivos que executam o Android 10 ou versões posteriores e analisar adequadamente se o app depende dos formatos de mapa dalvik.
Os apps destinados ao Android 10 não podem usar o Ashmem diretamente.
(/dev/ashmem) e precisa acessar a memória compartilhada por meio do namespace
Classe ASharedMemory
.
Além disso, os aplicativos não podem fazer IOCTLs diretos para descritores de arquivos ashmem existentes
e, em vez disso, precisa usar a classe ASharedMemory
do NDK ou o Java do Android
APIs para criar regiões de memória compartilhada. Essa mudança aumenta a segurança e
robustez ao trabalhar com memória compartilhada, melhorando o desempenho e a segurança
do Android em geral.
Permissão de execução removida para o diretório inicial do app
A execução de arquivos do diretório inicial do app gravável é uma violação W^X (link em inglês). Os apps precisam carregar somente o código binário incorporado ao arquivo do APK do app.
Apps não confiáveis direcionados ao Android 10 não podem invocar execve()
diretamente nos arquivos no diretório inicial do app.
Além disso, os apps direcionados ao Android 10 não podem modificar na memória
código executável de arquivos que foram abertos com dlopen()
e esperam
gravações dessas alterações em disco, porque a biblioteca não pode ter
mapeado para PROT_EXEC
por meio de um descritor de arquivo gravável. Isso inclui
Arquivos de objeto compartilhado (.so
) com realocações de texto.
Tempo de execução do Android aceita apenas arquivos OAT gerados pelo sistema
O Android Runtime (ART) não invoca mais dex2oat
do aplicativo
de desenvolvimento de software. Com essa alteração, o ART aceitará apenas arquivos OAT gerados pelo
sistema.
Aplicação da correção AOT no ART
No passado, a compilação antecipada (AOT, na sigla em inglês) realizada pelo Android O tempo de execução (ART) poderia causar falhas de tempo de execução se o ambiente do caminho de classe não fosse os mesmos no tempo de compilação e execução. Android 10 e versões mais recentes exigem que os contextos de ambiente sejam os mesmos, o que resulta mudanças de comportamento a seguir:
- Carregadores de classe personalizados, ou seja, carregadores de classe gravados por apps, ao contrário das classes
carregadores do pacote
dalvik.system
não são compilados AOT. Isso ocorre porque O ART não consegue conhecer a implementação de consulta de classe personalizada no momento da execução. - Arquivos dex secundários, ou seja, os arquivos dex carregados manualmente por aplicativos que não estão APK primário, são compilados AOT em segundo plano. Isso ocorre porque o primeiro uso a compilação pode ser muito cara, levando à latência indesejada antes execução. Para apps, adotar divisões e deixar de usar componentes dex é recomendado.
- As bibliotecas compartilhadas no Android (as entradas <library> e <uses-library> em um manifesto do Android) são implementadas com uma hierarquia de carregador de classe diferente daquela usada em versões anteriores da plataforma.
Alterações em permissões para intents de tela cheia
Apps direcionados ao Android 10 ou versões mais recentes que usam notificações com
tela cheia
intents devem solicitar
as
USE_FULL_SCREEN_INTENT
no arquivo de manifesto do app. Isso é normal
permissão para que o sistema
a concede automaticamente ao app solicitante.
Se um app destinado ao Android 10 ou versões mais recentes tentar criar uma notificação com uma intent de tela cheia sem solicitar a permissão necessária, o sistema vai ignorar essa intent e exibir a seguinte mensagem de log:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Compatibilidade com dobráveis
O Android 10 introduz alterações que são compatíveis com dispositivos dobráveis e de tela grande.
Quando um app é executado no Android 10, a
onResume()
e
Os métodos onPause()
funcionam
de maneiras diferentes. Quando vários apps aparecem ao mesmo tempo no modo de várias janelas ou
modo de várias telas, todas as principais atividades focalizáveis em pilhas visíveis
estão no estado Retomado, mas apenas um deles, o "principal retomado" atividade
realmente tem foco. Quando executado em versões anteriores ao Android 10, apenas um
atividade única no sistema pode ser retomada por vez, todas as outras
atividades sejam pausadas.
Não confunda "foco" com a "principal atividade retomada". O sistema atribui as atividades com base na ordem z para dar maior prioridade as atividades com que o usuário interagiu por último. Uma atividade pode ser a principal atividade retomada, mas não ter o foco (por exemplo, quando a aba de notificações é expandida).
No Android 10 (nível 29 da API) e versões mais recentes, é possível assinar os
Callback onTopResumedActivityChanged()
receber uma notificação quando sua atividade adquirir ou perder o conteúdo retomado
posição Isso equivale ao estado retomado antes do Android 10 e pode ser útil
como uma dica caso seu app use recursos exclusivos ou singleton que podem precisar
sejam compartilhados com outros aplicativos.
O comportamento
resizeableActivity
atributo de manifesto também foi alterado. Se um app definir
resizeableActivity=false
no Android 10 (nível 29 da API) ou versões mais recentes, ele poderá ser colocado no modo de compatibilidade
quando o tamanho de tela disponível mudar ou se o app passar de uma tela para
outra.
Os apps podem usar o
android:minAspectRatio
introduzido no Android 10, para indicar a tela
proporções compatíveis com o app.
A partir da versão 3.5, a ferramenta de emulador do Android Studio inclui 7,3" e 8" dispositivos virtuais para testar seu código com telas maiores.
Para saber mais, consulte Projetar apps para dispositivos dobráveis.