In this post, we will explore composing a One-Tap phone number login experience using Google’s Sms Verification APIs. The premise of a phone number login flow is fairly straightforward. We enter a phone number, get a one-time verification code on the phone, enter the code and voila! Let’s get into the nitty–gritty!

Getting the phone number

Look no further than the docs for Obtaining phone number and we have a good starting point for our solution. The dependencies are listed here. As we are working with Jetpack Compose, we can abstract it as a function and drop wherever we need this functionality.

What’s happening here?

• We create the CredentialClient in LaunchedEffect so it is created only once and used till the composable leaves the composition.
• We use setPhoneNumberIdentifierSupported in building the HintRequest as we are really only interested in phone number hints.
• Instead of using onActivityResult, we are using ActivityResultsContracts to get the result. We launch the IntentSenderRequest using the HintPicker Intent.
• Finally, inside the lambda, we get the credential extra where id is the phone number as we set that in creating the HintRequest object.

This can be used by dropping in the PhoneNumberConsent Composable on the Phone number login screen.

Reading the verification code SMS

Now that we have fetched the phone number and made the login request to our backend, we are expecting an SMS with the one-time verification code so let’s start listening for the message. There are two APIs, Sms Retriever or SMS User Consent, either of them can be used and we’ll cover them both but a more detailed guide to which API might suit you best can be found here.

SMS User Consent API, also known as One Tap verification API is useful when we don’t have control of the contents of the message and the message always contains a 4–10 digit alphanumeric code.

The docs show an example of how that can be achieved and here’s the same behaviour written as a drop–in composable.

What’s happening here?

• Similar to PhoneNumberConsent, we create the SmsRetrieverClient in LaunchedEffect and we call startSmsUserConsent(). The param can be the phone number which can be useful if we know the phone number that will send the message, in our case we set it to null which means we listen to the next message containing an alphanumeric code of 4–10 digits from a phone number that’s not in the contact list.
• On success, we register the broadcast receiver that has the permission similar to what’s mentioned in the docs. We are using the SystemBroadcastReceiver composable from the interoperability docs, which handles unregistering itself on leaving the composition, so when the shouldRegisterReceiver state is set to false, the receiver is unregistered.
• Here again, we are using ActivityResultsContracts to get the result. We launch the ActivityResultContract using the Consent Intent. In case the activity is not found, we catch the exception and the user would have to enter the code manually.
• Finally, inside the LauncherForActivityResult lambda we get the SMS message. The system opens a bottom sheet with the message and the user can allow or deny the permission to read that specific message. We proceed to extract the code from the message and call the onSmsReceived function.

An easy helper function to extract a numerical verification code from a message.

The method above still requires 2 taps (1 for the phone number consent and 1 for SMS bottom sheet permission), let’s try to eliminate the second tap altogether. If the backend service we own can send the message with an 11 digit hash based on the app’s signing key we can eliminate the bottom sheet by directly getting access to the message, autofill the verification code text field and straight away log in the app. Let’s see how we can do that with SmsRetriever API.

The only difference from the Sms User Consent API is that we call startSmsRetriever on SmsRetrieverClient and get the SMS as a String in an extra in the broadcasted message. So we can get rid of the LauncherForActivityResult altogether. The usages for both look quite similar, as we can see here.

Testing with ADB

If you’d like to test receiving the Sms without calling the backend, maybe backend is WIP or you’d like to save costs from a 3rd party phone number authentication service, it’s possible to emulate an incoming message on the emulator with the following command.

Separating country code and national number

If you’d like to separate the country dialing code and national number from the phone number fetched from the device, you can use libphonenumber or libphonenumber-android which is an android optimized version of the same library. Here we have a formatter that is injected with PhoneNumberUtil which basically does all the heavy lifting for parsing the phoneNumber String into a PhoneNumber object which has the countryCode and nationalNumber as fields which are returned as a Pair.