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

Visão geral de permissões

O objetivo de uma permissão é proteger a privacidade de um usuário do Android. Apps para Android precisam solicitar permissão para acessar dados confidenciais do usuário (como contatos e SMS), bem como recursos específicos do sistema (como câmera e Internet). Dependendo do recurso, o sistema pode conceder a permissão automaticamente ou pedir ao usuário que aprove a solicitação.

Um dos pontos de projeto centrais da arquitetura de segurança do Android é que, por padrão, nenhum app tem permissão de realizar nenhuma operação que prejudique outros apps, o sistema operacional ou o usuário. Isso abrange a leitura e a gravação de dados privados do usuário (como contatos ou e-mails), leitura ou gravação dos arquivos de outro app, realização de acesso de rede, manter o dispositivo ativo etc.

Esta página fornece uma visão geral de como as permissões do Android funcionam, incluindo: como as permissões são apresentadas ao usuário, a diferença entre as solicitações de permissão no momento da instalação e da execução, como as permissões são aplicadas e os tipos de permissão e os respectivos grupos. Se você quiser apenas um guia com instruções de como usar permissões do app, consulte Solicitar permissões do app.

Aprovação de permissão

Um app precisa divulgar as permissões necessárias incluindo tags <uses-permission> no manifesto do app. Por exemplo, um app que precisa enviar mensagens SMS teria a seguinte linha no manifesto:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.snazzyapp">

    <uses-permission android:name="android.permission.SEND_SMS"/>

    <application ...>
        ...
    </application>
</manifest>

Caso seu app liste permissões normais no manifesto (ou seja, permissões que não apresentam muito risco à privacidade do usuário nem à operação do dispositivo), o sistema concederá automaticamente essas permissões.

Caso seu app liste permissões perigosas no manifesto (ou seja, permissões que possam afetar a privacidade do usuário ou a operação do dispositivo), como a permissão SEND_SMS acima, o usuário precisa concordar explicitamente em conceder essas permissões.

Para saber mais sobre permissões normais e perigosas, consulte Níveis de proteção.

Prompts de solicitação de permissões perigosas

Apenas as permissões perigosas exigem consentimento do usuário. A maneira como o Android pede que o usuário conceda permissões perigosas depende da versão do Android que está sendo executada no dispositivo do usuário e da versão do sistema segmentada pelo seu app.

Solicitações no tempo de execução (Android 6.0 e versões mais recentes)

Se o dispositivo estiver executando o Android 6.0 (API de nível 23) ou mais recente, e o targetSdkVersion do app for 23 ou versões mais recentes, o usuário não receberá nenhuma notificação sobre permissões do app no momento da instalação. O app precisa pedir que o usuário conceda permissões perigosas no momento da execução. Quando o app solicitar permissão, o usuário verá uma caixa de diálogo do sistema (como mostrado na figura 1, à esquerda) informando qual grupo de permissões o app está tentando acessar. A caixa de diálogo inclui os botões Negar e Permitir.

Se o usuário negar a solicitação de permissão, na próxima vez que o app solicitar a permissão, a caixa de diálogo terá uma caixa de seleção que, quando marcada, indica que o usuário não quer que a permissão seja solicitada novamente (veja a figura 1, à direita).

Figura 1. Caixa de diálogo de permissão inicial (esquerda) e solicitação de permissão secundária com opção para desativar outras solicitações (direita).

Se o usuário marcar a caixa Não perguntar novamente e tocar em Negar, o sistema não pedirá mais a permissão ao usuário se o app tentar solicitar a mesma permissão posteriormente.

Mesmo que o usuário conceda a permissão solicitada ao app, você nem sempre poderá confiar nela. Os usuários também têm a opção de ativar e desativar as permissões individualmente nas configurações do sistema. Sempre verifique e solicite permissões no tempo de execução para se proteger contra erros de tempo de execução (SecurityException).

Para mais detalhes sobre como lidar com solicitações de permissão no momento da execução, consulte Solicitar permissões do app.

Solicitações no momento da instalação (Android 5.1.1 e versões anteriores)

