AndroidManifest Permissions: conceitos-chave, declaração e tipos de permissões

O que são AndroidManifest Permissions?

AndroidManifest Permissions é o mecanismo de segurança do Android que controla o acesso dos aplicativos a dados protegidos e funções do sistema. Cada aplicativo deve declarar as permissões necessárias no arquivo AndroidManifest.xml usando o elemento . Sem a declaração, a chamada à API correspondente resultará em um erro de segurança SecurityException.

O modelo de permissões do Android passou por vários estágios de evolução. Antes do Android 6.0 (API 23), todas as permissões eram concedidas na instalação — o usuário via a lista completa e concordava ou recusava a instalação do aplicativo. A partir do Android 6.0, as permissões de nível dangerous são solicitadas em tempo de execução (Runtime Permissions), dando ao usuário um controle mais flexível.

As permissões são divididas em quatro níveis de proteção: normal (concedidas automaticamente na instalação), dangerous (exigem solicitação em tempo de execução), signature (disponíveis apenas para aplicativos assinados com o mesmo certificado) e special (exigem ativação separada nas configurações). Cada nível tem seu próprio mecanismo de concessão e revogação.

De acordo com o Google I/O 2024, o Android 15 planeja introduzir permissões mais granulares — o usuário poderá conceder acesso apenas a arquivos específicos na biblioteca de mídia, e não à coleção inteira. Isso continua a tendência do Android de minimizar a quantidade de dados fornecidos por padrão.

Diferença do modelo de permissões do iOS

Ao contrário do iOS, onde todas as permissões são solicitadas em tempo de execução, o Android divide as permissões em tipos de instalação (install-time) e execução (runtime). O nível normal é concedido automaticamente na instalação sem notificação ao usuário. O nível dangerous exige um diálogo explícito, como no iOS.

Outra diferença: no Android, as permissões são agrupadas em grupos de permissões. Se o usuário concordar com o acesso à câmera, o aplicativo obtém automaticamente acesso ao microfone — eles estão no mesmo grupo MICROPHONE. No iOS, cada permissão é solicitada independentemente, independentemente dos grupos.

Evolução das permissões por versões do Android

Quais tipos de permissões existem

O Android define quatro níveis de proteção para permissões, cada um com suas próprias regras de concessão. Vamos revisar cada nível em detalhes.

Permissões Normal (install-time)

As permissões normal são concedidas automaticamente na instalação do aplicativo sem notificação ou solicitação ao usuário. Elas cobrem funções de baixo risco que não ameaçam a privacidade do usuário: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. O usuário não vê nenhum diálogo de consentimento — a permissão é considerada concedida após a instalação.

O desenvolvedor não precisa lidar com solicitações em tempo de execução para permissões normal — basta declará-las no manifesto. No entanto, no Android 12+, ao instalar pelo Google Play, o usuário vê uma guia “Permissões” listando todas as permissões normal, aumentando a transparência. De acordo com a Statista (2024), mais de 90% dos aplicativos no Google Play usam INTERNET como a permissão normal mais comum.

Permissões Dangerous (runtime)

As permissões dangerous cobrem o acesso a dados e funções que podem comprometer a privacidade: câmera, microfone, geolocalização, contatos, SMS, telefone, calendário, sensores corporais. Essas permissões exigem um mecanismo de duas etapas: declaração no manifesto + solicitação em tempo de execução via ActivityCompat.requestPermissions().

O usuário pode negar uma permissão dangerous, e o aplicativo deve lidar com esse cenário corretamente. No Android 11+, se o usuário negar duas vezes, as solicitações subsequentes não mostram o diálogo do sistema — o sistema retorna automaticamente DENIED. Nesse caso, o aplicativo deve direcionar o usuário para as configurações.

Permissões Signature e Special

O nível signature — a permissão é concedida automaticamente se o aplicativo for assinado com o mesmo certificado que o sistema ou outro aplicativo que definiu a permissão. Usado para aplicativos de sistema e corporativos. Exemplo: BIND_ACCESSIBILITY_SERVICE — disponível apenas para aplicativos do sistema.

O nível special (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — exige uma ação explícita do usuário através das configurações do sistema. O aplicativo pode abrir a página de configurações com Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). O Google Play restringe o uso de permissões special e exige justificativa no formulário de publicação.

Runtime Permission: trabalhando com permissões dangerous

Desde o Android 6.0, todas as permissões dangerous exigem solicitação em tempo de execução. Vamos percorrer o ciclo completo de trabalho com runtime permissions em Kotlin.

Verificação e solicitação de permissão

Antes de chamar uma API que exija uma permissão dangerous, sempre verifique o status atual via ContextCompat.checkSelfPermission(). Se o status for PERMISSION_GRANTED, você pode chamar a API. Se for PERMISSION_DENIED, você precisa solicitar a permissão através do ActivityResultContract RequestPermission (AndroidX) ou do obsoleto requestPermissions().

Recomenda-se usar ActivityResultContracts.RequestMultiplePermissions para solicitar várias permissões de uma vez. O Google recomenda agrupar permissões relacionadas (por exemplo, câmera + microfone para gravação de vídeo) em um único diálogo, para que o usuário veja o contexto completo da solicitação.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                explainWhyPermissionNeeded()
            }
        }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        checkCameraPermission()
    }

    private fun checkCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(this,
                Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(
                Manifest.permission.CAMERA
            ) -> {
                showRationale()
            }
            else -> {
                requestPermissionLauncher.launch(
                    Manifest.permission.CAMERA
                )
            }
        }
    }
}

