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

Permissões no Android

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 oferece uma visão geral de como as permissões do Android funcionam, incluindo os tipos de permissões e seus grupos e como as permissões são aplicadas. Se você quiser apenas um guia com instruções de como usar permissões do app, consulte os guias sobre comodeclarar permissões do app esolicitar permissões do app.

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.

O sistema se comporta de forma específica se o seu app é instalado em um dispositivo que executa o Android 6.0 (API de nível 23) ou mais recente, ou se o app é direcionado ao Android 6.0 ou mais recente. O sistema irá se comportar de maneira diferente se o app for instalado em um dispositivo que seja executado no Android 5.1 (API de nível 22) ou anterior ou se o app for direcionado ao Android 5.1 ou versões anteriores.

Se um dispositivo estiver executando o Android 6.0 ou versões mais recentes e a targetSdkVersion do app é 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 -s no comando adb 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

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 Activity

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 na próxima seção. 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 a permissão de leitura. O uso de ContentResolver.insert(), ContentResolver.update() e ContentResolver.delete() requer 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 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 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. 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 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.

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.

Outros recursos