Permission Group no Android — o que é, grupos de permissões e princípio de funcionamento

O que é Permission Group no Android

Permission Group é um mecanismo do sistema Android que agrupa várias permissões perigosas em um grupo com base em sua finalidade funcional. Cada grupo tem um identificador de string, por exemplo android.permission-group.CAMERA ou android.permission-group.LOCATION. Todas as permissões dentro de um grupo estão logicamente relacionadas e fornecem acesso a funções relacionadas do dispositivo.

Os grupos de permissões apareceram no Android 6.0 Marshmallow junto com o modelo de permissões em tempo de execução. Seu principal objetivo é simplificar a interação com o usuário: em vez de uma série de diálogos para cada permissão individual, o sistema mostra um diálogo por grupo. Se o usuário conceder uma permissão de um grupo, as demais são consideradas automaticamente aprovadas. De acordo com a Android UX Research (2015), isso reduziu o número de negações no primeiro lançamento em 20 por cento.

É importante entender que o desenvolvedor não pode criar seus próprios Permission Groups. Os grupos são pré-definidos no nível do sistema operacional e descritos em arquivos permissions.xml em cada dispositivo. O aplicativo apenas declara uses-permission, e o sistema mapeia automaticamente a permissão para seu grupo com base no protectionLevel e na categorização no AOSP.

Como o sistema determina o grupo

O mapeamento de uma permissão para um grupo ocorre através do atributo permissionGroup na definição da permissão do sistema. Por exemplo, CAMERA é declarado com permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION com permissionGroup="android.permission-group.LOCATION". Este mapeamento está fixado no código do Android Open Source Project e é idêntico em todos os dispositivos certificados.

Como funcionam os Permission Group

O mecanismo de grupos funciona no princípio de “um diálogo por grupo”. Quando um aplicativo solicita pela primeira vez qualquer permissão perigosa, o sistema verifica seu Permission Group. Se nenhuma permissão deste grupo foi concedida ainda — um diálogo é mostrado. Após o consentimento, o sistema marca todo o grupo como concedido, e as solicitações subsequentes de outras permissões do mesmo grupo são satisfeitas sem interface do usuário.

O algoritmo simplificado é assim:

• O aplicativo chama requestPermissions para ACCESS_FINE_LOCATION
• O sistema determina o grupo — android.permission-group.LOCATION
• Verifica se o grupo LOCATION foi concedido anteriormente
• Se não — mostra um diálogo com o nome do grupo e lista de permissões incluídas
• Após Allow — todo o grupo LOCATION é considerado concedido
• ACCESS_COARSE_LOCATION agora está disponível sem uma solicitação adicional

Este mecanismo se aplica apenas a permissões perigosas. Permissões normais não têm grupos e não participam desta lógica. Permissões privilegiadas e de assinatura também não são agrupadas — elas têm um sistema de controle de acesso separado.

Limitações da lógica de grupo

Os grupos não funcionam “ao contrário”: revogar uma permissão de um grupo através das configurações revoga apenas essa permissão sem afetar as outras. Além disso, se um usuário recusar o diálogo de um grupo, isso não bloqueia outros grupos — cada nova permissão de um grupo diferente mostrará seu próprio diálogo. Permission Group afeta apenas a UX da solicitação, não o modelo de segurança.

Lista de Permission Group no Android

O Android define os seguintes Permission Groups do sistema para permissões perigosas. Cada grupo inclui uma ou mais permissões unidas por um propósito funcional comum.

Mudanças nas novas versões

No Android 13 (API 33), surgiu um novo grupo NEARBY_DEVICES, combinando BLUETOOTH_SCAN, BLUETOOTH_CONNECT e BLUETOOTH_ADVERTISE. Além disso, o grupo STORAGE foi parcialmente substituído por permissões de mídia READ_MEDIA_IMAGES, READ_MEDIA_VIDEO e READ_MEDIA_AUDIO, que não fazem parte do STORAGE, mas são permissões perigosas independentes sem agrupamento.

Grupos de permissões personalizados

Os desenvolvedores podem declarar suas próprias permissões com Permission Groups personalizados através do atributo permissionGroup no manifesto. No entanto, isso só funciona para permissões personalizadas do mesmo aplicativo e não afeta os diálogos de interface do sistema. Na prática, Permission Groups personalizados são raramente usados — para interação entre aplicativos no mesmo stack.

Permission Group e UX