Lidando com a negação “Não perguntar novamente”

Se o usuário negar duas vezes, o Android coloca a solicitação no estado “Never ask again”. Nesse caso, shouldShowRequestPermissionRationale() retorna false, e o diálogo do sistema não será exibido. O aplicativo deve direcionar o usuário para as configurações do sistema via Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Importante: não mostre um diálogo oferecendo abrir configurações imediatamente após a primeira negação — isso é percebido como comportamento agressivo. Use shouldShowRequestPermissionRationale() para determinar se é necessário mostrar uma explicação. As Diretrizes do Material Design recomendam mostrar uma tela explicando o valor do acesso, não apenas um botão “Abrir configurações”.

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Acesso à câmera")
        .setMessage("Permita o acesso à câmera nas Configurações, "
            + "para tirar fotos de perfil")
        .setPositiveButton("Abrir configurações") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Cancelar", null)
        .show()
}

Declaração de permissões no AndroidManifest.xml

O arquivo AndroidManifest.xml contém o elemento para cada permissão que o aplicativo usa. As permissões são declaradas no nível antes do elemento .

Sintaxe de declaração

Cada permissão é declarada com um elemento separado usando o atributo android:name que especifica o nome completo da permissão. Para permissões introduzidas em versões específicas do Android, use o atributo maxSdkVersion para limitar a declaração apenas às versões necessárias — isso melhora a compatibilidade.

Por exemplo, a permissão WRITE_EXTERNAL_STORANCE não é necessária no Android 10+ (Scoped Storage), então especifique maxSdkVersion="28" (Android 9). Isso evita perguntas desnecessárias dos usuários em versões mais recentes. O Android Studio avisa sobre maxSdkVersion recomendados através do Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

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

    <application>
        <!-- ... -->
    </application>
</manifest>

Usando para filtragem

O elemento indica que o aplicativo requer hardware específico (câmera, GPS, NFC). O atributo android:required="false" permite que o aplicativo seja instalado em dispositivos sem esse hardware — a disponibilidade é verificada no código. Se required="true", o Google Play filtra o aplicativo, tornando-o indisponível para dispositivos inadequados.

Recomenda-se definir required="false" para todos os recursos de hardware e verificar a disponibilidade programaticamente via PackageManager.hasSystemFeature(). Isso expande o público do seu aplicativo. A única exceção é se o recurso for crítico para o funcionamento do aplicativo (um aplicativo de táxi sem GPS não faz sentido).

Melhores práticas e erros

O gerenciamento adequado de permissões é um aspecto fundamental da qualidade de um aplicativo Android. Vamos revisar as principais recomendações e erros típicos.

Minimizar as permissões solicitadas

Solicite apenas as permissões realmente necessárias para o funcionamento do aplicativo. Cada permissão extra reduz a taxa de conversão de instalações e aumenta a quantidade de recusas. O Google Play Console mostra quantos usuários recusaram a instalação devido ao conjunto de permissões. De acordo com a AppBrain (2024), aplicativos com 10+ permissões dangerous têm 35% menos instalações.

Revise regularmente sua lista de permissões. Remova as não utilizadas, especialmente ao migrar para versões mais recentes do Android onde algumas permissões se tornam opcionais. Por exemplo, com o seletor de fotos (ActivityResultContracts.PickVisualMedia) no Android 13+, o acesso à biblioteca de mídia pode ser obtido sem a permissão dangerous READ_MEDIA_IMAGES.

Mostrar explicação antes de solicitar

Antes de solicitar uma permissão dangerous, mostre ao usuário uma tela explicando por que essa permissão é necessária e qual valor ela proporciona. O Material Design recomenda usar uma bottom sheet ou diálogo com um ícone, texto breve e um botão “Continuar”. A explicação aumenta o consentimento em 20–30% em comparação com uma solicitação direta.

Verifique shouldShowRequestPermissionRationale() antes de chamar launch(). Se for true, mostre a explicação. Se for false, a permissão já foi concedida ou o usuário a negou permanentemente (never ask again). Neste último caso, mostre um botão “Abrir configurações” em vez de repetir a solicitação.

Testar todos os cenários de permissões

Teste todos os cenários possíveis: concessão da permissão, negação, negação permanente, revogação da permissão nas configurações, redefinição de permissões (Android 11+ auto-reset). Cada cenário deve ser tratado sem travamentos ou perda de dados. O Guia de Testes do Android recomenda usar a biblioteca TestPermission para automatizar os testes.

Preste atenção especial ao cenário em que o usuário revoga uma permissão enquanto o aplicativo está em execução (aplicativo minimizado → Configurações → revogação). Ao retornar ao aplicativo, verifique todas as permissões em onResume(). Não confie no cache do status das permissões — o usuário pode alterá-las a qualquer momento.

Erros típicos

• Solicitar uma permissão sem primeiro verificar checkSelfPermission — gera um diálogo desnecessário
• Ignorar shouldShowRequestPermissionRationale — piora a experiência do usuário após a primeira negação
• Solicitar permissão sem contexto (apenas “Permitir acesso?”) — reduz o consentimento
• Usar WRITE_EXTERNAL_STORAGE no Android 10+ sem maxSdkVersion — solicitação desnecessária
• Falta de verificação de permissões em onResume — perder a revogação de permissões nas configurações