3 Answers
3

It's not intended for anyone to override handleIntent(). That's why it was made final. Also, you'll notice that it's completely missing from the javadocs - that's intentional.

If you want to handle a message in any circumstance (both foreground and background), use onMessageReceived(). The javadoc for that method says:

Called when a message is received.

This is also called when a notification message is received while the
app is in the foreground. The notification parameters can be retrieved
with getNotification().

This should work for data messages, but not notification messages sent from the console. Notification messages have different delivery behavior. See the documentation about message types and how to handle them.

I've read those articles, but when my app is in background, it just receive the notification, but when the user taps on it, the notification is dismissed. I've already developed the logic of click in the notification to direct the user to specific activities. When I used to override the handleIntent, it worked perfectly.
– Guilherme Lima PereiraNov 15 '17 at 16:55

5

This is terrible. We are now unable to upgrade as we have our backend servers sending the same notifications to iOS and android, so all our android push messages have a notification setting. With this change its now impossible for us to render our notifications as desired without the backend system starting to differentiate the messages they send through FCM based on the device receiving the message.
– Jake HallNov 29 '17 at 23:52

1

@JakeHall I'm in the exact same situation, cannot use data only message since iOS would not receive in when app is killed.
– BapJan 27 '18 at 22:32

2

@annihil we ended up having to create our own implementation of a BroadcastReceiver and JobIntentService to receive the FCM messages and explicitly pulling out the intent filters which sent the messages to the FCM classes shipped w/ their SDK
– Jake HallJan 30 '18 at 11:58

1

@JakeHall Do you have that Receiver and JobIntentService open-source anywhere?
– Matt McApr 2 '18 at 0:42

I'd add that in FirebaseMessagingService 11.8.0 docs, it is stated in https://firebase.google.com/docs/cloud-messaging/android/receive that if a notification has a data payload it will call onMessageRecieved() when the app is in the foreground, and if the app is in the background the notification and data payload are delivered in the extras of the intent of your launcher Activity.

So, this means you need to decide how to handle the notification in two places, depending on whether the user is actively using the app or if it is in the background.

As you have seen yourself, if you receive the notification while the app is in the foreground, onMessageReceived() is called and you handle the notification there.

When the app is launched from the background, you have 2 options:

1: By default, the notification is sent to your system tray, and when it is clicked it opens your main activity, passing the data (what would have been remoteMessage.getData() in onMessageReceived()) to your activity as intent extras. You can handle the extras in your main activity like so and decide what to do with them, for instance check for a key value and launch a related intent.

You can decide what intent to open on-click if you add an intent-filter in your app manifest and a designated "click_action" value in your notification, and then handle the intent extras in the designated activity. See https://stackoverflow.com/a/39665485/3746204