Permissões de tempo de execução

No Android 6.0 e versões posteriores, o modelo de permissões de aplicativos Android foi projetado para tornar as permissões mais compreensíveis, úteis e seguras para os usuários. O modelo moveu aplicativos Android que exigem permissões perigosas (consulte Permissões afetadas ) de um modelo de permissão em tempo de instalação para um modelo de permissão em tempo de execução :

  • Permissões no momento da instalação

    ( Android 5.1 e inferior ) Os usuários concedem permissões perigosas a um aplicativo quando o instalam ou atualizam. Os fabricantes e operadoras de dispositivos podem pré-instalar aplicativos com permissões pré-concedidas sem notificar o usuário.

  • Permissões de tempo de execução

    ( Android 6.0 – 9 ) Os usuários concedem permissões perigosas a um aplicativo quando ele está em execução. Quando as permissões são solicitadas (como quando o aplicativo é iniciado ou quando o usuário acessa um recurso específico) depende do aplicativo, mas o usuário concede/nega acesso do aplicativo a grupos de permissões específicos. OEMs/operadoras podem pré-instalar aplicativos, mas não podem conceder permissões a menos que passem pelo processo de exceção. (Consulte Criando exceções .)

    ( Android 10 ) Os usuários veem maior transparência e têm controle sobre quais aplicativos têm permissões de tempo de execução de reconhecimento de atividade (AR). A caixa de diálogo de permissões de tempo de execução solicita aos usuários que sempre permitam, permitam durante o uso ou negem permissões. Em uma atualização do sistema operacional para o Android 10, as permissões concedidas aos aplicativos são mantidas, mas os usuários podem acessar as Configurações e alterá-las.

As permissões de tempo de execução evitam que os aplicativos obtenham acesso a dados privados sem o consentimento do usuário e fornecem contexto e visibilidade adicionais sobre os tipos de permissões que os aplicativos estão buscando ou que receberam. O modelo de tempo de execução incentiva os desenvolvedores a ajudar os usuários a entender por que os aplicativos exigem as permissões solicitadas e fornece maior transparência para que os usuários possam tomar melhores decisões sobre concedê-las ou negá-las.

Permissões afetadas

O Android 6.0 e superior requer permissões perigosas para usar um modelo de permissões de tempo de execução. Permissões perigosas são permissões de alto risco (como READ_CALENDAR ) que concedem aos aplicativos solicitantes acesso a dados privados do usuário ou controle sobre um dispositivo, o que pode impactar negativamente o usuário. Para ver uma lista de permissões perigosas, execute o comando:

adb shell pm list permissions -g -d

O Android 6.0 e superior não altera o comportamento das permissões normais . Todas essas permissões não são perigosas, incluindo permissões normais, de sistema e de assinatura. Permissões normais são permissões de baixo risco (como SET_WALLPAPER ) que concedem aos aplicativos solicitantes acesso a recursos isolados no nível do aplicativo com risco mínimo para outros aplicativos, para o sistema ou para o usuário. Como no Android 5.1 e versões anteriores, o sistema concede automaticamente permissões normais a um aplicativo solicitante na instalação e não solicita aprovação do usuário. Para obter detalhes sobre permissões, consulte a documentação do elemento <permission> .

Restrições rígidas e flexíveis no Android 10

Além de ser perigosa, uma permissão pode ser restrita ou restrita. Em ambos os casos, a permissão restrita também deve estar na lista de permissões. As restrições rígidas não incluídas na lista de permissões se comportam de maneira diferente das restrições flexíveis não incluídas na lista de permissões:

  • ( Restrições rígidas ) Os aplicativos não podem receber permissões que não estejam na lista de permissões.
  • ( Restrições leves ) Os aplicativos sem lista de permissões se comportam de acordo com a permissão específica que solicitam. O comportamento está descrito na documentação pública da permissão solicitada.

Ao instalar um aplicativo, o instalador (como a Google Play Store) pode optar por não permitir as permissões restritas do aplicativo. As permissões são restritas pela plataforma e só podem ser concedidas se um aplicativo atender a critérios especiais de acordo com a política da plataforma. Exemplos de tipos de permissão com restrição rígida incluem permissões de SMS e registro de chamadas.

