Mudanças de comportamento: apps direcionados a níveis de API acima do 29

O Android 10 inclui mudanças atualizadas de comportamento do sistema 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, faça modificações 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.

Atualizações para restrições de interface não SDK

Para garantir a estabilidade e a compatibilidade dos apps, a plataforma começou a restringir quais interfaces externas ao SDK podem ser usadas 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 as interfaces não SDK.

Se você não segmentar o Android 10 (nível 29 da API), algumas dessas mudanças podem não afetar 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 sabe se o app usa interfaces não SDK, é possível testá-lo para descobrir. Se ele depende de interfaces não SDK, planeje 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 deixar de usar uma interface não SDK em um recurso no app, solicite uma nova API pública.

Para saber mais, consulte Atualizações para restrições de interface não SDK no Android 10 e Restrições para interfaces nã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 mais recente e analisar de acordo se o app depende de formatos de mapa dalvik.

Os apps destinados ao Android 10 não podem usar o ashmem diretamente (/dev/ashmem) e precisam acessar a memória compartilhada pela classe ASharedMemory do NDK. Além disso, os apps não podem fazer IOCTLs diretos para descritores de arquivo ashmem atuais 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 do diretório inicial do app gravável é uma violação W^X. Os apps precisam carregar apenas 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 na memória o código executável de arquivos que foram abertos com dlopen() e esperar que essas mudanças sejam gravadas no disco, porque a biblioteca não pode ter sido mapeada PROT_EXEC por um descritor do 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. Com essa mudança, o ART só vai aceitar 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 Runtime (ART) podia causar falhas de execução se o ambiente do caminho de classe não fosse o mesmo no tempo de compilação e no tempo de execução. O Android 10 e versões mais recentes sempre exigem que esses contextos de ambiente sejam os mesmos, o que resulta nas seguintes mudanças de comportamento:

• Os carregadores de classes personalizados, ou seja, escritos por apps, ao contrário dos carregadores de classes do pacote dalvik.system, não são compilados por AOT. Isso ocorre porque o ART não pode saber sobre a implementação personalizada de pesquisa de classe 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 em AOT em segundo plano. Isso ocorre porque a compilação no primeiro uso pode ser muito cara, levando a uma latência indesejada antes da execução. Para apps, recomendamos adotar divisões e deixar de usar 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 da usada 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, então 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 maneira diferente. Quando vários apps aparecem ao mesmo tempo no modo de várias janelas ou várias telas, todas as atividades principais em foco nas pilhas visíveis ficam no estado retomado, mas apenas uma delas, a atividade "retomada mais importante", tem o foco. Ao executar em versões anteriores ao Android 10, apenas uma 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 no topo, 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, é possível se inscrever no callback onTopResumedActivityChanged() para receber uma notificação quando a atividade adquirir ou perder a posição retomada mais alta. Isso é o equivalente ao estado retomado antes do Android 10 e pode ser útil como uma dica se o app estiver usando recursos exclusivos ou singleton que talvez precisem ser compartilhados com outros apps.

O comportamento do atributo de manifesto resizeableActivity também mudou. Se um app definir resizeableActivity=false no Android 10 (nível 29 da API) ou mais recente, ele poderá ser colocado no modo de compatibilidade quando o tamanho da tela disponível mudar ou se o app for movido de uma tela para outra.

Os apps podem usar o atributo android:minAspectRatio, introduzido no Android 10, para indicar as proporções de tela compatíveis com o 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 mais informações, consulte Criar apps para dispositivos dobráveis.