O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 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 como 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 leves no Android 10

Além de ser perigosa, uma permissão pode ser restrita de forma rígida 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 é 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 na lista de permissões as permissões restritas para o aplicativo. As permissões são restritas pela plataforma e podem ser concedidas apenas 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 que já está 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 colocar permissões na lista de 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 de aplicativo incluem:

  • O modelo de permissão de tempo de execução deve ser consistente em todos os dispositivos que executam 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 aplicativos 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 .
  • 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 o nível 23 da API 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 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.

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 o 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 CTS posterior.