FCM token update problem

[InI4]

Description

Users of my app claim app notification to be unreliable. As it turns out FCM notifications run fine, after app has run, but then disappears. There is a background FCM topen update problem. I have a corresponding listener in my app, that triggers both, forwarding the token to my apps FCM functions and to the Twilio stack. My own FCM stuff is working reliably. The Twilio code is a hardly modified copy of your (Java!) demo project.

After checking my (Java) and here (Kotlin) code, without having access to the native parts, it seems like your code makes strong assumption of both uninterrupted network connection and the lifecycle of TwilioApplication and BasicChatClient. Doesn't FCM need a path disregarding this?

Steps to Reproduce

1. Start the app.
2. Get notifications.
3. End the app.
4. Still get notifications for a while.
5. Then, you do not get notifications any more.

Expected Behavior

Update FCM token, even when app is not running.

Actual Behavior

Update of FCM token seems to fail often.

Reproduces how Often

As there is timing and Android resource management involved and this is based on user reports I have no data. Some users seem to get notifications only a few minutes after app has run, some do not seem to have a problem.

Chat Android SDK

2.0.8 and 2.0.11 and many older.

Android API

Android 7.1.1 definitely has problems.

Android Device

various reports

[berkus]

Hi,

the demo application FCM code does not handle the backgrounding/shutdown scenario, you should handle that yourself. In the future I may add such handling code to the demo application but it is not present at the moment.

[InI4]

As said the app itself does the successfully, but the suggested call to Twilio code fail.

Problem is, this is a bit of a black box as it ends up calling Twilio components and it is at least not clear to me, what properties this component requires to update the FCM token. I mean you can hardly require a user logon as logon might require user interaction not feasible in background.

[berkus]

You need at least a working ChatClient, once user is logged in the token can be refreshed in the background without additional interactions.

Your FCM service may arbitrarily defer invoking ChatClient's processing depending on your usecases. E.g only launch ChatClient and handle the push if the app is actually foregrounded.

[InI4]

But then it can hardly be called a push. We would really like to have a message something was happening while App was not running.

[berkus]

You will receive push in the FCMListenerService. Afterwards its up to you, if you want to grab existing ChatClient, or instantiate a new one, and do something, or just display the push and do nothing until the user actually clicks on it.

[berkus]

The FCM token update can be done in background but it's up to your service called InstanceIDService to handle that.

[berkus]

Your FCM token storage should keep the token somewhere in persistent storage and update it whenever google FCM invokes your InstanceIDService.

You need to do a few checks also: if ChatClient is still up and running, unregister old FCM token and register a new one; if it isn't - start one and register an FCM token for it.

[InI4]

The problem is, that my InstanceIDService needs a full logon for security reasons, however I cannot get a full logon when FCM Token update happens while app is in background. As Twilio-API is using device IDs in many places, I expected it, to attach tokens to device IDs, not accounts.

[berkus]

a full logon for security reasons, however I cannot get a full logon when FCM Token update happens while app is in background

Why not? You have a token, just login using that token and that's it.

[InI4]

My app is built to need a Google Account login to Instances service. This login expires and then I am stuck.

[berkus]

Ok, this does not seem to be related to Twilio then.

[InI4]

Well, yes, but I do not consider this security mechanics too exotic ..

[berkus]

The InstanceIDService is supposed to work without logging in, this is described in Firebase docs and examples.

[InI4]

As I moved on to v3.0 (in production, hopefully soon 4.2.6) and 4.2.5 in test, I cannot give input with these issues any more. Close it, or keep it, I do not mind.

[berkus]

The notification library callbacks have been improved in 5.0.

As this is related to very old version and specifically Google SSO logins, closing it.