Se o dispositivo estiver executando o Android 5.1.1 (API de nível 22) ou anterior, ou o targetSdkVersion do app for 22 ou anterior, durante a execução em qualquer versão do Android, o sistema solicitará automaticamente que o usuário conceda todas as permissões perigosas para seu app no momento da instalação (veja a figura 2).

Figura 2. Caixa de diálogo de permissão no momento da instalação.

Se o usuário clicar em Aceitar, todas as permissões solicitadas pelo app serão concedidas. Se o usuário negar a solicitação de permissões, o sistema cancelará a instalação do app.

Se uma atualização do app incluir a necessidade de outras permissões, será solicitado que o usuário aceite essas novas permissões antes de atualizar o app.

Para ter uma visão geral dos padrões de experiência do usuário recomendados para solicitar permissões, consulte Práticas recomendadas de permissões do app.

Para saber como procurar e solicitar permissões do usuário, consulte Solicitar permissões do app.

Prompts de solicitação para acessar informações confidenciais do usuário

Alguns apps dependem do acesso a informações confidenciais do usuário relacionadas a registros de chamadas e mensagens SMS. Se você quiser solicitar permissões especificamente para registros de chamadas e mensagens SMS e publicar seu app na Play Store, precisará solicitar que o usuário configure seu app como o gerenciador padrão de uma função principal do sistema antes de solicitar permissões no momento da execução.

Para ver mais informações sobre gerenciadores padrão, incluindo orientações sobre como mostrar uma solicitação de gerenciador padrão para o usuário, consulte o guia sobre permissões usadas somente em gerenciadores padrão.

Permissões para recursos opcionais de hardware

O acesso a alguns recursos de hardware (como Bluetooth ou câmera) exige uma permissão do app. No entanto, nem todos os dispositivos Android realmente têm esses recursos de hardware. Portanto, se o app solicitar a permissão CAMERA, é importante também incluir a tag <uses-feature> no manifesto para declarar se esse recurso é realmente necessário. Por exemplo:

<uses-feature android:name="android.hardware.camera" android:required="false" />

Se você declarar android:required="false" para o recurso, o Google Play permitirá que o app seja instalado em dispositivos que não tenham o recurso. Em seguida, você precisa verificar se o dispositivo atual tem o recurso em tempo de execução chamando PackageManager.hasSystemFeature() e desativá-lo se ele não estiver disponível.

Se você não fornecer a tag <uses-feature>, quando o Google Play perceber que o app solicita a permissão correspondente, ele presumirá que o app precisa desse recurso. Portanto, o app não estará disponível nos dispositivos sem o recurso, como se você tivesse declarado android:required="true" na tag <uses-feature>.

Para saber mais, consulte Google Play e filtragem baseada em recurso.

Permissões únicas

A partir do Android 11 (nível 30 da API), sempre que seu app solicitar uma permissão relacionada à localização, ao microfone ou à câmera, a caixa de diálogo de permissões voltada ao usuário conterá uma opção chamada Somente desta vez. Se o usuário selecionar essa opção na caixa de diálogo, seu app receberá uma permissão única temporária.

O app poderá acessar os dados relacionados por um período que depende do comportamento do app e das ações do usuário:

  • Enquanto a atividade do seu app estiver visível, ele poderá acessar os dados.
  • Se o usuário colocar o app em segundo plano, o app poderá continuar acessando os dados por um curto período.
  • Se um serviço for iniciado em primeiro plano enquanto a atividade estiver visível, e o usuário mover o app para o segundo plano, o app continuará acessando os dados relacionados até que o serviço em primeiro plano seja interrompido.
  • Se o usuário revogar a permissão única, nas configurações do sistema, por exemplo, o app não poderá acessar os dados, independentemente de um serviço ter sido iniciado em primeiro plano. Como acontece com qualquer permissão, se o usuário revogar a permissão única do app, o processo do app será encerrado.

Quando o usuário abrir o app e um recurso dele solicitar acesso à localização, ao microfone ou à câmera, o usuário receberá a solicitação novamente.

Aplicação de permissões

Permissões não servem apenas para solicitar recursos do sistema. Os serviços fornecidos pelos apps podem aplicar permissões personalizadas para restringir quem pode usá-los. Para mais informações sobre como declarar permissões personalizadas, consulte Definir uma permissão personalizada do app.

Aplicação de permissão de atividade

