Participe do evento ⁠#Android11: apresentação de lançamento da versão Beta no dia 3 de junho.

Determinar a necessidade de acesso a dados confidenciais

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 aplicativo tem permissão de realizar nenhuma operação que prejudique outros aplicativos, 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 aplicativo, 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ê quer 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 de que precisa incluindo as tags <uses-permission> no manifesto do aplicativo. Por exemplo, um aplicativo 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>
    

Se seu aplicativo lista 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 automaticamente concede essas permissões.

Se seu aplicativo lista 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 aplicativo.

Solicitações no momento da execução (Android 6.0 e versões superiores)

Se o dispositivo está executando o Android 6.0 (API de nível 23) ou versões posteriores e a targetSdkVersion do aplicativo é 23 ou posterior, o usuário não recebe nenhuma notificação sobre permissões do app no momento da instalação. O aplicativo precisa pedir que o usuário conceda permissões perigosas no momento da execução. Quando o aplicativo solicita permissão, o usuário vê uma caixa de diálogo do sistema (como mostrado na figura 1, à esquerda) informando qual grupo de permissões o aplicativo 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 pedida 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 seu aplicativo tentar solicitar a mesma permissão posteriormente.

Mesmo que o usuário conceda a permissão solicitada ao seu app, você nem sempre pode 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. Você precisa sempre verificar e solicitar permissões no momento da 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 está executando o Android 5.1.1 (nível de API 22) ou versões anteriores ou a targetSdkVersion do aplicativo é 22 ou anterior ao executar qualquer versão do Android, o sistema pede automaticamente que o usuário conceda todas as permissões perigosas ao 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 aplicativo.

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

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 aplicativo na Play Store, precisará solicitar que o usuário configure seu aplicativo como o manipulador 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 manipuladores padrão, incluindo orientações sobre como exibir uma solicitação de manipulador padrão aos usuários, consulte o guia sobre permissões usadas somente em manipuladores 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 seu app solicita a permissão CAMERA, é importante incluir também a tag <uses-feature> no manifesto para declarar se esse recurso é realmente necessário ou não. 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 seu aplicativo seja instalado em dispositivos que não tenham o recurso. Você precisará, então, verificar se o dispositivo atual tem o recurso no momento da execução chamando PackageManager.hasSystemFeature() e desativar esse recurso se ele não estiver disponível.

Se você não fornecer a tag <uses-feature>, quando o Google Play perceber que seu aplicativo solicita a permissão correspondente, ele presumirá que o aplicativo precisa desse recurso. Então, ele filtrará seu aplicativo em dispositivos que não têm 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.

Aplicação de permissões

Permissões não servem apenas para solicitar recursos do sistema. Os serviços fornecidos pelos aplicativos 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 Activity

Permissões aplicadas usando o atributo android:permission à tag <activity> do manifesto restringem quem pode iniciar essa 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á devolvido da chamada.

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

Permissões aplicadas usando o atributo android:permission à tag <service> do 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á devolvido da chamada.

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

Permissões aplicadas usando o atributo android:permission à tag <receiver> restringem quem pode enviar transmissões ao BroadcastReceiver associado. A permissão é verificada depois que Context.sendBroadcast() é retornado enquanto o sistema tenta entregar a transmissão enviada a determinado receptor. Como resultado, uma falha de permissão não resulta em uma exceção devolvida ao autor da chamada, ela apenas não entregará 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, é possível fornecer uma permissão ao chamar Context.sendBroadcast() para restringir quais broadcast receivers podem receber a transmissão.

Observe que, tanto um receptor quanto um transmissor pode exigir uma permissão. Quando isso acontece, as duas verificações de permissão precisam passar pelo 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

Permissões aplicadas usando o atributo android:permission à 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. Diferentemente de outros componentes, há dois atributos separados de permissão que podem ser definidos: 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 a partir de um provedor.

Essas permissões são verificadas ao recuperar um provedor pela primeira vez (se não tiver nenhuma das permissões, SecurityException será devolvido) e à medida que se são realizadas operações no provedor. O uso de ContentResolver.query() exige reter a permissão de leitura. O uso de ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requer a permissão de gravação. Em todos esses casos, não reter a permissão exigida resulta em uma SecurityException devolvida 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 aplicativos para que possam operar.

Um exemplo típico são os anexos em um app de emails. O acesso aos e-mails precisa ser protegido por permissões, já que os dados do usuário 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 esse 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 no intent, independentemente se ele tem ou não a permissão para acessar os dados no provedor de conteúdo correspondente ao 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 que os apps necessitam apenas àquelas diretamente relacionadas ao comportamento.

Para criar a implementação mais segura que torna outros apps responsáveis pelas ações deles dentro do seu app, você precisa usar permissões detalhadas dessa maneira e declarar a compatibilidade do seu 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. Isso é 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 código do processo (PID, na sigla em inglês) de outro processo, poderá usar o método Context.checkPermission() para verificar uma permissão nesse PID. Se você tiver o nome do pacote de outro aplicativo, poderá usar o método PackageManager.checkPermission() para descobrir se esse pacote recebeu uma permissão específica.

Ajustes de permissões automáticas

Com o tempo, novas restrições podem ser adicionadas à plataforma de modo que, para usar determinadas APIs, seu aplicativo precise solicitar uma permissão que não tinha anteriormente. Como os aplicativos 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 aplicativo para evitar erros na versão da nova plataforma ("isentando" seu aplicativo da permissão). O Android decide se um aplicativo precisará da permissão com base no valor fornecido para o atributo targetSdkVersion. Se o valor é menor que a versão à qual a permissão foi adicionada, o Android adiciona a permissão.

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

