Mudanças de comportamento: todos os apps

A plataforma Android 11 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam a todos os apps quando executados no Android 11, independentemente de targetSdkVersion. Teste seu app e modifique-o conforme necessário para ficar compatível com essas mudanças, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps direcionados ao Android 11.

Privacidade

O Android 11 introduz mudanças e restrições para melhorar a privacidade do usuário, incluindo:

  • Permissões únicas: oferece aos usuários a opção de conceder acesso temporário às permissões de localização, microfone e câmera.
  • Visibilidade da caixa de diálogo de permissão: recusas repetidas de uma permissão implicam "não perguntar novamente".
  • Auditoria de acesso a dados: receba informações sobre onde seu app acessa dados particulares, tanto no código do app quanto no código das bibliotecas dependentes.
  • Permissões da janela de alerta do sistema: determinadas classes de apps recebem automaticamente a permissão SYSTEM_ALERT_WINDOW mediante solicitação. Além disso, as intents que incluem a ação da intent ACTION_MANAGE_OVERLAY_PERMISSION sempre levam os usuários a uma tela nas configurações do sistema.
  • Identificadores de chip permanentes: no Android 11 e em versões mais recentes, o acesso a ICCIDs não reconfiguráveis por meio de getIccId() é restrito. O método retorna uma string vazia não nula. Para identificar exclusivamente um chip instalado no dispositivo, use o método getSubscriptionId(). O ID da assinatura fornece um valor de índice (começando em 1) para identificar exclusivamente chips instalados, incluindo físicos e eletrônicos. O valor desse identificador é estável para um determinado chip, a menos que o dispositivo seja redefinido para a configuração original.

Para saber mais, consulte a página Privacidade.

Notificações de Exposição

O Android 11 atualiza a plataforma para adequá-la ao Sistema de Notificação de Exposição. Agora, os usuários podem executar apps de Notificações de Exposição no Android 11 sem precisar ativar a configuração de localização do dispositivo. Essa é uma exceção exclusiva do Sistema de Notificação de Exposição, que foi projetado de maneira a não permitir que os apps que o utilizam consigam inferir a localização do dispositivo por meio da busca por Bluetooth.

Para proteger a privacidade do usuário, todos os outros apps não podem realizar a busca por Bluetooth, a menos que a configuração de localização do dispositivo esteja ativada e o usuário tenha concedido a permissão de localização. Leia mais na postagem Atualização das Notificações de Exposição (em inglês).

Segurança

Soquetes SSL usam o mecanismo SSL do Conscrypt por padrão

A implementação SSLSocket padrão do Android é baseada em Conscrypt (link em inglês). Desde o Android 11, essa implementação é criada internamente no SSLEngine do Conscrypt.

Alocador reforçado Scudo

O Android 11 usa o Alocador reforçado Scudo internamente para fazer o serviço de alocações de heap. O Scudo é capaz de detectar e atenuar alguns tipos de violações de segurança da memória. Se você estiver vendo falhas relacionadas ao Scudo (por exemplo, Scudo ERROR:) em relatórios de falhas nativas, consulte a documentação Solução de problemas do Scudo.

Estatísticas de uso do app

Para proteger melhor os usuários, o Android 11 armazena as estatísticas de uso de apps de cada usuário em armazenamento criptografado por credencial. Portanto, nem o sistema nem os apps podem acessar esses dados, a menos que isUserUnlocked() retorne true, o que ocorre após um dos acontecimentos a seguir:

  • O usuário desbloqueia o dispositivo pela primeira vez após a inicialização do sistema.
  • O usuário muda para a própria conta no dispositivo.

Se o app já estiver vinculado a uma instância de UsageStatsManager, verifique se você chama métodos neste objeto depois que o usuário desbloqueia o dispositivo. Caso contrário, a API retornará valores nulos ou vazios.

Compatibilidade com emulador para 5G

