Data message not received when app's in the background

[creatio-ua]

[REQUIRED] Please fill in the following fields:

• Unity editor version: 2020.3.18f1
• Firebase Unity SDK version: 9.1.0, 9.3.0
• Source you installed the SDK: dotnet4/FirebaseMessaging.unitypackage
• Problematic Firebase Component: Messaging
• Other Firebase Components in use: none
• Additional SDKs you are using: Unity Package: Mobile Notifications 2.0.2
• Platform you are using the Unity editor on: Mac
• Platform you are targeting: Android
• Scripting Runtime: IL2CPP
• Pre-built SDK from the [website]

[REQUIRED] Please describe the issue here:

If I'm sending a message as "data message" (only "data", no "notification" in the message JSON), it behaves in one of the following ways:

• app in foreground - everything's fine (OnMessageReceived fires).
• app in background or killed state - no message appears in the system tray (i.e. no signs of the message being received).

I've got custom MainActivity (builds from a separate project in Android Studio) and it has the base class according to the docs: com.google.firebase.MessagingUnityPlayerActivity

I've also added to the main app manifest, AndroidManifest.xml the following lines:

   <!-- Main activity -->
   <activity android:name="com.google.firebase.MessagingUnityPlayerActivity" ...
...
    <service android:name="com.google.firebase.messaging.MessageForwardingService"
        android:permission="android.permission.BIND_JOB_SERVICE"
        android:exported="false" >
    </service>
...
    <meta-data android:name="firebase_messaging_auto_init_enabled"
             android:value="false" />
    <meta-data android:name="firebase_analytics_collection_enabled"
             android:value="false" />
    <meta-data
        android:name="com.google.firebase.messaging.default_notification_icon"
        android:resource="@drawable/ic_notification_sign" /> <!-- This is the icon, that's added into Plugins/Android/res/drawable-XXXXXX -->

The icon exists in 5 size variations. The code in C# is taken from here: https://github.com/firebase/quickstart-unity/tree/master/messaging/testapp

But that didn't help. Also I tried to implement all the steps, mentioned in this workaround here: https://github.com/firebase/quickstart-unity/issues/877

But it didn't improve the situation.

Steps to reproduce:

• Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? Yes, reproduced in 100% cases

• What happened? How can we make the problem occur? Send a "data message" (without "notification" payload) to the app (made with Unity 2020.3.18f1 and Firebase Messaging 9.3.0), when the app is in the background or in killed state.

• Test sample https://drive.google.com/file/d/1y1V8NRZ_iO4UgveNnmBUew_HuoCGSZzv/view?usp=sharing

[paulinon]

Hi @creatio-ua,

Thanks for reporting this. I see that you provided a sample project, but I don't seem to have access to it. It would be great if the project be shared without the access issue.

[creatio-ua]

Hi @creatio-ua,

Thanks for reporting this. I see that you provided a sample project, but I don't seem to have access to it. It would be great if the project be shared without the access issue.

Excuse me, it should've worked. Please try this one: https://drive.google.com/file/d/1kreOOKvDIGEzHiBriWcmR9N6IHfga2sm/view?usp=sharing

[paulinon]

Thanks for the update, @creatio-ua. I've encountered an issue upon building the sample project saying:

Exception: OBSOLETE - Providing Android resources in Assets/Plugins/Android/res was removed, please move your resources to an AAR or an Android Library. See "AAR plug-ins and Android Libraries" section of the Manual for more details.

Were you able to encounter this error message as well? If so, what steps did you perform as a workaround? It would be great if you list the complete steps to replicate the issue in order to identify the cause of this behavior.

[creatio-ua]

@paulinon

Were you able to encounter this error message as well?

I saw only the warning message.

OBSOLETE - Providing Android resources in Assets/Plugins/Android/res is deprecated, please move your resources to an AAR or an Android Library. See "AAR plug-ins and Android Libraries" section of the Manual for more details. UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&) (at /Users/bokken/buildslave/unity/build/Modules/IMGUI/GUIUtility.cs:189)

