I am getting an error when I try to send messages via the Firebase Notification screen in the console. It says I have an invalid token format, but I have used previously used tokens collected with the same method successfully.
I was not getting this error a few days ago, and notifications were working properly. I just pushed an update to the Google Play Store recently, but this update did not touch any code relating to the notifications.
status.firebase.google.com says that notifications are currently up. All other Firebase usages in my app (database, storage, auth) are working properly.
When I updated my app, I did not change my google-services.json file at all. Do I need to do some sort of update to this file, or some sort of version change on the Firebase Console to keep the versions consistent between the APK and the console?
As mentioned by #Arthur Thomson (in the comments), your registration token may change as a result of an update in the application. It does matter that you did not change the google-services.json if the user reinstalled or updated the application the token maybe changed.
According to the docummentation about the device registration token, the registration toke may change when:
The app deletes Instance ID
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
So you would need to retrieve the new registration token using the onTokenRefresh() method in your Android client application. I mean, you just need to implement a code to retrieve the new token if it changes.
Hope this helps
Related
I'm using Firebase Phone Auth to identify the user, the sms is received but I need to change the SMS sender name (Not the template) in mobile, is there anyway to change the sender name or the messaging service?
The sms is received like:
Phonecode
106109 is your verification code for MyAppName
what I need is:
MyAppName
106109 is your verification code MyAppName
As for now, We simply can't change the template nor sender name/number. We can only see in which template user will get SMS.
Additional Info:
Until your app gets live, your format will be *%LOGIN_CODE% is your verification code.
After upload app on google-play-store, format will be %LOGIN_CODE% is your verification code for %APP_NAME%.
the app name displayed in the SMS can't be changed manually (neither can you modify the template).
The app name is retrieved from the play store/app store once the app is live in the store.
This wasn't 100% clear to me after reading Rumit's answer.
here is the response from the firebase support about this matter:
The SMS messages draw the app's name from the App Store / Play Store.
Once an app is published, the correct name should start appearing.
There may be a small delay (a week or two at most). So, this is an
expected behavior if you published the app a few days ago.
But if the app is published and you are still not able to see the
app's name, it's possible that someone else has registered the user's
App's Application ID (Usually the same as the Package Name - for
instance, com.example.myapp) on the Play Store with a different name
(which is the name shown as the %APP_NAME% value on the SMS template).
Firebase pulls %APP_NAME% from the Play Store based on this
Application ID.
Since Application IDs in Google Play must be unique, you can't use an
ID that is already taken by someone else.
To fix this, you can change your Application ID and register the new
one in the package name field in the Firebase Console.
This is the response I got from Firebase support team as of March 19, 2021.
hi am also using firebase messages for send otp on mobile numbers. I also want to show my app name in text message but there is a firebase document that you can't change body of message in firebase. You can select the language from the Firebase console, however this is a per project setting and you can't modify the templates.
Go to Firebase>Authentication>Templates>Password Reset> Put %APP_NAME%
I have an Android app with firebase notification services currently on deployment.
The google-services.json file associated with it had wrong entries.
I fixed the .json file and firebase services are now working as usual for newly installed apps.
But for current users it is not working (Because it is still using the old token).
Called when the system determines that the tokens need to be refreshed. The application should call getToken() and send the tokens to all application servers.
This will not be called very frequently, it is needed for key rotation and to handle Instance ID changes due to:
App deletes Instance ID
App is restored on a new device
User uninstalls/reinstall the app
User clears app data
The system will throttle the refresh event across all devices to avoid overloading application servers with token updates.
I tried deleting the instanceId programmatically (So I get a new token); it gets deleted (no exception is thrown) but then the new token is the same as the old one.
Shouldn't changing the google-services.json trigger a token change automatically?
How can I solve this without re-installing the app for current users (on update)?
I am using the latest versions of Firebase and google-services (in Gradle).
You can update your app by submitting the new apk to the play store. So after old customers update your apk old customers will be replaced by new apk and new google-services.json file. Make sure your code is written to call the onRefreshToken() method and get the new token and send it to your server for further communication. When this is updated. All your new customers will be able to receive the notifications.
#Override
public void onNewToken(String s) {
super.onNewToken(s);
Log.d("NEW_TOKEN",s);
}
I would like to know what the default authentication period for users to be logged into Firebase is. I have an Android app where users are logging in via email/password and I want to know how long FirebaseAuth.getInstance().getCurrentUser() will remain not null.
In the previous version of Firebase, the default length of time was 24 hours and could be modified via the firebase console. Is the default amount of time still 24 hours? Can this be modified via the console? (I cannot seem to find anything regarding this in the latest version of Firebase)
I realize this question is six years old at this point, but as mentioned in the comments, the user lifecycle states that the user token will expire and that in that event, the refresh token will be used to automatically reissue a set of new tokens for the user when using the SDKs. This allows the user to continue using the app without issue and does not force the user to re-authenticate into the app when their session token has expired.
I've got an Android application that uses Firebase password and email authentication and the real time database. This all works completely fine when the user has just logged in.
However maybe a few hours later data will stop being shown even if the data changes in the database, it almost seems as though the user is no longer authenticated. But when I connect my device to the adb I can see in the log that the user is logged in with the correct uid and there are no errors being reported. The only strange thing I noticed is that there is no network requests in the network monitor.
Can anyone shed some light on what is happening? I'm not sure if it's a database problem or an authentication problem. I can provide any information needed
EDIT
Marked answer down below but also take a look at these instructions also when adding your SHA1 Keys to firebase, add both production and dev copies
You need to add SHA1 of your debug and production certificates to Firebase console.
It is needed so firebase knows your app has access to refresh access token.
Docs Reference: https://firebase.google.com/support/guides/launch-checklist
From the GCM docs:
When an application is updated, it should invalidate its existing
registration ID, as it is not guaranteed to work with the new version.
Because there is no lifecycle method called when the application is
updated, the best way to achieve this validation is by storing the
current application version when a registration ID is stored. Then
when the application is started, compare the stored value with the
current application version. If they do not match, invalidate the
stored data and start the registration process again.
When the docs state that "it is not guaranteed to work with the new version" is that a GCM limitation or are they speculating about potential changes in my app's behavior from version to version?
From the app side I can more-or-less guarantee that successive versions will function properly with respect to GCM and whatever app-specific message format I concoct. Do I still need to re-register?
If so, which should I use to detect a "new version": version code or version name? My understanding is that these are "free form" and the app developer sets them to whatever values he chooses. So, what if I put an app update in the store but don't change versionName or versionCode; would I need to re-register with GCM?
It seems like what GCM actually wants is for the app to re-register each time a new installation is launched for the first time (and each time it's successively launched until registration is complete), regardless of the values in versionName and versionCode. Is that an accurate statement?
I don't remember where we've read it, but it came to our attention that when a device gets a push while an app is not installed, Google will invalidate the registration id.
This makes sense if the app is really uninstalled, but if the device was actually in the middle on an update, it quickly uninstalls and re-installs, so google might mistakenly think the registration needs to be invalidated.
The solution seems like to re-register on the first launch after an update, to guarantee your app registration id is active.
Version code is indeed a freely selected number, but you must increase it on every new version you publish to google play, so you can check if that number has changed, and know your app had been updated and you need to refresh the registration.
EDIT:
This is also relevant to C2DM's successor GCM, with a lot more docs explaining this behavior and how to properly write code.
See: http://developer.android.com/google/gcm/client.html with all the details.
Specifically this code, where getRegistrationId will return an empty string in case the version code changed forcing the client to register again:
if (checkPlayServices()) {
gcm = GoogleCloudMessaging.getInstance(this);
regid = getRegistrationId(context);
if (regid.isEmpty()) {
registerInBackground();
}
} else {
Log.i(TAG, "No valid Google Play Services APK found.");
}
I would use the Version Code to detect the app update. The Version Code is forced to change every time you submit a new version to the Google Play store, hence you can rely on it to detect the app's version.