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 recente, modifique o app para oferecer suporte a esses comportamentos de forma adequada,
quando aplicável.
Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 10.
Observação : além das mudanças listadas nesta página, o Android 10 apresenta um grande número de mudanças e restrições baseadas em privacidade, incluindo o seguinte:
- Armazenamento com escopo
- Acesso ao número de série do dispositivo USB
- 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, melhoram a privacidade do usuário. Para saber mais sobre como oferecer suporte a essas mudanças, consulte a página Mudanças 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 as interfaces externas ao 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 nos testes internos mais recentes. Nosso objetivo é garantir que alternativas públicas estejam disponíveis antes de restringirmos interfaces externas ao SDK.
Se você não for destinado ao Android 10 (nível 29 da API), algumas dessas mudanças talvez não afetem você 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, teste o app para descobrir. Caso seu app dependa de interfaces externas ao 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. Caso você não encontre uma alternativa para deixar de usar uma interface externa ao SDK em um recurso no app, solicite uma nova API pública.
Para saber mais, consulte as páginas Atualizações para restrições de interface não SDK no Android 10 e Restrições para interfaces que não são SDK.
Memória compartilhada
O Ashmem mudou o formato dos mapas dalvik em /proc/<pid>/maps, afetando os apps que analisam diretamente o arquivo de mapas. Os desenvolvedores de aplicativos precisam testar o formato /proc/<pid>/maps em dispositivos com o Android 10 ou versões mais recentes e fazer a análise adequada caso o app dependa dos formatos de mapa dalvik.
Os apps destinados ao Android 10 não podem usar diretamente o Ashmem (/dev/ashmem) e precisam acessar a memória compartilhada por meio da classe ASharedMemory do NDK.
Além disso, os apps não podem fazer IOCTLs diretos para descritores de arquivos ashmem
existentes e precisam usar a classe ASharedMemory do NDK ou as APIs Java
do Android para criar regiões de memória compartilhada. Essa mudança aumenta a segurança e
a 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 a partir do diretório inicial do app gravável é uma violação W^X. Os apps precisam carregar somente o código binário incorporado ao arquivo APK do app.
Apps não confiáveis direcionados ao Android 10 não podem invocar execve()
diretamente em arquivos no diretório inicial do app.
Além disso, os apps direcionados ao Android 10 não podem modificar
o código executável na memória a partir de arquivos que foram abertos com dlopen() e esperam
que essas mudanças sejam gravadas em disco, porque a biblioteca não pode
ter sido mapeada para PROT_EXEC por um descritor de arquivo gravável. Isso inclui todos
os 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 processo do
aplicativo. Essa mudança significa que o ART aceitará apenas arquivos OAT gerados pelo
sistema.
Aplicação da correção AOT no ART
Antes, a compilação antecipada (AOT, na sigla em inglês) realizada pelo Android Runtime (ART) poderia causar falhas na execução se o ambiente do caminho de classe não fosse o mesmo no momento da compilação e do tempo de execução. O Android 10 e versões mais recentes sempre exigem que esses contextos de ambiente sejam os mesmos, resultando nas seguintes mudanças de comportamento:
- Carregadores de classes personalizados, ou seja, carregadores de classes escritos por apps, ao contrário dos carregadores
de classes do pacote
dalvik.system, não são compilados AOT. Isso ocorre porque o ART não conhece a implementação de pesquisa de classe personalizada no momento da execução. - Os arquivos dex secundários, ou seja, os arquivos dex carregados manualmente por apps que não estão no APK principal, são compilados AOT em segundo plano. Isso ocorre porque a compilação de primeiro uso pode ser muito cara, levando à latência indesejada antes da execução. Para apps, é recomendável adotar divisões e se afastar dos arquivos dex secundários.
- As bibliotecas compartilhadas no Android (as entradas <library> e <uses-library> em um manifesto do Android) são implementadas usando uma hierarquia de carregador de classes diferente daquela utilizada em versões anteriores da plataforma.
Alterações em permissões para intents de tela cheia
Os apps destinados ao Android 10 ou versões mais recentes que usam notificações com
intents
de tela cheia precisam solicitar
a
permissão
USE_FULL_SCREEN_INTENT
no arquivo de manifesto do app. Essa é uma permissão
normal, portanto, 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 a intent de tela cheia e vai gerar a seguinte mensagem de registro:
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, os métodos
onResume() e
onPause() funcionam
de forma diferente. Quando vários apps aparecem ao mesmo tempo no modo de várias janelas ou
várias telas, todas as principais atividades focalizáveis nas pilhas visíveis
estão no estado retomado, mas apenas uma delas, a atividade "principalmente retomada",
realmente tem o foco. Ao executar em versões anteriores ao Android 10, apenas uma
única atividade no sistema pode ser retomada por vez, todas as outras atividades
visíveis são pausadas.
Não confunda "foco" com a "principal atividade retomada". O sistema atribui prioridades às atividades com base na ordem z para dar maior prioridade às atividades com que o usuário interagiu por último. Uma atividade pode ser retomada principal, mas não ter foco (por exemplo, se a aba de notificações estiver expandida).
No Android 10 (nível 29 da API) e versões mais recentes, você pode se inscrever no callback
onTopResumedActivityChanged()
para receber uma notificação quando sua atividade conquistar ou perder a posição de principal
retomada. Isso é equivalente ao estado retomado antes do Android 10 e pode ser útil
como uma dica caso seu app esteja usando recursos exclusivos ou singleton que podem precisar
ser compartilhados com outros apps.
O comportamento do atributo de manifesto
resizeableActivity
também mudou. Se um app definir
resizeableActivity=false no Android 10 (API de nível 29) 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 atributo
android:minAspectRatio, introduzido no Android 10, para indicar as proporções
de tela com suporte do app.
A partir da versão 3.5, a ferramenta de emulador do Android Studio inclui dispositivos virtuais de 7,3" e 8" para testar seu código com telas maiores.
Para saber mais, consulte Projetar apps para dispositivos dobráveis.