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 manualmente as permissões da 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_CALLpode 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.
Revogando permissões
No Android 13 e posterior, 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 é 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 entender que a revogação de uma única permissão pode não ser refletida na interface do usuário 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 garantir que os usuários possam confirmar a revogação nas configurações for importante para você, revogue 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 de suas permissões de primeiro plano correspondentes ainda forem concedidas.
A revogação não será acionada enquanto o processo permanecer em primeiro plano, mas também pode ser acionado imediatamente eliminando manualmente todos os processos em execução no uid atual, por exemplo, usando System.exit() . No entanto, é recomendável deixar o sistema decidir quando ativá-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 anteriormente negada pelo usuário. Embora você seja encorajado a revogar as permissões que você possui atualmente, mas 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.