O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Permissões de tempo de execução

No Android 6.0 e superior, o modelo de permissões do aplicativo Android é projetado para tornar as permissões mais compreensíveis, úteis e seguras para os usuários. O modelo moveu os 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 ao instalá-lo ou atualizá-lo. 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 o acesso do aplicativo a grupos de permissão específicos. OEMs / operadoras podem pré-instalar aplicativos, mas não podem pré-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 avisados ​​pela caixa de diálogo de permissões de tempo de execução para sempre permitir, 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 evitam que os aplicativos tenham 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 foram concedidos. 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 são permissões não perigosas, incluindo permissões normais, do sistema e de assinatura. Permissões normais são permissões de menor 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, 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 as 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 por hardware ou por software. 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 permitidas:

  • ( 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 é descrito na documentação pública para a permissão solicitada.

Ao instalar um aplicativo, o instalador (como Google Play Store) pode optar por não colocar as permissões restritas do aplicativo na lista de permissões. As permissões são restritas pela plataforma e só podem ser concedidas se um aplicativo atender a critérios especiais por política de plataforma. Exemplos de tipos de permissão de 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 está pré-instalado.
  • uma permissão é necessária para uma função já definida para colocar a permissão na lista de permissões.
  • o instalador (como Google Play Store) marca a permissão como lista branca.

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

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 de aplicativo incluem:

  • O modelo de permissão de tempo de execução deve ser consistente em todos os dispositivos com 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 no tempo de execução. Para obter detalhes, consulte Atualizar 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 permissão de acesso do telefone.) Para obter detalhes, consulte Criação de exceções .
  • Os aplicativos pré-carregados que têm 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 IU durante a instalação do aplicativo não deve se desviar da implementação AOSP de PermissionController, os usuários podem revogar permissões perigosas de aplicativos pré-instalados e assim por diante.
  • Os aplicativos sem periféricos 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 / segundo plano, consulte Alteração de privacidade do Android 10 , começando com Solicitar localização de 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 têm permissões pré-concedidas automaticamente. Incentivamos você a trabalhar 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 revogam permissões.

Aplicativos pré-carregados

No Android 9 e inferior, os aplicativos pré-carregados que usam permissões perigosas devem ter como alvo 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 IU 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 do 10, o fluxo de instalação (executado pelo aplicativo Package Installer ) é uma função separada da concessão de permissões (no aplicativo Permission Controller ).

Aplicativos sem cabeça

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

  • No Android 5.1 e anterior, os aplicativos headless podem solicitar permissões quando instalados ou se foram pré-instalados sem o uso de uma atividade.
  • No Android 6.0 e superior, os aplicativos sem cabeça 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 este método apenas quando precisar que a plataforma manipule 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.

Personalização da IU PackageInstaller

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

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

Criação de 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

Definição de permissões personalizadas

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

No Android 6.0 e posterior, se você adicionar uma nova permissão perigosa, ela deve 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 de Compatibility Test Suite (CTS) que verificam se as permissões individuais são mapeadas para os grupos corretos. Passar nesses testes é um requisito para compatibilidade com o Android 6.0 e posterior CTS.