Runtime Permission: quais tipos existem e princípio de funcionamento no Android

O que é Runtime Permission?

Runtime Permission é um modelo de segurança do Android no qual o aplicativo solicita acesso a dados confidenciais no momento em que essa funcionalidade é realmente necessária para o usuário. Antes do Android 6.0, todas as permissões eram concedidas na instalação do aplicativo, e o usuário não podia revogá-las sem desinstalar completamente o aplicativo.

Evolução do modelo de permissões do Android

Antes do Android 6.0, o usuário via uma lista de todas as permissões na instalação e podia aceitar todas ou recusar a instalação. Um estudo de 2015 mostrou que 87% dos usuários não leem a lista de permissões na instalação. O Android 6.0 introduziu as runtime permissions, dividindo as permissões em normais (automáticas) e perigosas (com solicitação). O Android 11 adicionou as permissões únicas — revogação automática ao fechar o aplicativo. O Android 13 introduziu o Photo Picker e as notificações push como runtime permissions independentes.

O iOS usa um modelo semelhante desde o iOS 10, onde o acesso à câmera, microfone e geolocalização é solicitado no primeiro uso. No entanto, o iOS não tem o conceito de “permissões normais” — cada permissão é solicitada explicitamente, e a recusa persiste até que o desenvolvedor solicite novamente através das configurações do sistema.

Como o Runtime Permission funciona no Android?

O Runtime Permission funciona através de um diálogo do sistema invocado pelo método requestPermissions() (AndroidX — ActivityResultLauncher). O sistema exibe um diálogo padrão com uma explicação, e o usuário escolhe “Permitir” ou “Negar”. Após a resposta, um callback é acionado onde o aplicativo processa a decisão do usuário.

Solicitação de permissão via ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

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

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

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

O método shouldShowRequestPermissionRationale retorna true se o usuário já negou a solicitação uma vez. Neste caso, é recomendado mostrar um diálogo explicando por que o aplicativo precisa da permissão, e só então solicitar novamente. Isso aumenta a probabilidade de consentimento do usuário em 30–40% (dados do Google I/O 2024).

Tipos de permissões no Android

O Android classifica todas as permissões em vários níveis de proteção: normais, perigosas, de assinatura e especiais. As permissões normais são concedidas automaticamente na instalação. As permissões perigosas exigem uma solicitação em tempo de execução. As permissões de assinatura estão disponíveis apenas para aplicativos assinados com o mesmo certificado.

Grupos de permissões perigosas

As permissões especiais (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) exigem navegação adicional para as configurações do sistema através de Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Essas permissões não podem ser solicitadas através do diálogo padrão do sistema e exigem uma ação explícita do usuário na tela de configurações.

Solicitação de permissões no Android 12+

O Android 12 introduziu mudanças significativas no modelo de runtime permissions. As permissões únicas permitem conceder acesso à câmera, microfone ou geolocalização apenas para uma sessão. Assim que o usuário fecha o aplicativo, a permissão é revogada automaticamente. Os indicadores de privacidade são indicadores verdes na barra de status que mostram quando um aplicativo está usando a câmera ou o microfone.

Lidando com permissões únicas

// Android 12+ — tratamento de permissão única de localização
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Verificar se a permissão foi revogada pelo sistema (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

O Android 13 adicionou a permissão POST_NOTIFICATIONS ao grupo perigoso, exigindo uma solicitação explícita para enviar notificações push. O Android 14 introduziu restrições à geolocalização em segundo plano: o aplicativo deve obter a aprovação explícita do usuário cada vez que solicitar localização em segundo plano. O Photo Picker (API 33+) substituiu a necessidade de READ_EXTERNAL_STORAGE para seleção de imagens.

Lidando com recusas do usuário

A recusa do usuário a uma solicitação de permissão é uma situação normal que deve ser tratada corretamente. Existem dois tipos de recusa: única (o usuário pressionou “Negar”) e permanente (o usuário selecionou “Não perguntar novamente”). No segundo caso, o diálogo do sistema não aparecerá mais, e o aplicativo deve redirecionar o usuário para as configurações do sistema.

Estratégia de tratamento de recusas

Após a primeira recusa, o aplicativo deve mostrar um diálogo de justificativa — sua própria explicação de por que a permissão é necessária. Se o usuário recusar novamente, o aplicativo deve redirecionar para a tela de configurações do aplicativo através de Settings.ACTION_APPLICATION_DETAILS_SETTINGS. O Material 3 recomenda usar PermissionRequestBottomSheet para uma UX mais natural.

É importante não bloquear completamente a funcionalidade do aplicativo em caso de recusa. Por exemplo, se o usuário recusou a geolocalização, o aplicativo deve oferecer a entrada manual de endereço. Para a câmera, permitir o upload de uma imagem da galeria. O Google recomenda sempre fornecer um mecanismo alternativo para todas as runtime permissions.

Recomendações de segurança

As runtime permissions não são apenas um mecanismo técnico, mas também um elemento de confiança do usuário no aplicativo. Solicitar uma permissão em um momento inadequado (por exemplo, na primeira inicialização) reduz significativamente a probabilidade de consentimento. O Google Play Store analisa a frequência e o contexto das solicitações de permissão: aplicativos com solicitações agressivas obtêm posições mais baixas na pesquisa.

Regras para solicitar permissões

Contexto — solicite a permissão imediatamente antes de executar a ação que a requer. Mínimo — solicite apenas as permissões realmente necessárias para o funcionamento do recurso. Transparência — explique ao usuário por que a permissão é necessária antes do diálogo do sistema. Revogação — inscreva-se em ACTION_PERMISSION_REVOCATION para lidar corretamente com a revogação de permissões em tempo de execução.

Para testar runtime permissions, use comandos adb: adb shell pm revoke <package> android.permission.CAMERA permite simular a revogação de permissão sem reinstalar o aplicativo. Espresso e UiAutomator suportam testes de diálogos de permissão através de GrantPermissionRule. A integração dessas ferramentas no pipeline de CI/CD é obrigatória para aplicativos com runtime permissions.

Auditoria de permissões no Google Play Console

O Google Play Console fornece uma seção de auditoria de permissões, onde os desenvolvedores podem ver com que frequência as permissões são solicitadas, qual porcentagem de usuários concede acesso e quais permissões foram revogadas. A análise desses dados ajuda a identificar solicitações ineficazes e otimizar a UX. Por exemplo, se menos de 40% dos usuários concedem geolocalização, considere revisar o momento da solicitação e adicionar uma justificativa mais convincente.

O uso do Android Vitals para monitorar ANR (Application Not Responding) relacionado a permissões também é crítico. Se uma solicitação de permissão for executada na thread principal ou o diálogo do sistema bloquear a UI, isso pode causar ANR em dispositivos lentos. Mova a verificação e solicitação de permissões para uma thread separada ou use corrotinas do Kotlin para manipulação assíncrona para evitar bloquear a interface do usuário.