Guia rápido de alarmes no Android 12
O Android 12 trouxe diversas mudanças e uma delas, uma que gera algumas dúvidas, é a nova permissão de alarme exato. Esse artigo é um guia rápido e leve sobre essa nova permissão, explicando porque, como e quando usá-la. É a primeira vez que escrevo um artigo nesse formato mais leve e todo feedback será bem vindo. 😊
O que é essa permissão?
Essa nova permissão de alarme exato (SCHEDULE_EXACT_ALARM) surgiu com o objetivo de economizar recursos de sistema. Alarmes que precisam ser executados em um horário exato podem ser executados enquanto o celular está em economia de energia ou no modo Soneca, fazendo o app gastar mais bateria do que deveria.
Quando eu devo usar essa tipo de alarme exato?
O Google recomenda que esse tipo alarme seja utilizado apenas em duas situações:
- O app é um despertador ou temporizador
- O app tem eventos de ação com precisão, como notificações de tarefas e eventos
Que tipo de permissão é essa?
Essa permissão é do tipo “Acesso especial a apps” (Special app access). Você consegue encontrá-las em Configurações > Apps > Acesso especial a apps > Alarmes e lembretes. Essa permissão já é dada no momento da instalação do app. Para o usuário revogá-la, ele precisa ir nessa tela e fazer manualmente.
O que acontece quando o usuário desabilita essa permissão?
Primeiramente, todos os alarmes exatos já criados são deletados e não irão funcionar. Além disso, caso alguma função seja chamada configurando um alarme exato, o aplicativo irá encerrar (crashar) com uma exceção do tipo SecurityException.
Meu app usa AlarmManager, preciso mudar alguma coisa?
Depende. Se o aplicativo usar os métodos do AlarmManager que definem um alarme exato será necessário algumas mudanças. Os métodos que definem esse tipo de alarme são:
setAlarmClock()setExact()setExactAndAllowWhileIdle()
Caso esteja usando o AlarmManager com métodos como set(), setInexactRepeating(), setAndAllowWhileIdle() ou setWindow() não será necessário se adequar a esse novo requisito.
Meu app usa WorkManager, preciso alterar alguma coisa?
Não. O WorkManager foi desenvolvido respeitando as otimizações do sistema e não há garantias que ele será executado no exato momento que foi configurado. Essa nova regra se aplica somente a métodos exatos do AlarmManager.
O que eu preciso fazer no meu app para me adequar?
São necessários alguns passos para continuar usando alarmes exatos no Android 12, assim como alguns cuidados para manter a estabilidade do seu aplicativo.
1. Adicionar a nova permissão no AndroidManifest.xml
O primeiro passo é adicionar a nova permissão SCHEDULE_EXACT_ALARM no AndroidManifest.xml. Caso ela não esteja sendo encontrada pelo Android Studio, tenha certeza que o app está sendo compilado na API 31 (compileSdkVersion = 31).
2. Verifique se possui permissão antes de definir alarmes
Como essa permissão pode ser revogada a qualquer momento pelo usuário, é recomendado que seja feita uma verificação antes de definir qualquer novo alarme exato. Para isso, o AlarmManager possui um novo método:
O método canScheduleExactAlarms() retorna um booleano informando se a permissão está ativa ou não.
3. Direcionar o usuário para conceder a permissão
Caso o método de verificação retorne false, o recomendado é mostrar uma informação para o usuário de porque essa permissão é importante para o seu app e direcioná-lo para a tela de “Acesso especial a apps”. Para isso, podemos usar a seguinte Intent:
Vale ressaltar que essa Intent não irá abrir diretamente na tela de permissão do seu aplicativo. Ela irá direcionar o usuário para a tela de “Alarmes e lembretes” com a lista de todos os apps que precisam dessa permissão. Então é uma boa ideia deixar essa informação clara antes de direcioná-lo.
4. Registrar um BroadcastReceiver para ser informado da mudança de estado da permissão
Também é recomendado criar um BroadcastReceiver para receber a informação de quando o usuário ligar a permissão de alarme novamente para o seu app. Essa informação é muito importante porque, como mencionado anteriormente, quando o usuário revoga a permissão, todos os alarmes exatos são deletados. Com essa informação é possível redefini-los.
Para aplicativos que já trabalham com alarmes, o procedimento é o mesmo para quando o celular é desligado: os alarmes são removidos pelo sistema e quando ele é ligado novamente, recebemos o RECEIVE_BOOT_COMPLETED para redefinir os alarmes.
O BroadcastReceiver terá mais ou menos esse formato:
Essa intent de ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED pode ser recebida tanto de um receiver registrado em tempo de execução quanto registrado via AndroidManifest. No nosso exemplo, registrando ele via manifest ficaria assim:
Um ponto muito importante é que esse broadcast apenas será enviado pelo sistema quando o usuário conceder a permissão novamente para o seu aplicativo. Esse broadcast não será enviado quando o usuário revogar a permissão. Dependendo da experiência que quer proporcionar ao seu usuário, seja interessante verificar a permissão toda vez que o usuário entrar no seu app e informá-lo sobre o estado atual.
E agora?
As mudanças no geral são bem simples de serem feitas, mas é essencial uma boa testagem já que elas podem impactar bastante a usabilidade do seu aplicativo.
Se você quiser acompanhar essa mudança em um aplicativo mais estruturado, recomendo esse pull request que fiz no Alkaa. O meu aplicativo pessoal é um aplicativo de lembretes, que foi diretamente impactado por essa mudança. Pode ser legal dar uma olhada em um ambiente mais complexo para ajudar na implementação do “mundo real”.
Materiais externos
Vou deixar uma lista de documentações oficiais do Android com mais detalhes dessa e de outras alterações necessárias para o Android 12.
Muito obrigado por ler o meu artigo. ❤️