Cuidado: se uma permissão é adicionada automaticamente ao aplicativo, os detalhes do app no Google Play listam as permissões adicionais mesmo que o aplicativo não as exija. Para evitar isso e remover as permissões padrão desnecessárias, atualize sempre a targetSdkVersion para a versão mais recente possível. Você pode ver quais permissões foram adicionadas em cada versão 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 aplicativos 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 aplicativo precisa acessar dados ou recursos fora da sandbox do aplicativo, mas apresenta pouco risco à privacidade do usuário ou à operação de outros aplicativos. Por exemplo, a permissão para definir o fuso horário é normal.

Se um aplicativo declara no manifesto que precisa de uma permissão normal, o sistema automaticamente concede 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 aplicativo que tenta usar a permissão é assinado pelo mesmo certificado que o aplicativo que define a permissão.

Permissões perigosas

Permissões perigosas abrangem áreas em que o aplicativo 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 aplicativos. Por exemplo: a capacidade de ler os contatos do usuário é uma permissão perigosa. Se um aplicativo declara que precisa de uma permissão perigosa, o usuário precisa conceder explicitamente essa permissão. Até o usuário aprovar a permissão, seu aplicativo não poderá fornecer recursos que dependam dessa permissão.

Para usar uma permissão perigosa, seu aplicativo 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 as normais nem as perigosas. SYSTEM_ALERT_WINDOW e WRITE_SETTINGS são particularmente sensíveis, portanto, a maioria dos apps não deve usá-las. Se um aplicativo precisa de uma dessas permissões, precisa declarar a permissão no manifesto e enviar um intent solicitando a autorização do usuário. O sistema responde ao intent mostrando uma tela de gerenciamento detalhada ao usuário.

Para mais informações sobre como solicitar essas permissões, consulte as entradas de referência SYSTEM_ALERT_WINDOW e WRITE_SETTINGS.

Todas as permissões fornecidas pelo sistema Android podem ser encontradas em Manifest.permission.

Grupos de permissões

As permissões são organizadas em grupos relacionados a recursos ou funcionalidades de um dispositivo. De acordo com esse 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 aplicativo. Por exemplo, o grupo 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 está executando o Android 6.0 (API de nível 23) e a targetSdkVersion dele é 23 ou posterior, o seguinte comportamento de sistema se aplica quando o aplicativo solicita uma permissão perigosa:

  • Se o aplicativo 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 aplicativo quer acessar. A caixa de diálogo não descreve a permissão específica dentro do grupo. Por exemplo, se um aplicativo solicita a permissão READ_CONTACTS, a caixa de diálogo do sistema simplesmente dirá que o aplicativo precisa acessar os contatos do dispositivo. Se o usuário concede aprovação, o sistema dá ao aplicativo apenas a permissão que ele solicitou.
  • Se o aplicativo 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 aplicativo já solicitou e recebeu a permissão READ_CONTACTS e depois solicita WRITE_CONTACTS, o sistema concede imediatamente essa permissão 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 aplicativo 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 seu aplicativo solicitar a permissão READ_CONTACTS e depois solicitar a WRITE_CONTACTS, não presuma que o sistema poderá conceder a permissão WRITE_CONTACTS automaticamente.

Se o dispositivo está executando o Android 5.1 (API de nível 22) ou versões anteriores ou se a targetSdkVersion do aplicativo é 22 ou anterior, o sistema pede ao usuário que conceda as permissões no momento da instalação. Mais uma vez, o sistema apenas diz ao usuário de quais grupos de permissões o aplicativo 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 aceita, apenas a permissão READ_CONTACTS é concedida ao aplicativo.

Observação: seu aplicativo 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 deve ter uma lógica que dependa que um conjunto de permissões específicas esteja no mesmo grupo.

Visualizar as permissões de um aplicativo

É possível ver todas as permissões atualmente definidas no sistema usando o aplicativo Config. e o comando shell adb shell pm list permissions. Para usar o aplicativo Config., vá para Config. > Aplicativos. Escolha um aplicativo e role para baixo para ver as permissões que ele usa. Para desenvolvedores, a opção adb '-s' exibe as permissões em uma forma semelhante a como o usuário as vê:

    $ 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 adb -g para conceder todas as permissões automaticamente ao instalar um aplicativo em um emulador ou dispositivo de teste:

    $ adb shell install -g MyApp.apk
    

Outros recursos

  • Solicitar permissões do app: guia com instruções de como solicitar permissões no seu aplicativo.
  • Permissões que implicam em requisitos de recurso: informações sobre como solicitar algumas permissões restringe implicitamente seu aplicativo a dispositivos que tenham o recurso de hardware ou software correspondente.
  • <uses-permission>: referência da API para a tag do manifesto que declara as permissões necessárias do seu aplicativo.
  • Compatibilidade do dispositivo: informações sobre como o Android funciona em diferentes tipos de dispositivo e uma introdução sobre como otimizar seu aplicativo para cada dispositivo ou restringir a disponibilidade do seu aplicativo a diferentes dispositivos.
  • Visão geral da segurança do Android: uma discussão detalhada sobre o modelo de segurança da plataforma Android.
  • "Mother, May I?" Asking for Permissions: este vídeo da Conferência de Desenvolvedores Android 2105 descreve as práticas recomendadas para solicitar permissões.
  • Android M Permissions: este vídeo do Google I/O 2015 explica as mudanças feitas no modelo de permissões do Android 6.0.