In Unity 2020.3.18f1 this feature isn't removed, I guess.

But as long as it's a warning, I ignored it. Despite of its appearance, I saw the notification with the icon when I added the "notification" payload to the message, i.e. like this - works:

curl --header "Authorization: key=$KEY" --header Content-Type:"application/json" -d \
"{ \
    \"to\": \"$DEVICE_TOKEN\", \
    \"notification\": \
    { \
        \"title\": \"Test Title\", \
        \"text\": \"Sample message\", \
    }, \
    \"data\": \
    { \
        \"title\":\"Test title\", \
        \"text\":\"TEST TEXT!\" \
    } \
}" $URL

[paulinon]

Hi @creatio-ua,

While I try to replicate the issue using Unity editor version 2020.3.18f1, could you confirm if you're facing a similar issue using our quickstart?

[creatio-ua]

Hi @paulinon

could you confirm if you're facing a similar issue using our quickstart?

I made my sample, using your quickstart project.

[paulinon]

Hi @creatio-ua,

I've used the quickstart, and I was able to receive the data message on my app in both killed and background states. I'd like to ask the method you're using to send these data messages. Were you able to get a '200' response from the server and is a message_id returned? Could you also share a sample message that you're trying to send?

[creatio-ua]

Hi @paulinon, That's just awesome! I would love to learn how you did that.

My sending method is (I'm on Mac OS 12.4):

DEVICE_TOKEN=<the token, obtained from a call to GetTokenAsync>
KEY=<Server key for my legacy server API>
URL=https://fcm.googleapis.com/fcm/send

curl --header "Authorization: key=$KEY" --header Content-Type:"application/json" -d \
"{ \
    \"to\": \"$DEVICE_TOKEN\", \
    \"data\": \
    { \
        \"title\":\"Test title\", \
        \"text\":\"TEST TEXT!\" \
    } \
}" $URL

The response for such call is:

{"multicast_id":2565469300720721421,"success":1,"failure":0,"canonical_ids":0,"results":[{"message_id":"0:1659531956902312%11b7a5a0f9fd7ecd"}]}%

I'm using Samsung S10 with Android 12 for my tests.

[AlmostMatt]

@creatio-ua Can you check on the device that you are testing if there are any settings preventing your app from sending or receiving background data? Some that I know of are: Settings > Network > Data Usage > Data Saver and for a specific app you can long-press to get app info > Mobile Data & Wi-FI > Background Data

[creatio-ua]

Hi @AlmostMatt, I tried to find something on the device, but with no luck. https://drive.google.com/file/d/1LU4zy9vfq0jjWSGfPvguBTQ2bVV5PRYX/view?usp=sharing https://drive.google.com/file/d/1NFAbKPwZfxuVDX-Xa-Qjzxsbl7oEB3hl/view?usp=sharing

At the same time:

• This device constantly gets email and weather notifications.
• If I add the "notification" payload to the message, like mentioned above - it works in backgrounded mode just fine.
• The OnMessageReceived triggers, when the app is in the foreground

So it looks unlikely that the problem is in the device. At least all my attempts to find something wrong about it gave nothing.

[creatio-ua]

Hi @paulinon, Would you mind sending the test sample that works for you?

[paulinon]

Hi @creatio-ua,

I used the quickstart sample to build the app and the OAuth 2.0 Playground to send a data message (such as this). Could you check if this method makes the data message appear in both killed and background states?

[google-oss-bot]

Hey @creatio-ua. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[creatio-ua]

Hi @paulinon,

Sorry I had to temporarily switch to another task. So I tried the service you suggested and reproduced the same behavior. Here are the details.

POST /fcm/send HTTP/1.1 Host: fcm.googleapis.com Content-length: 270 Content-type: application/json Authorization: Bearer AAAA59x4zRY:APA91bEr1HCa2z2W2g_IRvkUqKVsn_ZrJiqQCBxCiNUodOM8S9pJaPwdsGCpernwlOxgTgeFu0J1iyhIZtRZNa0Gmzv-E7urY8AhtmosV0-qD_dC7Tc7hpiDxY89yToGb6Mkt59SV6Sk { "to": "ckT_xd16Q0--92qK9jnHGz:APA91bFNpkd5KwGgGVo7HHcY_RfNkE_WxZVsp9xpmV4OoGt9V_awEw5s8I2Hv8obbHErBxoyrxbh2umkcBM3RM-4MnAzVEByCCOOrnQCjrljfl_5OnsI1gyVjwUiqDj5E-IkdeVyvmO6",
"data": { "title":"Test title", "text":"TEST TEXT!" } } HTTP/1.1 200 OK Content-length: 143 X-xss-protection: 1; mode=block Content-security-policy: frame-ancestors 'self' X-content-type-options: nosniff Transfer-encoding: chunked Expires: Wed, 17 Aug 2022 20:37:08 GMT Server: GSE -content-encoding: gzip Cache-control: private, max-age=0 Date: Wed, 17 Aug 2022 20:37:08 GMT X-frame-options: SAMEORIGIN Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43" Content-type: application/json; charset=UTF-8 { "failure": 0, "canonical_ids": 0, "success": 1, "multicast_id": 8526490262917412526, "results": [ { "message_id": "0:1660768628719477%11b7a5a0f9fd7ecd" } ] }

Probably I'm doing some very obvious mistake. And as long as the request is ok - then it probably is related to the Unity project. But I don't have any clues on how to narrow down the problem any further. I multiple-checked everything, but ... here I am :)

