Mobilidade é tudo – Android 6.0 e a Política de Permissões

O Android 6.0 (Marshmallow) é a mais recente atualização da plataforma. Assim como aconteceu nas versões anteriores, o números de novas features, frameworks e possibilidades aumentou consideravelmente. Uma delas em especial tem chamado a minha atenção. A nova política de requisição de permissões em tempo de execução.

O impacto dessa mudança será sentido à medida que a nova versão da plataforma começar a ganhar mercado. Segundo dados do início do mês de agosto de 2015, a fatia que o Marshmallow já abocanhou ainda é bem tímida: apenas 0,3%.

A primeira mudança de conceito está na ideia de permissões normais e permissões perigosas. Ou, no bom e velho inglês, normal permission e dangerous permission. O primeiro tipo indica as permissões que não causam riscos diretos de privacidade ao usuário, enquanto que o segundo (as perigosas) pode causar.

Alguns exemplos de dangerous permission: READ_CALENDAR, READ_CONTACTS, CALL_PHONE, SEND_SMS, READ_SMS. Alguns exemplo de normal permission: FLASHLIGHT, TRANSMIT_IR, INTERNET, VIBRATE, USE_FINGERPRINT e SET_TIME_ZONE.

Diferentemente das versões anteriores, nas quais todas as permissões eram configuradas no AndroidManifest.xml e o usuário as aceitava no momento da instalação da aplicação, agora o Android já aceita por padrão as normal permissions e pede permissão de uso ao usuário a cada momento em que uma dangerous permission seja utilizada.

O primeiro grande cuidado é checar a permissão dada pelo usuário no momento de usar uma permissão. Mesmo que a revogação não tenha ocorrido dentro do app, é possível, no Android Marshmallow, acessar as preferências de um aplicativo e mudar completamente as permissões.

Com a biblioteca de compatibilidade do Android, é possível usar o método checkSelfPermission da classe ContextCompat. Como parâmetro do método é passada a permissão que desejamos checar.

int permissionCheck = ContextCompat.checkSelfPermission(thisActivity, Manifest.permission.WRITE_CALENDAR);

Os dois retornos possíveis são: PackageManager.PERMISSION_GRANTED e PERMISSION_DENIED. No primeiro caso, temos permissão de uso e a aplicação pode proceder normalmente. Já no segundo caso, o usuário negou a permissão e o código deve ser suficientemente inteligente para fornecer outra feature ou tratar de maneira adequada a falta desse “recurso”.

Se a aplicação não tiver permissão de uso de uma feature, o próximo passo lógico é requisitá-la ao usuário. A imagem abaixo mostra o diálogo que será mostrado ao efetuarmos essa operação. O diálogo não é customizável:

E se o usuário já tiver negado essa mesma requisição? Ou, ainda, e se a permissão não for tão clara dentro do contexto de uso da aplicação? Em ambos os casos, o desenvolvedor pode programar uma view ou mostrar o seu próprio diálogo antes de fazer a requisição. E para responder à primeira pergunta, temos o método shouldShowRequestPermissionRationale(), que retornará true se a requisição já foi apresentada e negada previamente.

Para requisitar a permissão, usamos o método requestPermission da classe ActivityCompat. Os três parâmetros são: contexto, permissões desejadas e um request code que será recebido no retorno da resposta do usuário.

ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_REQUEST_CODE);

Para saber a resposta do usuário, basta sobrescrever o método onRequestPermissionsResult da Activity. Perceba que o primeiro parâmetro recebido é justamente o request code.

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_REQUEST_CODE: {
            // se a request for cancelada o grantResult vem vazio
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // permissão dada pelo usuário
            } else {
                // permissão negada pelo usuário
            }
            return;
        }
    }
}

Graças à API de compatibilidade, podemos deixar transparente essa mudança de paradigma para o usuário. Basta fazer a nossa parte :).

***

Texto publicado originalmente na Revista iMasters.