DEV Community: Murillo Alves da Silva

Lendo SMS em dispositivos android

Murillo Alves da Silva — Mon, 10 Apr 2023 19:37:01 +0000

Introdução
A verificação em dois fatores é amplamente utilizada, visto que garante maior segurança tanto para a empresa quanto para o usuário, pois confirma que o recurso está sendo acessado pelo titular da conta. Com isso, foi desenvolvida uma API que permite a leitura de SMS recebidos em tempo real. Neste artigo, abordaremos essa forma de verificação e como ela é suportada usando conceitos de broadcast receiver.

Prós e contras da API
Como todo recurso de software, existe prós e contras e deve ser resguardado para se utilizar em uma ocasião que realmente traz mais benefício do que malefício.

Os pontos fortes da API SMS Retriever são:

Sem permissões no manifest
API mantida pela criadora do android, a Google;
Fácil implementação.

Os pontos contras:

Permissão de consentimento único. Enquanto o aplicativo estiver em execução, só consegue ler o SMS única vez;
Documentação da API desatualizada com alguns métodos;
É necessário fazer manipulações para pegar o SMS e implementar um regex para pegar o código de verificação.

O que de fato é essa API e por que deve usar ela?
A API SMS Retriever, é o principal e único recurso de aplicativos que não tem como objetivo principal o tratamento de mensagens e ligações. Com isso, em um aplicativo que se adequam a esses requisitos, como Whatsapp, Telegram e entre outros conseguem fazer a verificação por SMS através de apenas um broadcast receiver e permissões, seja em tempo de execução (programáticamente) quanto no manifest. Antes, era bem comum os aplicativos pegarem o SMS do usuário com essas permissões, mas em 2018, a Google tirou essa flexibilização devido o uso indevido do recurso.

Implementação

Dependências: Adicione no build.gradle do app essas dependências:

    implementation 'com.google.android.gms:play-services-auth:17.0.0'
    implementation 'com.google.android.gms:play-services-auth-api-phone:17.4.0'

Declarando as váriaveis

    private lateinit var smsClient: SmsRetrieverClient
    private val broadcastReceiver = SmsBroadcastReceiver()
    private lateinit var resultLauncher: ActivityResultLauncher<Intent>

Instanciando e registrando o SmsClient

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        resultLauncher()
        smsClient = SmsRetriever.getClient(this@MainActivity)
        val actionId = IntentFilter()
        val intentFilter = IntentFilter(SmsRetriever.SMS_RETRIEVED_ACTION)
        registerReceiver(broadcastReceiver, intentFilter)
        configureFieldsWithSMS()
        initSmsClient()
    }

Criando listeners de sucesso e erro para o usuário:

interface States {

    fun onSuccess(consentIntent: Intent)
    fun error(typeError: TypeError)

    companion object {
        var statesResult: States? = null
        fun instanceStates(states: States) {
            statesResult = states
        }
    }
}

Colocando para detectar o primeiro SMS a ser recebido

Caso dê erro, entra no onFailure e se der sucesso para poder detectar os SMS a ser recebido, entra no onSuccess. Caso não receba um SMS a 5 minutos, ele entra em Timeout.

 fun initSmsClient() {
        smsClient.startSmsUserConsent(null).addOnSuccessListener {
            Toast.makeText(this, "Esperando pelo SMS", Toast.LENGTH_LONG).show()
        }.addOnFailureListener {
            Toast.makeText(this, it.message.toString(), Toast.LENGTH_LONG).show()
            it.printStackTrace()
        }
    }

Configurando o broadcast receiver

Para processar as transmissões e eventos, é necessário utilizar um broadcast receiver, registrar ele na activity e passar um IntentFilter (assim como está no onCreate)

class SmsBroadcastReceiver() : BroadcastReceiver() {

    private fun <T>configureParcelable(parcelable: String, intent: Intent, classParcelable: Class<T>) : T? {
        return if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            intent.extras?.getParcelable(parcelable, classParcelable)
        }else{
            intent.extras?.getParcelable(parcelable)
        }
    }

    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == SmsRetriever.SMS_RETRIEVED_ACTION) {
            try {
                val smsRetrieverStatus = configureParcelable(SmsRetriever.EXTRA_STATUS, intent, Status::class.java)

                when (smsRetrieverStatus?.statusCode) {
                    CommonStatusCodes.SUCCESS -> {
                        val consentIntent = configureParcelable(SmsRetriever.EXTRA_CONSENT_INTENT, intent, Intent::class.java)
                        consentIntent?.let { States.statesResult?.onSuccess(it)}
                    }

                    CommonStatusCodes.ERROR -> {
                        States.statesResult?.error(TypeError.ERROR)
                    }

                    CommonStatusCodes.TIMEOUT -> {
                        States.statesResult?.error(TypeError.TIMEOUT)
                    }
                }

            } catch (exception: java.lang.Exception) {
                States.statesResult?.error(TypeError.EXCEPTION)
                exception.printStackTrace()
            }
        }
    }
}

