No Android 6.0 e versões mais recentes, o modelo de permissões de apps do Android foi projetado para tornar as permissões mais compreensíveis, úteis e seguras para os usuários. O modelo mudou os apps Android que exigem permissões perigosas (consulte Permissões afetadas) de um modelo de permissão de instalação para um modelo de permissão de execução:
- Permissões da instalação
(Android 5.1 e versões anteriores) Os usuários concedem permissões perigosas a um app quando o instalam ou atualizam. Fabricantes de dispositivos e operadoras podem pré-instalar apps com permissões pré-concedidas sem notificar o usuário.
- Permissões de execução
(Android 6.0 a 9) Os usuários concedem permissões perigosas a um app quando ele está em execução. O momento em que as permissões são solicitadas (por exemplo, quando o app é iniciado ou quando o usuário acessa um recurso específico) depende do app, mas o usuário concede/nega o acesso do app a grupos de permissões específicos. OEMs/operadoras podem pré-instalar apps, mas não podem conceder permissões antecipadamente, a menos que passem pelo processo de exceção. Consulte Como criar exceções.
(Android 10) Os usuários têm mais transparência e controle sobre quais apps têm permissões de execução de reconhecimento de atividade (RA). A caixa de diálogo de permissões de execução solicita que os usuários sempre permitam, permitam durante o uso ou neguem as permissões. Em uma atualização do SO para o Android 10, as permissões concedidas aos apps são mantidas, mas os usuários podem acessar as Configurações e mudá-las.
As permissões de execução impedem que os apps tenham acesso a dados particulares sem o consentimento do usuário e oferecem mais contexto e visibilidade sobre os tipos de permissões que os apps estão buscando ou que foram concedidas. O modelo de execução incentiva os desenvolvedores a ajudar os usuários a entender por que os apps precisam das permissões solicitadas e oferece maior transparência para que os usuários possam tomar melhores decisões sobre a concessão ou recusa delas.
Permissões afetadas
O Android 6.0 e versões mais recentes exigem permissões perigosas para usar um modelo de permissões de execução.
Permissões perigosas são de alto risco (como READ_CALENDAR) que concedem
acesso a apps que solicitam dados particulares do usuário ou controle sobre um dispositivo, o que pode afetar
negativamente o usuário. Para conferir uma lista de permissões perigosas, execute o comando:
adb shell pm list permissions -g -d
O Android 6.0 e versões mais recentes não mudam o comportamento das permissões
normais. Todas essas permissões não são perigosas, incluindo permissões normais, do sistema e de assinatura. As permissões normais são de menor risco (como
SET_WALLPAPER) e concedem aos apps solicitantes acesso a recursos isolados
no nível do app, com risco mínimo para outros apps, o sistema ou o usuário. Como nas versões do Android 5.1 e
anteriores, o sistema concede automaticamente permissões normais a um app solicitante na
instalação e não solicita a aprovação do usuário. Para saber mais 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 não. Em ambos os casos, a permissão restrita também precisa estar na lista de permissões permitidas. As restrições rígidas fora da lista de permissões se comportam de maneira diferente das restrições fora da lista de permissões:
- (Restrições rígidas) Não é possível conceder permissões que não estejam na lista de permissões permitidas.
- (Restrições flexíveis) Os apps sem lista de permissões se comportam de acordo com a permissão específica que eles solicitam. O comportamento é descrito na documentação pública da permissão solicitada.
Ao instalar um app, o instalador (como a Google Play Store) pode selecionar para não permitir a lista de permissões restritas para o app. As permissões são restringidas pela plataforma e só podem ser concedidas se um app atender a critérios especiais de acordo com a política da plataforma. Exemplos de tipos de permissões com restrição rígida incluem permissões de SMS e registro de chamadas.
A inclusão na lista de permissões acontece durante a instalação e quando
- um app já está instalado durante um upgrade do Android 9 para o 10.
- uma permissão é concedida previamente ou um app é pré-instalado.
- uma permissão é necessária para que um papel já definido seja incluído na lista de permissões;
- o instalador (como a Google Play Store) marca a permissão como permitido.
Os usuários não podem adicionar manualmente as permissões à lista de permissões.
Requisitos
O modelo de permissão de execução se aplica a todos os apps, incluindo os pré-instalados e os enviados ao dispositivo como parte do processo de configuração. Os requisitos de software do app incluem:
- O modelo de permissão de execução precisa ser consistente em todos os dispositivos com o Android 6.0 ou mais recente. Isso é aplicado pelos testes do Teste de compatibilidade do Android (CTS, na sigla em inglês).
- Os apps precisam solicitar que os usuários concedam permissões no momento da execução. Para mais detalhes, consulte Atualizar
apps. Exceções limitadas podem ser concedidas a apps e processadores padrão
que oferecem funcionalidades básicas do dispositivo fundamentais para a operação esperada do dispositivo.
Por exemplo, o app Discador padrão do dispositivo para processar
ACTION_CALLpode ter acesso à permissão do telefone. Para mais detalhes, consulte Como criar exceções. - Os apps pré-carregados com permissões perigosas precisam ser criados para o nível 23 da API e manter o modelo de permissão de execução. Ou seja, o fluxo da interface durante a instalação do app não pode se desviar da implementação do AOSP do PermissionController. Os usuários podem revogar permissões perigosas de apps pré-instalados e assim por diante.
- Os apps sem cabeça precisam usar uma atividade para solicitar permissões ou compartilhar um UID com outro app que tenha as permissões necessárias. Para mais detalhes, consulte Apps sem cabeça.
Migração de permissões
As permissões concedidas a apps no Android 5.x continuam sendo concedidas após a atualização para o Android 6.0 ou mais recente, mas os usuários podem revogar essas permissões a qualquer momento.
Em uma atualização do Android 9 para o 10, todas as permissões com fortes restrições são incluídas na lista de permissões. Para saber mais sobre a implementação das permissões divididas em primeiro/segundo plano, consulte a mudança de privacidade do Android 10, começando com Solicitar a localização em segundo plano.
Integração
Ao integrar o modelo de permissões de execução do app para o Android 6.0 e versões mais recentes, é necessário
atualizar os apps pré-instalados para que funcionem com o novo modelo. Também é possível definir exceções para apps
que são gerenciadores/provedores padrão para a funcionalidade principal, definir permissões personalizadas e
personalizar o tema usado no app PermissionController.
Atualizar apps
Os apps na imagem do sistema e os pré-instalados não recebem automaticamente permissões. Recomendamos que você trabalhe com desenvolvedores de apps pré-instalados (OEM, operadora e terceiros) para fazer as modificações necessárias usando as diretrizes para desenvolvedores. Especificamente, é necessário garantir que os apps pré-instalados sejam modificados para evitar falhas e outros problemas quando os usuários revogarem as permissões.
Apps pré-carregados
No Android 9 e versões anteriores, os apps pré-carregados que usam permissões perigosas precisam ser destinados ao nível 23 da API
ou mais recente e manter o modelo de permissão do AOSP do Android 6.0 e versões mais recentes. Por exemplo, o fluxo da interface
durante uma instalação de app não pode se desviar da implementação do AOSP de
PermissionController. Os usuários podem até revogar as permissões perigosas de
apps 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 app Package
Installer) é uma função separada da concessão de permissões (no
app Permission Controller).
Apps 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 apps sem cabeça podem solicitar permissões quando são instalados ou se foram pré-instalados sem o uso de uma atividade.
- No Android 6.0 e versões mais recentes, os apps sem cabeça precisam usar um dos seguintes métodos para solicitar permissões:
- Adicione uma atividade para solicitar permissões. Esse é o método preferencial.
- Compartilhe um UID com outro app que tenha as permissões necessárias. Use esse método somente quando precisar que a plataforma processe vários APKs como um único app.
O objetivo é evitar confundir os usuários com solicitações de permissão que aparecem fora do contexto.
Personalizar a interface do PackageInstaller
Se quiser, você pode personalizar o tema da interface de permissões
atualizado os temas padrão do dispositivo (Theme.DeviceDefault.Settings
e Theme.DeviceDefault.Light.Dialog.NoActionBar) usados pelo
PackageInstaller. No entanto, como a consistência é fundamental para os desenvolvedores de apps,
não é possível personalizar a posição, a posição e as regras de quando a interface de usuário
de permissões aparece.
Para incluir strings em outros idiomas, faça contribuições para o AOSP.
Criar exceções
É possível conceder permissões antecipadamente a apps que são processadores 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
Definir permissões personalizadas
É possível definir permissões e grupos personalizados como normais ou perigosas e adicionar permissões específicas de OEM/operadora a grupos de permissões existentes, assim como nas versões do Android 5.x e anteriores.
No Android 6.0 e versões mais recentes, se você adicionar uma nova permissão perigosa, ela precisará ser processada da mesma forma que outras permissões perigosas (solicitadas durante a execução do app e revocáveis pelos usuários). Especificamente:
- É possível adicionar novas permissões a um grupo atual, mas não é possível modificar o mapeamento do AOSP de permissões e grupos de permissões perigosas. Em outras palavras, não é possível remover uma permissão de um grupo e atribuir a outro.
- É possível adicionar novos grupos de permissões em apps instalados no dispositivo, mas não no manifesto da plataforma.
Testar permissões
O Android inclui testes do conjunto de teste de compatibilidade (CTS) que verificam se as permissões individuais são mapeadas para os grupos corretos. A aprovação desses testes é um requisito para a compatibilidade com o CTS do Android 6.0 e versões mais recentes.
Revogar permissões
No Android 13 e versões mais recentes, é possível revogar as próprias permissões
de execução concedidas usando
Context.revokeSelfPermissionsOnKill().
A revogação ocorre de forma assíncrona e é acionada quando é seguro fazer isso sem interromper
o usuário. Quando a revogação é acionada, todos os processos em execução no UID de chamada são encerrados.
É importante entender que a revogação de uma única permissão pode não ser refletida na
interface de configurações, que trata as permissões por grupo. Normalmente, um grupo de permissões é mostrado como
concedido se pelo menos uma das permissões desse grupo for concedida. Se você quiser que os usuários
possam confirmar a revogação nas configurações, revogue todas as
permissões no grupo. Para saber quais permissões pertencem a um determinado grupo, use
PackageManager.getGroupOfPlatformPermission
e PackageManager.getPlatformPermissionsForGroup.
Quando o sistema revoga as permissões solicitadas, ele também revoga as permissões em segundo plano correspondentes se nenhuma das permissões em primeiro plano correspondentes ainda for concedida.
A revogação não é acionada enquanto o processo permanece em primeiro plano, mas pode
ser acionada imediatamente encerrando manualmente todos os processos em execução no uid atual, por
exemplo, usando System.exit().
No entanto, é recomendável deixar o sistema decidir quando acionar.
Depois que uma revogação de permissão for efetivada, você poderá solicitar novamente, e o usuário será instruído a conceder ou negar a solicitação. Não é possível solicitar uma permissão que já foi negada pelo usuário. Recomendamos que você revogue as permissões que você tem, mas que não são mais necessárias. No entanto, tome cuidado para não informar o usuário sobre a revogação até que ela entre em vigor.