O Android 10 inclui alterações de comportamento do sistema atualizadas que podem afetar seu app.
As alterações listadas neste documento se aplicam exclusivamente a apps destinados à API 29 ou superior. Se seu app definir targetSdkVersion como "29" ou superior, será preciso modificar o app para que ele seja compatível com esses comportamentos, 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 do app, a plataforma começou a restringir quais interfaces não SDK seu app pode usar no Android 9 (API de nível 28). O Android 10 inclui listas atualizadas de interfaces não SDK restritas baseadas na colaboração com desenvolvedores do 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 pretende desenvolver apps para o Android 10 (API de nível 29), algumas das mudanças podem não afetar você imediatamente. No entanto, embora atualmente seja possível usar as interfaces não SDK que fazem parte da lista cinza (dependendo do nível da API de destino do app), o uso de qualquer método ou campo não SDK sempre apresentará um alto risco de corromper o app.
Se você não souber se seu app usa interfaces não SDK, poderá testá-lo para descobrir. Se ele depende de interfaces não SDK, é necessário começar 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 não SDK em um recurso no seu app, solicite uma nova API public.
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 não SDK.
Memória compartilhada
O Ashmem alterou o formato dos mapas dalvik em /proc/<pid>/maps, e isso afetou 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 voltados ao Android 10 não podem mais usar diretamente o Ashmem (/dev/ashmem) e precisam acessar a memória compartilhada por meio da classe ASharedMemory do NDK (link em inglês).
Além disso, os apps não podem fazer IOCTLs diretos para os descritores de arquivos Ashmem existentes. Em vez disso, é necessário usar a classe ASharedMemory do NDK ou as APIs Android Java para criar regiões de memória compartilhada. Essa alteração aumenta a segurança e a robustez no trabalho com memória compartilhada, melhorando o desempenho e a segurança do Android como um todo.
Permissão de execução removida para o diretório inicial do app
Apps não confiáveis direcionados ao Android 10 não podem invocar exec() em arquivos no diretório inicial do app. Essa execução de arquivos do diretório inicial do app gravável é uma violação de W^X (link em inglês). Os apps precisam carregar somente o código binário incorporado ao arquivo APK do app.
Além disso, os apps destinados ao Android 10 não podem modificar o código executável na memória a partir de arquivos que foram abertos com dlopen(). 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 tempo de execução do Android (ART, na sigla em inglês) não invoca mais o dex2oat do processo do app. Com essa alteração, 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 de tempo de execução se o ambiente de caminho de classe não fosse o mesmo no tempo de compilação e no de execução. O Android 10 e versões posteriores sempre exigem que esses contextos de ambiente sejam os mesmos, resultando nas seguintes mudanças de comportamento:
- Carregadores de classe personalizados, ou seja, carregadores de classe 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 conhece a implementação de consulta de classe personalizada no tempo de execução. - Arquivos dex secundários, ou seja, os arquivos dex carregados manualmente por apps que não estão no APK principal, são compilados por AOT em segundo plano. Isso ocorre porque a compilação do 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 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
Os apps voltados ao Android 10 ou versões posteriores que usam notificações com intents de tela cheia precisam solicitar a permissão USE_FULL_SCREEN_INTENT no arquivo de manifest 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 posteriores tentar criar uma notificação com um intent de tela cheia sem solicitar a permissão necessária, o sistema ignorará esse intent e emitirá 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, 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 principais atividades focalizáveis nas pilhas visíveis ficam no estado retomado. Contudo, somente uma delas, a "principal atividade retomada", fica com o foco. Em versões anteriores ao Android 10, somente uma atividade no sistema pode ser retomada por vez, enquanto todas as outras atividades visíveis ficam 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 àquelas com as quais 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 (API de nível 29) e versões posteriores, você pode se inscrever no callback onTopResumedActivityChanged() para receber uma notificação quando sua atividade conquistar ou perder a posição de principal atividade retomada. Isso equivale ao estado retomado antes do Android 10 e pode ser útil como uma dica caso seu app utilize recursos exclusivos ou singleton que talvez precisem ser compartilhados com outros apps.
O comportamento do atributo de manifesto resizeableActivity também foi alterado. Se um app definir resizeableActivity=false no Android 10 (API de nível 29), 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, apresentado 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 emulação do Android Studio inclui dispositivos virtuais de 7,3 e 8 polegadas para testar seu código com telas maiores.
Para ver mais informações, consulte Criar apps para dispositivos dobráveis.
Alterações em java.io.FileChannel.map()
A partir do Android 10, FileChannel.map() não é compatível com arquivos que não são padrão, como /dev/zero, cujo tamanho não pode ser alterado usando truncate(). As versões anteriores do Android omitiam o erro retornado por truncate(), mas o Android 10 gera uma IOException. Se você precisar do comportamento anterior, terá que usar o código nativo.