Apresentando o SMS para o usuário

 private fun configureFieldsWithSMS() {
        States.instanceStates(object : States {
            override fun onSuccess(consentIntent: Intent) {
                resultLauncher.launch(consentIntent)
            }

            override fun error(typeError: TypeError) {
                Log.d("ERROR", typeError.name)
            }
        })
    }

Processando resposta do usuário: Caso o usuário deu OK ao consentimento de ler SMS, conseguiremos ler a mensagem. Com isso, é necessário resgatar esse código no activityResult

private fun resultLauncher() {
         resultLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result->
            if(result.resultCode == Activity.RESULT_OK) {
                val sms = result.data?.getStringExtra(SmsRetriever.EXTRA_SMS_MESSAGE).toString()
                Toast.makeText(this@MainActivity, sms, Toast.LENGTH_LONG).show()
            }
        }
    }

Criando a mensagem no emulador: Para simular, é necessário seguir um padrão de mensagem especificada pela Google.

Com isso, já que não temos um server side para mandar o SMS com códigos, iremos configurar manualmente no emulador e mandar por lá mesmo.
Clique nas configurações do emulador (3 pontos):
Vá na opção Phone do lado esquerdo e depois insira um texto com os padrões especificados acima. Exemplo: teste 1234.

Com isso, será apresentando o bottomSheet pedindo o consentimento:

E caso o usuário dê o aceite, o SMS será apresentando na tela em forma de Toast:

Caso queira ver o código todo, ele se encontra neste repositório do github.

Contate-me
Linkedin

Garantindo a execução de alarmes no modo soneca do Android

Murillo Alves da Silva — Sun, 02 Apr 2023 21:27:32 +0000

Introdução
A medida que novas versões do android vão surgindo, são criadas diferentes formas de trabalho e acesso aos dados do ecossistema. Diante disso, desde a versão do android 6, a Google vem tratando a forma que os serviços são executados, visando uma boa experiência do usuário e diminuindo riscos em potenciais.
A Google também avançou em diversas ferramentas para trabalhos em segundo plano e agendamentos de tarefas, no qual podemos citar: AlarmManager, WorkManager(oficial) e Firebase JobDispatcher. A medida que crescia a popularidade dessas ferramentas, a preocupação com o consumo de bateria também aumentava.
Em suma, o consumo de bateria diminui quando estamos executando alguma tarefa em segundo plano, visto que a execução dela pode ser feita de diferentes formatos, desde uma vez a cada hora e até de maneira recorrente com poucos intervalos de 10 segundos.
Com isso, a partir do android 6, foi introduzido o modo Soneca e amplamente apoiado pela comunidade.

O que é o modo soneca?
O modo soneca no android é uma forma de economizar bateria quando o dispositivo está muito tempo sem interação, ou seja, o celular só entra neste modo quando o usuário não utiliza. Sendo assim, o modo soneca entende que o dispositivo não está sendo utilizado e barra qualquer alarme, notificação, acesso a dados remotos e até tarefas que estão sendo executados em segundo plano, mas com uma condição: Essas tarefas, alarmes, notificações e etc são executados, mas em um formato de janela e varia com o tempo.

O que são as janelas de execução?
As janelas de execução são feitas para poder executar qualquer tarefa quando o dispositivo estiver no modo soneca. A partir da janela, o sistema operacional aciona algumas tarefas e coloca em uma janela. Com isso, todas as tarefas são executadas naquele período. O problema é que a medida que uma janela é colocada, a próxima executa em um tempo maior que a outra, sendo assim, a tarefa que era para ser executada a cada 30 segundos, naquela janela ela será executada daqui a 30 minutos e prejudicando o seu aplicativo.

AlarmManager
Não vamos nos aprofundar nesse momento com o alarmManager, mas é necessário termos um breve conhecimento.
Segundo a documentação do AlarmManager, ele é uma ferramenta para realizar operações baseadas em tempo fora da vida útil do seu app. Em qualquer projeto tem seu caso de uso, mas podemos imaginar uma o conceito de despertador, mas imaginemos o seguinte: o despertador só sabe que precisa tocar todos os dias as 16:30 horas porque foi programado através do alarmManager para ele realizar aquela operação.

