Firebase phone auth OTP no longer being read automatically

[vijtheveg]

Android device: Any device
Android OS version: Any version (have tested this starting from OS21 all the way to the latest OS - bug repros everywhere)
Google Play Services version: com.google.gms:google-services:4.3.8
Firebase/Play Services SDK version: com.google.firebase:firebase-auth:21.0.1
FirebaseUI version: com.firebaseui:firebase-ui-auth:7.1.1

Steps to reproduce:
OTP was being read automatically in my app for many months now. It has suddenly stopped working in the last few weeks. There are no specific steps to reproduce - OTP is never read automatically anymore. My code (which has been working for many months now) has not changed at all - it is pretty much the same as the code in the Firebase Auth documentation / samples - nothing special here.

I have verified that the SMS template being used is correct and matches the OTP received. I have also enabled Android SafetyNet / app verification, to no avail.

I filed an issue in the Firebase Auth UI repo (firebase/FirebaseUI-Android#1948) and was directed to file an issue here instead.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[aguatno]

Hi @vijtheveg Thank you for the provided details. I haven't been able to reproduce it on our end yet. A sample project where the issue can be reproduced will significantly help the investigation. Also, let us know if you noticed any patterns like issues occurred on some model devices etc.

[vijtheveg]

Thanks @aguatno, for your response. It takes considerable amount of time to create a working sample app using Firebase auth and given that my code has not changed at all in the past 6 months, and is virtually identical to the code in your documentation, something else is happening.

The only other change that I can think of is that my app name as specified in the Play Store changed from 'MeraBills' to 'MeraBills - Small Business Management & Accounting.'

Consequently, the receive SMS looks like: '697874 is your verification code for MeraBills - Small Business Management & Accounting.' - do you think the presence of the special characters in the app name (-, & and .) may be causing problems with the SMS parsing?

The only LogCat line that seems to appy to this problem is the one below:
2021-05-27 23:52:53.338 21157-21334/com.merabills.merchant_app_android W/System: Ignoring header X-Firebase-Locale because its value was null.

[vijtheveg]

FYI, I removed special characters from the app name - this problem continues to happen

[Iltwats]

Hi, @vijtheveg, @aguatno I have also faced this issue, but for me how this occurred is different. Before publishing my app in playstore in OTP messages there use to be the app's hash value which helped in automatically detecting the OTP messages and authenticating. But since I published it on the play store the hash value got replaced by the app's name and no longer I am able to verify OTP automatically.
I checked out a few documentation where they suggested I add that app's hash value at the end of the OTP message. But unfortunately, I cannot edit the template in firebase auth.
I am attaching the screenshot of OTP messages before and after publishing it to playstore.

This problem is the same with all the devices.
I have used the exact same code mentioned in this firebase doc and earlier it was working fine before publishing to play store.

[vijtheveg]

Thanks, Atul. What is the "app's hash value" - where can I find it?

[Iltwats]

@vijtheveg you can check this link but after generating we can't add it to our OTP messages.

[malcolmdeck]

Hey there, Malcolm from Firebase here. Right now, this is expected behavior - your application's name is long enough that is crowds out the application hash from the SMS. However, I think I might have a way of more appropriately assessing when to include/exclude application hashes that should leave you with fewer pain points. For the moment:

1. There are no workarounds, so just sit tight
2. I'll see whether or not we can do anything, but I can't make any promises as to whether or not I'll be able to remedy the issue. But we'll at least take a look :)