As permissões aplicadas usando o atributo android:permission na tag <activity> no manifesto restringem quem pode iniciar esse Activity. A permissão é verificada durante Context.startActivity() e Activity.startActivityForResult(). Se o autor da chamada não tiver a permissão necessária, SecurityException será gerada a partir da chamada.

Aplicação de permissão de serviços

As permissões aplicadas usando o atributo android:permission na tag <service> no manifesto restringem quem pode iniciar ou se vincular ao Service associado. A permissão é verificada durante Context.startService(), Context.stopService() e Context.bindService(). Se o autor da chamada não tiver a permissão necessária, SecurityException será gerada a partir da chamada.

Aplicação de permissão de transmissão

As permissões aplicadas usando o atributo android:permission na tag <receiver> restringem quem pode enviar transmissões para o BroadcastReceiver associado. A permissão é verificada depois que Context.sendBroadcast() retorna, enquanto o sistema tenta entregar a transmissão enviada a um determinado receptor. Como resultado, uma falha de permissão não resulta em uma exceção retornada ao autor da chamada. Ela apenas não exibe o Intent.

Da mesma forma, é possível fornecer uma permissão a Context.registerReceiver() para controlar quem pode transmitir para um receptor registrado programaticamente. Por outro lado, uma permissão pode ser concedida ao chamar Context.sendBroadcast() para restringir quais broadcast receivers podem receber a transmissão.

Observe que, tanto um receptor quanto um transmissor podem exigir uma permissão. Quando isso acontece, as duas verificações de permissão precisam passar pela intent para serem entregues ao destino associado. Para saber mais, consulte Restringir transmissões com permissões.

Aplicação de permissão do provedor de conteúdo

As permissões aplicadas usando o atributo android:permission na tag <provider> restringem quem pode acessar os dados em um ContentProvider. Provedores de conteúdo têm uma unidade de segurança adicional importante chamada permissões de URI, descrita a seguir. Diferente de outros componentes, há dois atributos separados de permissão que se podem definir: android:readPermission restringe quem pode ler dados no provedor e android:writePermission restringe quem pode gravar nele. Observe que, se um provedor é protegido com as permissões de leitura e gravação, a permissão de gravação sozinha não significa que seja possível ler dados de um provedor.

As permissões são verificadas quando você recupera um provedor pela primeira vez (se você não tiver nenhuma permissão, uma SecurityException será devolvida) e à medida que você realizar operações no provedor. O uso de ContentResolver.query() exige que se tenha a permissão de leitura; o uso de ContentResolver.insert(), ContentResolver.update() e ContentResolver.delete() exige a permissão de gravação. Em todos esses casos, não ter a permissão exigida resulta em uma SecurityException gerada pela chamada.

Permissões de URI

O sistema de permissão padrão descrito até agora não é suficiente quando usado com provedores de conteúdo. Um provedor de conteúdo pode querer se proteger com permissões de leitura e gravação, enquanto clientes diretos também precisam usar URIs específicos e outros apps para que possam operar.

Um exemplo típico são os anexos em um app de e-mail. O acesso aos e-mails deve ser protegido por permissões, porque esses dados são confidenciais. No entanto, se um URI para um anexo de imagem for concedido a um visualizador de imagens, esse visualizador não terá mais a permissão para abrir o anexo, porque não há motivo para reter uma permissão para acessar todos os e-mails.

A solução para este problema são permissões por URI: ao iniciar uma atividade ou retornar um resultado para uma atividade, o autor da chamada pode definir Intent.FLAG_GRANT_READ_URI_PERMISSION e/ou Intent.FLAG_GRANT_WRITE_URI_PERMISSION. Isso concede à permissão de atividade recebida o acesso ao URI de dados específicos na intent, independentemente se ele tem ou não a permissão para acessar os dados no provedor de conteúdo correspondente à intent.

Esse mecanismo permite um modelo de estilo de capacidade comum em que a interação do usuário (como abrir um anexo ou selecionar um contato da lista) oferece a concessão ad-hoc de permissão detalhada. Esse pode ser um recurso fundamental para reduzir as permissões de que os apps necessitam apenas àquelas diretamente relacionadas ao comportamento.

