1. Cada permissão deve existir por uma razão funcional
Uma aplicação deve pedir acesso a funcionalidades sensíveis apenas quando existe uma necessidade clara. Localização, câmara, microfone, contactos ou ficheiros não devem ser pedidos antecipadamente sem relação com uma ação que o utilizador compreenda.
O exercício mais útil é completar a frase: “precisamos desta permissão porque a funcionalidade X precisa de Y”. Se não for possível escrever essa relação de forma simples, vale a pena rever se o acesso é realmente necessário.
2. Peça no momento certo
Solicitar várias permissões no primeiro arranque, antes de o utilizador perceber para que servem, cria desconfiança e aumenta a probabilidade de rejeição. Sempre que a plataforma o permite, é mais claro pedir acesso quando a pessoa tenta usar a funcionalidade associada.
Uma pequena explicação anterior ao pedido pode dar contexto, mas deve ser objetiva. Não deve pressionar o utilizador nem prometer algo diferente do que a permissão realmente permite.
3. Planeie o que acontece se a resposta for “não”
Permissões podem ser recusadas, revogadas mais tarde ou ficar indisponíveis por políticas do dispositivo. A aplicação precisa de um comportamento previsível: desativar apenas a funcionalidade dependente, oferecer uma alternativa ou explicar como voltar a ativar o acesso quando fizer sentido.
Evitar um bloqueio total é especialmente importante quando a permissão é opcional para o objetivo principal da aplicação.
4. Minimização também reduz manutenção
Quanto menos acessos sensíveis uma aplicação exigir, menos fluxos de autorização, exceções e explicações precisam de ser mantidos. Isto pode simplificar testes e reduzir impacto quando o Android altera regras de acesso numa nova versão.
5. Política de privacidade e comportamento real têm de coincidir
Não basta escrever uma política genérica. Se uma aplicação usa localização apenas para uma função específica, essa utilização deve ser refletida de forma compreensível. Se não recolhe determinado dado, não é útil afirmar o contrário “por segurança”, porque isso torna a informação menos precisa.
Da mesma forma, integrações com serviços externos devem ser consideradas: um dado pode não ser armazenado diretamente pelo programador e ainda assim ser processado por um fornecedor necessário à funcionalidade.
6. Reveja permissões quando a aplicação evolui
Funcionalidades são removidas e dependências mudam. Uma revisão periódica pode revelar permissões que deixaram de ser necessárias. Retirá-las melhora clareza e reduz superfície de acesso.
O princípio é simples: pedir apenas o necessário, no momento em que é necessário, explicar a finalidade e continuar a oferecer uma experiência coerente quando o utilizador não concede o acesso.