Permissões de tempo de execução

No Android 6.0 e superior, o modelo de permissões do aplicativo 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 de tempo de instalação para um modelo de permissão de tempo de execução :

  • Permissões de tempo de instalação

    ( Android 5.1 e inferior ) Os usuários concedem permissões perigosas a um aplicativo quando instalam ou atualizam o aplicativo. 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 o aplicativo 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 o 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). Os usuários são solicitados pela caixa de diálogo de permissões de tempo de execução a permitir sempre, permitir durante o uso ou negar 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 impedem que os aplicativos obtenham acesso a dados privados sem o consentimento do usuário e fornecem a eles contexto e visibilidade adicionais sobre os tipos de permissões que os aplicativos estão buscando ou 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 como conceder ou negar as permissões.

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 afetar negativamente o usuário. Para visualizar 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 . Essas são todas as permissões não perigosas, incluindo permissões normais, de sistema e de assinatura. As permissões normais são permissões de baixo risco (como SET_WALLPAPER ) que concedem aos aplicativos solicitantes acesso a recursos de nível de aplicativo isolados com risco mínimo para outros aplicativos, o sistema ou 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 a aprovação do usuário. Para obter detalhes sobre permissões, consulte a documentação do elemento <permission> .

Restrições rígidas e suaves 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 permitidas se comportam de maneira diferente das restrições flexíveis não permitidas:

  • ( Restrições rígidas ) Os aplicativos não podem receber permissões que não estejam na lista de permissões.
  • ( Restrições suaves ) Os aplicativos sem lista de permissões se comportam de acordo com a permissão específica que solicitam. O comportamento é 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 listar as permissões restritas do aplicativo. As permissões são restritas pela plataforma e são concedidas somente 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 na lista.
  • o instalador (como a Google Play Store) marca a permissão como permitida.

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

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 do 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 que os usuários 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 de 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 à permissão Telefone.) Para obter detalhes, consulte Criando exceções .
  • Os aplicativos pré-carregados com permissões perigosas devem ser direcionados à API de nível 23 e manter o modelo de permissão de tempo de execução. Ou seja, o fluxo da interface do usuário durante a instalação do aplicativo não deve se desviar 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 para 10, todas as permissões restritas são colocadas na lista de permissões. Para obter detalhes sobre como implementar as permissões de divisão de primeiro plano/fundo, 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 do aplicativo para Android 6.0 e superior, você deve atualizar os aplicativos pré-instalados para funcionar 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 são permissões pré-concedidas automaticamente. Recomendamos que você trabalhe com desenvolvedores de aplicativos pré-instalados (OEM, operadora e terceiros) para fazer as modificações de aplicativos necessárias 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 revogam as permissões.

Aplicativos pré-carregados

No Android 9 e inferior, os aplicativos pré-carregados que usam permissões perigosas devem segmentar a API de nível 23 ou superior e manter o modelo de permissão AOSP do Android 6.0 e superior. Por exemplo, o fluxo da interface do usuário durante a instalação de um aplicativo não deve se desviar da implementação AOSP de PermissionController . Os usuários podem até revogar as 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 de 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 forem 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 de contexto.

Personalizando a interface do usuário do PackageInstaller

Se desejar, você pode personalizar o tema Permissions UI 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 é fundamental para os desenvolvedores de aplicativos, você não pode personalizar o posicionamento, a posição e as regras de quando a interface do usuário de permissões é exibida.

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

Criando exceções

Você pode conceder permissões previamente a aplicativos que são manipuladores ou provedores padrão para a funcionalidade principal do SO 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 no Android 5.xe versões anteriores.

No Android 6.0 e posterior, 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 atribuir 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.

Permissões de teste

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