Para criar a implementação mais segura que torna outros apps responsáveis por suas ações no app, use permissões refinadas dessa maneira e declare a compatibilidade do app com o atributo android:grantUriPermissions ou a tag <grant-uri-permissions>.

Mais informações podem ser encontradas nos métodos Context.grantUriPermission(), Context.revokeUriPermission() e Context.checkUriPermission().

Outras aplicações de permissão

Permissões detalhadas arbitrariamente podem ser aplicadas a qualquer chamada a um serviço. Isto é realizado com o método Context.checkCallingPermission(). Realize uma chamada com uma string de permissão desejada e ela retornará um número inteiro indicando se essa permissão foi concedida ao processo de chamada atual. Essa opção só pode ser usada ao realizar uma chamada vinda de outro processo, geralmente por uma interface IDL publicada por um serviço ou de alguma outra forma, dependendo do processo.

Há várias outras formas úteis de verificar permissões. Se você tiver o ID do processo (PID, na sigla em inglês) de outro processo, poderá usar o método Context.checkPermission() para verificar uma permissão para esse PID. Se você tiver o nome do pacote de outro app, poderá usar o método PackageManager.checkPermission() para descobrir se esse pacote específico recebeu uma permissão específica.

Redefinir automaticamente as permissões de apps não usados

Se o app for direcionado ao Android 11 (nível 30 da API) ou a versões mais recentes e não for usado por alguns meses, o sistema protegerá os dados do usuário redefinindo automaticamente as permissões confidenciais que o usuário concedeu a ele. Essa ação tem o mesmo efeito que se o usuário visualizasse uma permissão nas configurações do sistema e mudasse o nível de acesso do app para Negar.

Se o app seguir as práticas recomendadas para solicitar permissões no tempo de execução, não será preciso fazer alterações nele.

Solicitar que o usuário desative a redefinição automática

Se necessário, você pode pedir ao usuário para impedir que o sistema redefina as permissões do seu app. Isso é útil em situações em que os usuários esperam que o app funcione principalmente em segundo plano, mesmo sem o usuário interagir com o app, como nos seguintes casos de uso:

Figura 3. O usuário desativou a redefinição automática de permissões para determinado app.
  • Fornecer segurança familiar
  • Sincronizar dados
  • Comunicar-se com dispositivos inteligentes
  • Parear com dispositivos complementares

Para direcionar o usuário para a página do app nas configurações do sistema, chame uma intent que inclua a ação Intent.ACTION_AUTO_REVOKE_PERMISSIONS. Nessa tela, os usuários podem impedir que o sistema redefina as permissões do app fazendo o seguinte:

  1. Toque em Permissões, que carrega a tela de configurações Permissões do app.
  2. Desative a opção denominada Remover permissões se o app não for usado, como mostrado na Figura 3.

Determinar se a redefinição automática está desativada

Para verificar se a funcionalidade de redefinição automática está desativada para seu app, chame isAutoRevokeWhitelisted(). Se esse método retornar true, o sistema não redefinirá automaticamente as permissões do app.

Testar o recurso de redefinição automática

Para verificar se o sistema redefine as permissões do app, faça o seguinte:

  1. Salve o tempo padrão que o sistema aguarda para redefinir as permissões de um app. Dessa forma, você pode restaurá-lo após o teste:

    threshold=$(adb shell device_config get permissions \
      auto_revoke_unused_threshold_millis2)
    
  2. Reduza o tempo que o sistema aguarda para redefinir as permissões. No exemplo a seguir, o sistema é modificado para redefinir as permissões de um app apenas um segundo depois que você parar de interagir com um app:

    adb shell device_config put permissions \
      auto_revoke_unused_threshold_millis2 1000
    
  3. Invoque o processo de redefinição automática manualmente, conforme mostrado no snippet a seguir. Certifique-se de que o dispositivo de teste esteja ligado por um curto período, cerca de 45 segundos, antes de executar este comando.

    adb shell cmd jobscheduler run -u 0 -f \
      com.google.android.permissioncontroller 2
    
  4. Verifique se o app pode processar o evento de redefinição automática.

  5. Restaure o tempo padrão que o sistema aguarda antes de redefinir automaticamente as permissões de um app:

    adb shell device_config put permissions \
      auto_revoke_unused_threshold_millis2 $threshold
    

