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 muitas mudanças e restrições para melhorar a privacidade do usuário. Para saber mais, consulte a página Privacidade.

Segurança

Executar criptografia baseada em arquivos após uma reinicialização do OTA sem credenciais de usuário

Depois que o dispositivo receber uma atualização OTA e reiniciar, as chaves criptografadas por credencial que são colocadas no armazenamento protegido por credencial ficam imediatamente disponíveis para operações de Criptografia baseada em arquivos (FBE, na sigla em inglês). Portanto, o app pode realizar ações relacionadas à criptografia baseada em arquivos antes que o usuário digite o PIN, o padrão ou a senha para desbloquear o dispositivo após a reinicialização.

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.

Câmera

Compatibilidade com o uso simultâneo de mais de uma câmera

O Android 11 traz APIs para consultar a compatibilidade com o uso de mais de uma câmera por vez, incluindo uma câmera frontal e traseira.

Para verificar a compatibilidade do dispositivo em que o app está sendo executado, use os seguintes métodos:

  • getConcurrentCameraIds() retorna um Set de combinações de IDs de câmera que podem transmitir simultaneamente com combinações de streaming garantidas quando configuradas pelo mesmo processo de aplicativo.
  • isConcurrentSessionConfigurationSupported() consulta se os dispositivos de câmera oferecem compatibilidade simultânea com as configurações das sessão correspondentes.

Conectividade

Abrir as mudanças na API Mobile

A partir do Android 11, a API Open Mobile (OMAPI) tem outras funcionalidades:

  • Analisar regras para privilégios de operadora.

  • Personalizar o acesso ao Elemento de segurança incorporado (eSE, na sigla em inglês) ou provisionar um eSE usando um ou mais dos seguintes itens:

    • Permissão privilegiada do sistema
    • Identificadores de aplicativo (AIDs, na sigla em inglês) configuráveis de Access Rule Application Master (ARA-M)
    • API do sistema para redefinir o leitor OMAPI
  • Forneça aos leitores um indicador claro de aplicativos para filtrar a capacidade dos dispositivos.

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.

Acessibilidade

Os leitores de tela exigem definições de ações de acessibilidade baseadas em cliques

Nas versões anteriores do Android, o framework enviava eventos de toque para widgets que não processavam corretamente as ações de acessibilidade com base em cliques. Normalmente, essas visualizações manipulam eventos de toque diretamente em vez de registrar um listener de cliques.

Para criar um comportamento mais consistente em apps que definem corretamente as ações de acessibilidade, o Android 11 nunca envia eventos de toque. Em vez disso, o sistema depende totalmente das ações de acessibilidade baseadas em cliques: ACTION_CLICK e ACTION_LONG_CLICK. Essa alteração afeta o comportamento dos leitores de tela.

O sistema processa widgets que usam as interfaces OnClickListener e OnLongClickListener. No entanto, se seu app usa um widget mais personalizado que depende da interface OnTouchListener, você precisa definir gerenciadores personalizados para as ações de acessibilidade com base em cliques. Para fazer isso, chame o método replaceAccessibilityAction() para cada ação, conforme mostrado no snippet de código a seguir:

Kotlin

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_CLICK,
            context.getString(R.string.select)
) { view, commandArguments ->
    selectText()
}

ViewCompat.replaceAccessibilityAction(
            WIDGET,
            ACTION_LONG_CLICK,
            context.getString(R.string.select_all)
) { view, commandArguments ->
    selectAllText()
}

Java

// Assumes that the widget is designed to select text when tapped and select
// all text when long-tapped. In its strings.xml file, this app has set
// "select" to "Select" and "select_all" to "Select all", respectively.
ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_CLICK,
        context.getString(R.string.select),
        (view, commandArguments) -> {
            selectText();
        });

ViewCompat.replaceAccessibilityAction(WIDGET, ACTION_LONG_CLICK,
        context.getString(R.string.select_all),
        (view, commandArguments) -> {
            selectAllText();
        });

Declarar o uso do botão de acessibilidade no arquivo de metadados

A partir do Android 11, o serviço de acessibilidade não pode declarar uma associação com o botão de acessibilidade do sistema no ambiente de execução. Se AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON for anexado à propriedade flags de um objeto AccessibilityServiceInfo, o framework não transmitirá eventos de callback do botão de acessibilidade do serviço.

Em vez disso, declare a associação do serviço de acessibilidade com o botão de acessibilidade usando a sinalização flagRequestAccessibilityButton no arquivo de metadados do serviço, normalmente res/raw/accessibilityservice.xml.

Interface do usuário

Mudanças em SYSTEM_ALERT_WINDOW

Há várias mudanças na forma como os apps recebem a permissão SYSTEM_ALERT_WINDOW. As mudanças visam proteger os usuários, tornando a concessão da permissão mais intencional.

Certos apps recebem a permissão SYSTEM_ALERT_WINDOW automaticamente quando a solicitam

Determinadas classes de app recebem a permissão SYSTEM_ALERT_WINDOW automaticamente quando a solicitam. Esses apps não precisam enviar ACTION_MANAGE_OVERLAY_PERMISSION para receber a permissão SYSTEM_ALERT_WINDOW. Eles podem simplesmente solicitar SYSTEM_ALERT_WINDOW de modo direto.

Todo app que tiver ROLE_CALL_SCREENING e solicitar SYSTEM_ALERT_WINDOW receberá a permissão automaticamente. Se o app perder ROLE_CALL_SCREENING, ele perderá a permissão.

Intents MANAGE_OVERLAY_PERMISSION sempre levam o usuário à tela de permissões do sistema

A partir do Android 11, as intents ACTION_MANAGE_OVERLAY_PERMISSION sempre levam o usuário para a tela Configurações de nível superior, em que é possível conceder ou revogar permissões SYSTEM_ALERT_WINDOW para apps. Todos os dados package: da intent são ignorados.

Em versões anteriores do Android, a intent ACTION_MANAGE_OVERLAY_PERMISSION poderia especificar um pacote, o que levaria o usuário a uma tela específica do app para gerenciar a permissão. Essa funcionalidade não é mais compatível no Android 11. Em vez disso, o usuário precisa selecionar o app para o qual quer conceder ou revogar a permissão. Essa mudança visa proteger os usuários, tornando a concessão de permissões mais intencional.

Compatibilidade de apps

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 restringir 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 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 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 public.

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.