Problemática
Temos um seguinte problema e precisamos resolver ele urgente: Um grupo de desenvolvedores criaram um aplicativo que gerencia o tempo de estudos dos usuários. Logo após o desenvolvimento, eles notaram que aqueles estudantes que passavam um bom tempo sem o celular começaram a reclamar que o dispositivo não estava tocando no horário programado e ocasionando em tempos indevidos de estudos.
Basicamente, é isso que vamos resolver aqui. Será criado uma solução para este problema e fazer com que o dispositivo toque mesmo no modo soneca.

Implementação
Criando um projeto android, iremos criar a classe IdleAlarmManager, onde fica responsável por configurar toda ação de alarme do aplicativo.

IdleAlarmManager

class IdleAlarmManager(context: Context) {
    private val alarmManager = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
    private val alarmIntent =
        PendingIntent.getBroadcast(context, 0, Intent(context, AlarmReceiver::class.java), 0)
    private val calendar = Calendar.getInstance().apply {
        timeInMillis = System.currentTimeMillis()
        set(Calendar.HOUR_OF_DAY, SUA_HORA)
        set(Calendar.MINUTE, SEU_MINUTO)
    }

    fun setAlarmManager() = alarmManager.setExactAndAllowWhileIdle (
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        alarmIntent
    )
}

Explicação do código acima:

É criado uma pendingIntent e passando qual broadcast receiver deve ser chamado quando o alarme for disparado.
O objeto calendar é utilizado para definir o horário que o alarme será disparado.
A parte mais importante do código: O metódo setAlarmManager() faz a configuração do alarme e a sua característica, no nosso caso, um alarme que dispara mesmo no modo soneca.
- o metódo setExactAndAllowWhileIdle() garante que o alarme será chamado mesmo quando estiver no modo soneca, diferente do setAndAllowWhileIdle(), no qual não tem total garantia. Este método exato ou o outro deve ser chamado para que o alarme seja tocado. Se for usado qualquer outro método, só será disparado quando o dispositivo sair do modo soneca. Lembrando que ambos podem haver atrasos em disparar esse alarme.

Depois, para mostrar a notificação após o alarme ser executado, será necessário criar um broadcast receiver e registrar no manifest. O broadcast receiver permite que um aplicativo receba mensagens ou "broadcasts" do sistema operacional ou de outros aplicativos, mesmo quando o aplicativo não está em execução. O metódo onReceive() é chamado toda vez que recebe uma mensagem do sistema.

Android Manifest

        <receiver android:name="com.github.tumusx.idle.alarmManager.AlarmReceiver"/>

AlarmReceiver

class AlarmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
            val builder = NotificationCompat.Builder(context, SEU_CHANNEL_ID)
                .setSmallIcon(R.drawable.notification)
                .setContentTitle(SEU_TITULO)
                .setContentText(SUA_MENSAGEM)
                .setStyle(
                    NotificationCompat.BigTextStyle()
                        .bigText(SUA_MENSAGEM)
                )
                .setPriority(NotificationCompat.PRIORITY_DEFAULT)
            val name = SEU_NOME
            val description = SUA_DESCRICAO
            val channelNotification = NotificationChannel(
                SEU_CHANNEL_ID,
                name,
                NotificationManager.IMPORTANCE_HIGH,
            ).also {
                it.description = description
            }
            val notificationManager = context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
            notificationManager.createNotificationChannel(channelNotification)
            notificationManager.notify(SEU_CHANNEL_ID, builder.build())
}

Não irei entrar em detalhes sobre o código acima pois não é o objetivo tratar notificações, mas em resumo, toda vez que o alarme for disparado, será construído e mostrado uma notificação para o usuário.

NÃO É POSSÍVEL ALTERAR PROGRAMATICAMENTE O MODO SONECA NO ANDROID

Para testar se realmente o alarme está sendo despertado no modo soneca, é necessário executar alguns comandos para forçar o dispositivo a entrar no modo soneca:
Com o seguinte caminho, abra o cmd:

C:\Users\SEU_USER\AppData\Local\Android\Sdk\platform-tools>

adb shell dumpsys deviceidle enable: Força a entrar em modo econômico;
adb shell dumpsys deviceidle force-idle: Força a entrar em modo soneca;
adb shell dumpsys deviceidle get deep: Checa o estado atual do dispositivo. Se retornar a mensagem IDLE, ele está em modo soneca;
adb shell dumpsys deviceidle unforce: Remove o dispositivo do modo soneca.

Caso queira consultar o repositório, se encontra no github.

Considerações finais
Como foi mostrado, é possível sim executar alguns processos mesmo quando o dispositivo estiver no modo soneca. Lembrando que o uso dessa implementação, o modo soneca não é desativado. Apenas garante que o alarme seja disparado quando estiver neste modo.
Existe outra solução para o problema, mas é utilizado o Firebase Cloud Messaging e a notificação tem que ser definida como prioridade alta.

Contate-me
Linkedin