As a crazy idea: could it be related to my use of the legacy server protocol: Cloud Messaging API (Legacy)?

[paulinon]

Hi @creatio-ua,

It appears that you've received a "success" response from FCM (HTTP/1.1 200 OK). However, this doesn't mean that the message was delivered successfully to the device. Rather, it means that this message was successfully accepted for delivery. Low delivery rates are usually caused by something going wrong on the client device:

• User's device is turned off, offline, or unable to connect to FCM.
• App crashes when it receives the notification. Crash reporting SDKs are the biggest help for detecting this.
• Platform-specific battery saving features can prevent your app from waking up.

In addition, FCM configuration can affect deliverability:

• The chosen priority and lifespan can affect whether or not your notification is shown, even if it is delivered to the device.
• Collapsible messages may be replaced by a new message if they have yet to be delivered to the device. Please learn more here.

Do any of these apply to your implementation or device? Does the issue persist regardless of device? Also, version 9.4.0 of the SDK has been released. Could you confirm if this version makes any difference?

[creatio-ua]

Hi @paulinon, In my case:

1. The device is obviously turned on, and it can connect to FCM, because it can receive the message when the app is on the foreground.
2. I would probably see that in the logs, but there's just nothing. Even more - when the app returns from the background state to the foreground - the message appears.
3. Hard to say anything about the battery, I'll try to dive deeper in this topic.
4. I tried to send the notification with and without specifying the priority and lifespan, with no noticeable changes.
5. I checked the collapsible messages, but with no noticeable changes also.
6. Following your advice, I installed the version 9.4.0, but had no improvement also.

In the Android part of the documentation, I found a slightly unexpected table:

App state	Notification	Data	Both
Foreground	onMessageReceived	onMessageReceived	onMessageReceived
Background	System tray	onMessageReceived	Notification: system trayData: in extras of the intent.

So does it mean, that the data messages shouldn't be shown in the tray at all? Only onMessageReceived in fore/background states?

[paulinon]

Hi @creatio-ua,

When you mentioned that "the app returns from the background state to the foreground - the message appears", this is what I originally meant when I said that I was able to receive the message in both killed and background states. Apologies for the miscommunication.

To answer your question, yes; data messages aren't expected to be seen in the system tray unless the message contains a notification payload. The way the FCM service handles these messages depends on the type of message.

I'll be closing this for now. Let me know if an issue arises or if you have any other related questions.