A lista de permissões acontece durante a instalação e quando

  • um aplicativo já está instalado durante uma atualização do Android 9 para 10.
  • uma permissão é pré-concedida ou um aplicativo é pré-instalado.
  • uma permissão é necessária para uma função que já está definida para permitir a permissão.
  • o instalador (como Google Play Store) marca a permissão como permitida.

Os usuários não podem permitir permissões manualmente.

Requisitos

O modelo de permissão de tempo de execução se aplica a todos os aplicativos, incluindo aplicativos pré-instalados e aplicativos entregues ao dispositivo como parte do processo de configuração. Os requisitos de software aplicativo incluem:

  • O modelo de permissão de tempo de execução deve ser consistente em todos os dispositivos que executam o Android 6.0 e superior. Isso é aplicado pelos testes do Android Compatibility Test Suite (CTS).
  • Os aplicativos devem solicitar aos usuários que concedam permissões de aplicativo em tempo de execução. Para obter detalhes, consulte Atualizando aplicativos . Exceções limitadas podem ser concedidas a aplicativos e manipuladores padrão que fornecem funcionalidade básica do dispositivo, fundamental para a operação esperada do dispositivo. (Por exemplo, o aplicativo Discador padrão do dispositivo para lidar com ACTION_CALL pode ter acesso de permissão de telefone.) Para obter detalhes, consulte Criando exceções .
  • Os aplicativos pré-carregados que possuem permissões perigosas devem ter como alvo o nível 23 da API e manter o modelo de permissão de tempo de execução. Ou seja, o fluxo da UI durante a instalação do aplicativo não deve desviar-se da implementação AOSP do PermissionController, os usuários podem revogar permissões perigosas de aplicativos pré-instalados e assim por diante.
  • Os aplicativos headless devem usar uma atividade para solicitar permissões ou compartilhar um UID com outro aplicativo que tenha as permissões necessárias. Para obter detalhes, consulte Aplicativos sem cabeça .

Migração de permissões

As permissões concedidas a aplicativos no Android 5.x permanecem concedidas após a atualização para o Android 6.0 ou superior, mas os usuários podem revogar essas permissões a qualquer momento.

Em uma atualização do Android 9 a 10, todas as permissões restritas são colocadas na lista de permissões. Para obter detalhes sobre a implementação das permissões de divisão em primeiro plano/segundo plano, consulte Alteração de privacidade do Android 10 , começando com Solicitar localização em segundo plano .

Integração

Ao integrar o modelo de permissões de tempo de execução de aplicativos para Android 6.0 e superior, você deve atualizar os aplicativos pré-instalados para funcionarem com o novo modelo. Você também pode definir exceções para aplicativos que são os manipuladores/provedores padrão para a funcionalidade principal, definir permissões personalizadas e personalizar o tema usado no aplicativo PermissionController .

Atualizando aplicativos

Os aplicativos na imagem do sistema e os aplicativos pré-instalados não recebem permissões pré-concedidas automaticamente. Recomendamos que você trabalhe com desenvolvedores de aplicativos pré-instalados (OEM, operadora e terceiros) para fazer as modificações necessárias no aplicativo usando as diretrizes do desenvolvedor . Especificamente, você deve garantir que os aplicativos pré-instalados sejam modificados para evitar travamentos e outros problemas quando os usuários revogarem permissões.

Aplicativos pré-carregados

No Android 9 e versões anteriores, os aplicativos pré-carregados que usam permissões perigosas devem ter como alvo o nível de API 23 ou superior e manter o modelo de permissão AOSP do Android 6.0 e superior. Por exemplo, o fluxo da IU durante a instalação de um aplicativo não deve desviar-se da implementação AOSP de PermissionController . Os usuários podem até revogar permissões perigosas de aplicativos pré-instalados.

No Android 6.0 a 9, algumas permissões são concedidas durante o fluxo de instalação. No entanto, a partir da versão 10, o fluxo de instalação (realizado pelo aplicativo Package Installer ) é uma função separada da concessão de permissões (no aplicativo Permission Controller ).

Aplicativos sem cabeça