O impacto do Permission Group na experiência do usuário é significativo. Graças ao agrupamento, o usuário não vê 8 diálogos separados para diferentes permissões, mas alguns diálogos de grupo. Isso reduz a carga cognitiva e diminui a probabilidade de o usuário negar uma permissão criticamente importante sem entender seu propósito.

Pesquisas de UX mostram que os diálogos de grupo são percebidos pelos usuários como mais transparentes. Quando um aplicativo solicita “permissão para aceder à câmara”, o usuário entende o contexto. Se cada permissão fosse solicitada separadamente — CAMERA, CAMERA2, FLASHLIGHT — criaria uma impressão de redundância. Permission Group abstrai essa granularidade.

A melhor prática é solicitar permissões apenas de um grupo de cada vez. Se um aplicativo precisa tanto da câmara quanto da localização, não as solicite numa única chamada requestPermissions. Primeiro solicite um grupo depois de explicar por que é necessário, depois o segundo. Isso dá ao usuário controle e uma compreensão sequencial de cada funcionalidade.

Permission Group vs ProtectionLevel

Permission Group e ProtectionLevel são duas dimensões diferentes do sistema de permissões do Android. ProtectionLevel determina como uma permissão é concedida (normal, dangerous, signature, privileged), enquanto Permission Group é uma categoria para exibição na interface do utilizador. São independentes, mas na prática a combinação dangerous + permission group é a mais comum.

Permissões do mesmo ProtectionLevel podem pertencer a grupos diferentes. Por exemplo, ACCESS_FINE_LOCATION e CAMERA têm ambos protectionLevel dangerous, mas pertencem a grupos diferentes — LOCATION e CAMERA. E inversamente, permissões com nomes semelhantes pertencem sempre ao mesmo grupo: ACCESS_FINE_LOCATION e ACCESS_COARSE_LOCATION estão ambas em LOCATION.

Níveis de proteção superiores — signature e privileged — não usam Permission Groups para a interface do utilizador. A sua concessão é controlada ao nível do sistema: signature é concedida a aplicações assinadas com o mesmo certificado que o sistema, e privileged a aplicações na imagem do sistema. Os grupos para tais permissões existem, mas não afetam os diálogos de UX porque estes diálogos simplesmente não aparecem.

Verificar Permission Group no código

O desenvolvedor pode determinar programaticamente o Permission Group de qualquer permissão através do PackageManager. O método getPermissionInfo retorna PermissionInfo com um campo group contendo o identificador de string do grupo. Isso é útil para registo, análise e ecrãs de permissões de interface personalizados.

fun getPermissionGroupName(
    permission: String
): String? {
    return try {
        val pm = packageManager
        val info = pm.getPermissionInfo(
            permission,
            PackageManager.GET_META_DATA
        )
        info.group
    } catch (e: NameNotFoundException) {
        null
    }
}

fun getPermissionsByGroup(
    group: String
): List<String> {
    val pm = packageManager
    val perms = pm.queryPermissionsByGroup(
        group,
        PackageManager.GET_META_DATA
    )
    return perms.map { it.name }
}

Uso em DI e arquitetura

O conhecimento dos Permission Groups ajuda a construir a arquitetura de solicitações. Pode criar uma abstração chamada PermissionGroupProvider que retorna a lista de permissões para um grupo específico. Isso simplifica os testes: em testes unitários, o fornecedor retorna dados simulados sem chamar PackageManager. Em testes de instrumentação, retorna grupos reais do sistema.

PermissionGroupProvider em DI

A integração do PermissionGroupProvider através de Dagger Hilt ou Koin permite uma gestão centralizada do mapeamento de permissões para grupos. No fornecedor, pode armazenar em cache o resultado de PackageManager.queryPermissionsByGroup para evitar chamadas repetidas ao sistema em cada solicitação. Isso é especialmente importante para ecrãs de configurações onde a lista completa de permissões e o seu estado são exibidos.

Registo e análise

Ao recolher análises sobre negações, é útil registar não apenas o nome da permissão, mas também o seu Permission Group. Isso permite identificar quais áreas funcionais causam o maior número de negações. Por exemplo, o grupo LOCATION tradicionalmente tem a maior taxa de negação — cerca de 40 por cento, de acordo com as estatísticas do Google Play Console.

A análise por grupos ajuda a tomar decisões de produto: se o grupo CONTACTS tem uma alta taxa de negação, talvez seja necessário reconsiderar o momento da solicitação ou adicionar um diálogo de justificação. A abordagem baseada em grupos para análise fornece uma imagem mais completa do que a análise de permissões individuais, pois o número de negações em todo um grupo reflete a atitude geral do utilizador em relação a uma área funcional.