Conceder novas permissões automaticamente

Com o tempo, novas restrições podem ser adicionadas à plataforma de modo que, para usar determinadas APIs, seu app precise solicitar uma permissão que não tinha anteriormente. Como os apps existentes presumem que o acesso a essas APIs está disponível livremente, o Android pode aplicar a nova solicitação de permissão ao manifesto do app para evitar erros na versão da nova plataforma (assim, permitindo que seu app herde a permissão). O Android decide se um app precisará da permissão com base no valor fornecido para o atributo targetSdkVersion. Se o valor for menor que a versão à qual a permissão foi adicionada, o Android adicionará a permissão.

Por exemplo, a permissão READ_EXTERNAL_STORAGE será aplicada a partir da API de nível 19 para restringir o acesso ao espaço de armazenamento compartilhado. Se o targetSdkVersion for igual ou anterior a 18, essa permissão será adicionada ao seu app em versões mais recentes do Android.

Cuidado: se uma permissão for adicionada automaticamente ao app, os detalhes do app no Google Play listam as permissões adicionais mesmo que o app não as exija. Para evitar isso e remover as permissões padrão desnecessárias, atualize sempre o targetSdkVersion para a versão mais recente possível. É possível ver as permissões adicionadas com cada lançamento na documentação Build.VERSION_CODES.

Níveis de proteção

As permissões são divididas em vários níveis de proteção. O nível de proteção indica se são necessárias solicitações de permissão no momento da execução ou não.

Três níveis de proteção afetam os apps de terceiros: permissões normais, de assinatura e perigosas. Para ver o nível de proteção que uma permissão específica possui, visite a página de referência da API de permissões.

Permissões normais

Permissões normais abrangem áreas em que seu app precisa acessar dados ou recursos fora da sandbox do app, mas apresenta pouco risco à privacidade do usuário ou à operação de outros apps. Por exemplo, a permissão para definir o fuso horário é normal.

Se um app declarar no manifesto que precisa de uma permissão normal, o sistema automaticamente concederá essa permissão no momento da instalação. O sistema não solicita que o usuário conceda permissões normais e os usuários não podem revogar essas permissões.

Permissões de assinatura

O sistema concede essas permissões do app no momento da instalação, mas apenas quando o app que tenta usar a permissão é assinado pelo mesmo certificado que o app que define a permissão.

Permissões perigosas

Permissões perigosas abrangem áreas em que o app precisa de dados ou recursos que envolvem informações pessoais do usuário ou que podem afetar os dados armazenados do usuário ou a operação de outros aps. Por exemplo: a capacidade de ler os contatos do usuário é uma permissão perigosa. Se um app declarar que precisa de uma permissão perigosa, o usuário precisará conceder explicitamente a permissão. Até que o usuário aprove a permissão, o app não poderá fornecer funcionalidades que dependam dessa permissão.

Para usar uma permissão perigosa, o app precisa solicitar ao usuário que conceda permissão no momento da execução. Para mais detalhes sobre como a solicitação é feita ao usuário, consulte Prompts de solicitação de permissão perigosa.

Permissões especiais

Algumas permissões não se comportam como normais ou perigosas. SYSTEM_ALERT_WINDOW e WRITE_SETTINGS são particularmente sensíveis. Portanto, a maioria dos apps não deve usá-las.

Na maioria dos casos, o app precisa declarar a permissão SYSTEM_ALERT_WINDOW no manifesto e enviar uma intent que solicita a autorização do usuário. O sistema responde à intent mostrando uma tela de gerenciamento detalhada ao usuário.

A partir do Android 11 (nível 30 da API), apps que invocam a ação da intent ACTION_MANAGE_OVERLAY_PERMISSION não podem especificar um pacote. Quando os apps invocam uma intent que inclui essa ação da intent, o usuário precisa selecionar o app ao qual ele quer conceder ou revogar a permissão. Esse comportamento visa proteger os usuários, tornando as permissões mais intencionais.

Para mais informações sobre a solicitação dessas permissões, consulte as entradas de referência SYSTEM_ALERT_WINDOW e WRITE_SETTINGS.

