I run an Android app that has users that wish to stay registered for push notifications indefinitely, and many use the app for years. I switched over my push notifications to Firebase last spring, and I'm now getting a significant number of users complaining who, after receiving notifications for months without issue, no longer receive notifications (when I try to send to the tokens I have in my database for them, I get either a InvalidRegistration or NotRegistered, not sure which tbh).
Is anyone else having this issue, and is it an issue with Firebase FCM itself? Perhaps onTokenRefresh isn't being called when it should be at times or something? (I'm certain that my code to give a refreshed token to the server is solid - I had no problems for years with the old GCM, although I had to have a bunch of hacks to re-register periodically in addition to when the user updated the app or the OS)
I see that FirebaseInstanceId.getInstance().getToken() can throw an IOException, perhaps that is killing my onTokenRefresh method before it can start sending the token to the server? Do robust apps take this possibility into account and have a mechanism to retry on failure?
Basically, just looking into any insight into why this is happening, if others are having the same issue, and any workarounds people have found. At the end of my rope over here:/
Related
We provide a service which has collected a lot of GCM registration ids over the last couple of years. We are wondering how many of these are still being used. We send millions of push notifications but we don't know which actually arrives on a device.
I followed the advice of some answers here on StackOverflow to check the validity of registration ids/push tokens using a dry_run flag.
That works fine to sort out tokens that are not valid (like asdf). But I also checked some ids of mine, all of them were valid. Even my oldest token (> 3 years old) of a device that is not in use anymore for 2 years now. Sending notifications to this token will never arrive on a device for sure.
Any idea on how we can check if a token/registration id still delivers notifications?
Thanks!
After some days I came across the FCM statistics panel in the google's developer console. It shows how many messages are sent and how many could be delivered to devices. This does not allow me to judge on individual tokens, but it gets me a general picture.
https://support.google.com/googleplay/android-developer/answer/2663268?hl=en
I have several apps on Google Play that extensively use GCM and they have all been working very well for quite some time now. But, all of a sudden (Aug 12, 2015), GCM is sometimes returning "NotRegistered" when my server posts a message to it.
This is happening just occasionally but that is often enough to cause big problems as the messaging can no longer be trusted.
The last part of the web response stream is: [{"error":"NotRegistered"}]}
I log the registration id along with the response stream and the registration id that I attempted to use is the same one that has always been used for that phone. My apps get a new registration id when they are first ran so it is necessary for the application to be uninstalled and reinstalled to make the app work again. Has something changed?
Oddly, (or not) the problem has only occurred on phones running 5.1 lollipop. Did I possibly miss another breaking change?
Thanks,
Dean
If you are using GoogleCloudMessaging to register, one possibility is that these users received an upgrade of your app. See the latest edit to Eran's answer here.They will need to re-register with GCM. Consider using the latest registration method using Instance IDs, which has a listener for token refresh when needed.
Scenario: I have a 3rd-party app server, a gcm http connection server, and an android app setup for push notifications. When the user uninstalls the app, I can delete them from my 3rd-party server by sending their (no-longer-valid) registration id a push notification and handling the "NotRegistered" error returned from the gcm connection server.
However, this similar approach does not seem to work when you send a push notification to users subscribed to a "Topic", as here the gcm connection server only returns a json object with the "message_id".
The notable columns in my 3rd-party server database table are as follows:
| gcmRegistrationID (string) | subscribedToNotificationTopic (boolean) |
Does anyone know how to identify a user that has previously set true in the subscribedToNotificationTopic column, then uninstalled the app?
I have an idea on how to resolve this, but it seems somewhat messy.
Every so often, instead of only sending push notifications to a topic e.g.
{
"to" : "/topics/global",
...
}
send a push notification to the registration ids of the users subscribed to the topic e.g.
{
"registration_ids" : {list of registration ids},
...
}
such that I can retrieve and handle any "NotRegistered" errors.
The problem with this however, is that multicast messaging has a limit of 1000 users so I'd have to send a message for each thousand.
This seems like bad practice (especially if there is more than one topic involved), but maybe it's the only way?
(Extra tags: topic messaging, pubsub, unregister, google cloud messaging)
First off, I am not sure it is correct to assume that an "NotRegistered" error can only be the result of the user uninstalling your app. It seems like the device can become unregistered if the device receives a message but that message can not be delivered. This can happen if the user stops the app (which is different from uninstalling it, or even if the app was killed and remains stopped due to a power saving mode.
https://developers.google.com/cloud-messaging/ccs#response
If it is NotRegistered, you should remove the registration ID from
your server database because the application was uninstalled from the
device, or the client app isn't configured to receive messages.
What you can do is from the device side, periodically register the device, and make sure that the token you get back is the same as the one you stored, if not update your server with the new token.
As far as detecting if a user has uninstalled your app via a response to a topic message, I agree with you it does not seem to be directly possible. As an alternative to your proposed solution, you might, every now and then include a flag in the topic message that would ask the device to validate itself with your server, if a device does not validate itself after some number of attempts or some period of time you might conclude the user is not longer listening.
The other question is why do you really need to know. Is there any harm in sending some extra regid's to google? If a user quits your web service you can remove them from the list, but do you really need to take action if they just un-install your app from there device? - Just some thing to consider. Hope this helps.
I'm trying to migrate from C2DM to GCM, and it mostly works just fine. C2DM used to handle uninstalls of the app very well by sending a NotRegistered error when the user uninstalled the app. GCM supposedly does this as well (albeit not guaranteed). However, it doesn't seem to be working. After sending multiple GCM notifications to a phone which has uninstalled the app, it still keeps responding with a normal "id=..." response.
Has anyone else come across this problem? If so, how did you solve it?
There's really nothing we can do about it. Only Google knows when an app is uninstalled and update their device registration database accordingly. Perhaps it takes a couple of hours for NotRegistered response to come back? If after a day, you're still not getting that, then file a bug report with them: http://code.google.com/p/android/issues/list
I can't imagine Google will let this bug stay for too long, as they are potentially looking at sending phantom notifications to thousands or hundred thousands of devices.
I've been migrating from C2DM to GCM, and I thought I was having this problem as well. Long story short, try uninstalling the app from your phone/emulator, then dont reinstall it on that phone/emulator and leave the phone/emulator running for a few hours, then you should get the NotRegistered error if you try to push to that device's registration id.
If I recall correctly even if you reinstalled the app in C2DM after uninstalling you'd get the NotRegistered error for the first registration id, this is not the case with GCM (usually if not always the two registration id's will be the same) and I spent a week thinking GCM had some bug where it wasn't sending that error...
So I have a strange problem, my app has C2DM setup and and it works for the most part, however there is quite a few people who never get registered. So the flow is as follows. On login, we make the registration request, when we get the response on that it submits the registration id to my back-end server and stores it in the database. For some reason I can see that some people logged in just fine, but I never received the registration id on the server, any ideas? I haven't be able to reproduce this my self, but it is affecting a lot of people using my app. Any suggestions on how I can make this more reliable? Because when the C2DM does not work they tend to not stay and use my application.
Any help or advice would be much appreciated.
What do you do on the client side if the registration fails? It could fail for a number of reasons. It'd probably be a good idea to send the status to your backend in failure cases so you can track that. Personally, The most common failures I see are due to not having a logged in google account or having background data turned off in settings.
Could the users in question be on unsupported (pre 2.2) devices?
C2DM in intended for android devices running Android 2.2(API 8) or higher that also have the Market application installed. However, you are not limited to deploying your applications through Market.
Also make sure you make the C2DM registration at very beginning of app start say splash screen. As the C2DM to register and obtain the REG_ID take about 3-4 sec depending upon the network connection.
Also make sure the devices that it is having problem that you reported might be showing the ACCOUNT MISSING:: OR ERROR IN REG_ID when C2DM registration works