O Android 11 adicionou APIs 5G para permitir que seus apps adicionem recursos modernos. Para testar os recursos adicionados, você pode usar os novos recursos do emulador do SDK do Android. A nova funcionalidade foi adicionada à versão 30.0.22 do emulador. Ao selecionar as configurações de rede 5G, TelephonyDisplayInfo é definido como OVERRIDE_NETWORK_TYPE_NR_NSA, a largura de banda estimada é modificada e permite definir a limitação para verificar se o app responde apropriadamente às mudanças no status NET_CAPABILITY_TEMPORARILY_NOT_METERED.

Desempenho e depuração

A chamada da API JobScheduler limita a depuração

O Android 11 oferece compatibilidade de depuração para que os apps identifiquem possíveis invocações da API JobScheduler que tenham excedido determinadas limitações de taxa. Os desenvolvedores podem usar esse recurso para identificar possíveis problemas de desempenho. Para apps com o atributo de manifesto debuggable definido como verdadeiro, as invocações da API JobScheduler além das limitações de taxa retornarão RESULT_FAILURE. As limitações são definidas de forma que os casos de uso legítimos não sejam afetados.

Limpador do descritor do arquivo (fdsan)

O Android 10 introduziu o fdsan (limpador do descritor do arquivo). O fdsan detecta o uso incorreto da propriedade do descritor do arquivo, como uso após fechamento e fechamento duplo. O modo padrão do fdsan está mudando no Android 11. Agora, o fdsan é cancelado após a detecção de um erro. O comportamento anterior era registrar um aviso e continuar. Se você estiver vendo falhas no seu app devido a fdsan, consulte fdsan documentation.

Restrições da interface não SDK

O Android 11 inclui listas atualizadas de interfaces não SDK restritas baseadas na colaboração com desenvolvedores do Android e nos testes internos mais recentes. Antes de restringirmos interfaces não SDK, sempre que possível, garantimos que haja alternativas públicas disponíveis.

Caso seu app não seja voltado para o Android 11, talvez algumas dessas mudanças 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 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. Caso você não encontre 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 sobre as mudanças dessa versão do Android, consulte Atualizações para restrições para interfaces não SDK no Android 11. Para saber mais sobre interfaces não SDK em geral, consulte Restrições para interfaces não SDK.

Biblioteca compartilhada do Google Maps v1 removida

A V1 da biblioteca compartilhada do Google Maps foi completamente removida no Android 11. O uso dessa biblioteca foi suspenso anteriormente e deixou de funcionar para apps no Android 10. Apps que antes dependiam dessa biblioteca compartilhada para dispositivos com o Android 9 (API de nível 28) ou versões anteriores precisam usar o SDK do Google Maps para Android.

Interação com outros apps

Compartilhar URIs de conteúdo

Se o app compartilhar um URI de conteúdo com outro app, o intent precisará conceder permissões de acesso ao URI definindo pelo menos uma das seguintes sinalizações de intent: FLAG_GRANT_READ_URI_PERMISSION e FLAG_GRANT_WRITE_URI_PERMISSION. Assim, se o outro app for direcionado ao Android 11, ele ainda poderá acessar o URI de conteúdo. Seu app precisa incluir as sinalizações de intent mesmo quando o URI de conteúdo está associado a um provedor de conteúdo que não é seu.

Caso o app seja proprietário do provedor de conteúdo associado ao URI de conteúdo, verifique se o provedor de conteúdo não é exportado. Recomendamos essa prática de segurança.

Carregamento da biblioteca

Como carregar a biblioteca comum do ICU com um caminho absoluto

Os apps destinados à API 28 e versões anteriores não podem usar dlopen(3) para carregar libicuuc com o caminho absoluto "/system/lib/libicuuc.so". Para esses apps, dlopen("/system/lib/libicuuc.so", ...) vai retornar um identificador nulo.

Em vez disso, para carregar a biblioteca, use o nome da biblioteca como o nome do arquivo, por exemplo, dlopen("libicuuc.so", ...).