As permissões fornecidas pelo sistema Android se encontram em Manifest.permission.

Grupos de permissões

As permissões são organizadas em grupos relacionados a recursos ou funcionalidades de um dispositivo. Nesse sistema, as solicitações de permissão são processadas no nível do grupo e um único grupo de permissões corresponde a várias declarações de permissão no manifesto do app. Por exemplo, o grupo de SMS inclui as declarações READ_SMS e RECEIVE_SMS. Esse agrupamento de permissões permite que o usuário faça escolhas mais significativas e informadas, sem ser sobrecarregado por solicitações de permissão complexas e técnicas.

Todas as permissões perigosas do Android pertencem a grupos de permissões. Qualquer permissão pode pertencer a um grupo de permissões, independentemente do nível de proteção. No entanto, os grupos de permissão só afetam a experiência do usuário se a permissão for perigosa.

Se um dispositivo estiver executando o Android 6.0 (API de nível 23) e a targetSdkVersion for 23 ou mais recente, o seguinte comportamento de sistema se aplica quando o app solicita uma permissão perigosa:

  • Se o app não tiver nenhuma permissão no grupo de permissões, o sistema mostrará a caixa de diálogo de solicitação de permissão ao usuário, descrevendo o grupo de permissões que o app quer acessar. A caixa de diálogo não descreve a permissão específica dentro do grupo. Por exemplo, se um app solicitar a permissão READ_CONTACTS, a caixa de diálogo do sistema simplesmente dirá que ele precisa acessar os contatos do dispositivo. Se o usuário conceder aprovação, o sistema dará ao app apenas a permissão que ele solicitou.
  • Se o app já tiver recebido outra permissão perigosa do mesmo grupo de permissões, o sistema concederá imediatamente a permissão sem nenhuma interação com o usuário. Por exemplo, se um app que solicitou e recebeu a permissão READ_CONTACTS for solicitar WRITE_CONTACTS, o sistema concederá essa permissão imediatamente sem mostrar a caixa de diálogo de permissões ao usuário.

Cuidado: versões futuras do SDK do Android podem mover uma permissão específica de um grupo para outro. Portanto, não baseie a lógica do seu app na estrutura desses grupos de permissões.

Por exemplo, READ_CONTACTS está no mesmo grupo de permissões que WRITE_CONTACTS desde o Android 8.1 (API de nível 27). Se o app solicitar a permissão READ_CONTACTS e, em seguida, solicitar a permissão WRITE_CONTACTS, não presuma que o sistema poderá conceder automaticamente a permissão WRITE_CONTACTS.

Se o dispositivo estiver executando o Android 5.1 (API de nível 22) ou anterior, ou a targetSdkVersion do app for 22 ou anterior, o sistema pedirá ao usuário que conceda a permissão no momento da instalação. Mais uma vez, o sistema informa ao usuário apenas os grupos de permissões de que o app precisa, não as permissões individuais. Por exemplo, quando um app solicita READ_CONTACTS, a caixa de diálogo de instalação lista o grupo "Contatos". Quando o usuário aceitar, apenas a permissão READ_CONTACTS será concedida ao app.

Observação: seu app ainda precisa solicitar explicitamente todas as permissões de que precisa, mesmo que o usuário já tenha concedido outra permissão do mesmo grupo. Além disso, a organização de permissões em grupo poderá mudar em versões futuras do Android. Seu código não pode ter uma lógica que dependa de um conjunto de permissões específicas estar no mesmo grupo.

Visualizar as permissões de um app

É possível ver todas as permissões atualmente definidas no sistema usando o app Configurações e o comando do shell adb shell pm list permissions. Para usar o app Configurações, acesse Configurações > Apps. Escolha um app e role para baixo para ver as permissões que ele usa. Para desenvolvedores, a opção adb '-s' exibe as permissões de uma forma semelhante àquela vista pelo usuário:

$ adb shell pm list permissions -s
All Permissions:

Network communication: view Wi-Fi state, create Bluetooth connections, full
internet access, view network state

Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone numbers

...

Você também pode usar a opção -g do adb para conceder todas as permissões automaticamente ao instalar um app em um emulador ou dispositivo de teste:

$ adb shell install -g MyApp.apk

Outros recursos