Somente atividades podem solicitar permissões. Os serviços não podem solicitar permissões diretamente.

  • No Android 5.1 e versões anteriores, os aplicativos headless podem solicitar permissões quando instalados ou se tiverem sido pré-instalados sem o uso de uma atividade.
  • No Android 6.0 e superior, os aplicativos headless devem usar um dos seguintes métodos para solicitar permissões:
    • Adicione uma atividade para solicitar permissões. (Este é o método preferido.)
    • Compartilhe um UID com outro aplicativo que tenha as permissões necessárias. Use esse método somente quando precisar que a plataforma lide com vários APKs como um único aplicativo.

O objetivo é evitar confundir os usuários com solicitações de permissão que aparecem fora do contexto.

Personalizando a IU do PackageInstaller

Se desejar, você pode personalizar o tema da UI de permissões atualizando os temas de dispositivo padrão ( Theme.DeviceDefault.Settings e Theme.DeviceDefault.Light.Dialog.NoActionBar ) usados ​​pelo PackageInstaller. No entanto, como a consistência é crítica para desenvolvedores de aplicativos, não é possível personalizar o posicionamento, a posição e as regras de quando a interface de usuário de permissões aparece.

Para incluir strings para idiomas adicionais, contribua com as strings para o AOSP.

Criando exceções

Você pode pré-conceder permissões a aplicativos que são manipuladores ou provedores padrão para a funcionalidade principal do sistema operacional usando a classe DefaultPermissionGrantPolicy.java no PackageManager. Exemplos:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definindo permissões personalizadas

Você pode definir permissões e grupos personalizados como normais ou perigosos e adicionar permissões específicas de OEM/operadora a grupos de permissões existentes, assim como faria no Android 5.x e versões anteriores.

No Android 6.0 e versões posteriores, se você adicionar uma nova permissão perigosa, ela deverá ser tratada da mesma forma que outras permissões perigosas (solicitadas durante o tempo de execução do aplicativo e revogáveis ​​pelos usuários). Especificamente:

  • Você pode adicionar novas permissões a um grupo atual, mas não pode modificar o mapeamento AOSP de permissões perigosas e grupos de permissões perigosas. (Em outras palavras, você não pode remover uma permissão de um grupo e atribuí-la a outro grupo).
  • Você pode adicionar novos grupos de permissões em aplicativos instalados no dispositivo, mas não pode adicionar novos grupos de permissões no manifesto da plataforma.

Testando permissões

O Android inclui testes do Compatibility Test Suite (CTS) que verificam se as permissões individuais estão mapeadas para os grupos corretos. Passar nesses testes é um requisito para compatibilidade com Android 6.0 e CTS posterior.

Revogando permissões

No Android 13 e versões posteriores, você pode revogar suas próprias permissões de tempo de execução concedidas usando Context.revokeSelfPermissionsOnKill() . A revogação acontece de forma assíncrona e é acionada quando for seguro fazê-lo sem interromper o usuário. Quando a revogação for acionada, todos os processos em execução no UID de chamada serão eliminados.

É importante compreender que a revogação de uma única permissão pode não ser refletida na IU de configurações, que trata as permissões por grupo. Normalmente, um grupo de permissões será exibido como concedido desde que pelo menos uma das permissões desse grupo seja concedida. Se for importante para você garantir que os usuários possam confirmar a revogação nas configurações, certifique-se de revogar todas as permissões no grupo de permissões. Para saber quais permissões pertencem a um determinado grupo, você pode usar PackageManager.getGroupOfPlatformPermission e PackageManager.getPlatformPermissionsForGroup .

Quando o sistema revoga as permissões solicitadas, ele também revoga as permissões de segundo plano correspondentes se nenhuma das permissões de primeiro plano correspondentes ainda for concedida.

A revogação não será acionada enquanto o processo permanecer em primeiro plano, mas também pode ser acionada imediatamente eliminando manualmente todos os processos em execução no uid atual, por exemplo, usando System.exit() . No entanto, é recomendado deixar o sistema decidir quando acioná-lo.

Depois que uma revogação de permissão entrar em vigor, você poderá solicitá-la novamente e o usuário será solicitado a conceder ou negar a solicitação. Não é possível solicitar uma permissão que tenha sido anteriormente negada pelo usuário. Embora você seja incentivado a revogar permissões que possui atualmente, mas que não são mais necessárias, você deve ter cuidado para não informar o usuário sobre a revogação até que ela entre em vigor.