fix: send high priority fcm messages#85
Conversation
|
This looks reasonable, but the documentation also says this at https://firebase.google.com/docs/cloud-messaging/android-message-priority#deprioritize:
Not every notification results in user visible message, e.g. for read receipts or duplicate messages (arriving in case of using multiple relays) nothing is shown. So it looks like Android may still detect this and then convert high priority into normal priority. On the other hand, if this works at least sometimes in your testing, it is an improvement. |
|
To me it seems to work in principle, so setting high-prio seems to improve reliability. What I did:
Only after the high-prio fcm message is sent, a notification comes through. (see log: I can see in the logs that DeltaChat continuously tries to fetch messages but fails due to network timeout (this happens even if no notification is received at all). Then, when the high-prio FCM allows for a wakeup, it still takes some seconds to recover from this fail-cycle until the fetch succeeds. But sometimes it never succeds and no notification is generated, even after high-prio fcm message. I suspect that receiving the high-prio message opens a time window where foreground activity is allowed, when we fail to fetch messages in that windows the notification is missed. Here is the logcat from the point in time where the high-prio fcm message is received: I tested with "Force background connection" off (when it's on, notifications arrived even with I also tried to trigger the conversion to "normal priority" by posting to Tested with FP3 on Android 13 and FP5 on Android 15. |
Documentation says "FCM uses 7 days of message behavior when determining whether to deprioritize or proxy messages; it makes this determination independently for every instance of your application. If, in response to high priority messages, notifications are displayed in a way that is visible to the user, then your future high-priority messages won't be affected.", so if this is correct, it will not happen immediately, but after 7 days of such usage. |
|
thanks a lot for looking closely, this is a minefield, probably. i checked our source code - and we show smth user-visible in all cases it seems: https://github.com/deltachat/deltachat-android/blob/main/src/gplay/java/org/thoughtcrime/securesms/notifications/FcmReceiveService.java#L90 - for "priority high" we open FetchForegroundService which will display a notification during fetching at least. maybe that is sufficient i wanted to check what signal is doing there but got lost somehow. that would indeed be interesting what others are doing in these cases, it is not only us who have to deal with eg. muted chats that are known to the client only |
There was a problem hiding this comment.
I think we can deploy it in any case, even if FCM later deprioritizes it to normal it's not worse than before.
On deltachat-android side we maybe need to always ask for "disable battery optimization" even on non-chatmail and when FCM is available since we currently have no way to distinguish between low and high priority.
Or we will need to expose whether the message is high priority unencrypted to distinguish actual messages from read receipts. And even then, there are duplicates, so we will need to increase debouncing interval, otherwise if messages do not arrive exactly at the same time we are still notifying duplicates with high priority and they will not create notifications. EDIT: I wrote this before message from @r10 above, displaying "Downloading messages..." and then removing it likely should indeed be good enough.
To make it work also in this case, it might make sense to stop and restart io in |
Probably better open an issue in https://github.com/deltachat/deltachat-android first, it's indeed a bug that we call maybe_network when the network is blocked. Restarting I/O should not be needed as it closes all the connections and opens them, but maybe_network is better called only when the network is known to be unblocked. @p1gp1g (author of deltachat/deltachat-android#4251, #53) also previously pointed me to https://codeberg.org/UnifiedPush/android-distributor/src/commit/966808bb164536a87be8cd4de7f1cbd2008a5236/distributor/src/main/java/org/unifiedpush/android/distributor/callback/NetworkCallback.kt, there is additional logic to keep track of VPN status and it is debugged already, maybe makes sense to use it as a reference. |
|
Regarding deprioritization: as the Google Play Services are opaque, we don't know when the application may be deprioritized. Especially:
In my opinion, it would be great to either, or both:
As deprioritized notifs set the priority to normal, which is the current priority, this PR seems reasonable to me. |
4 participants
I noticed that gplay push notifications are not reliable when the device has been locked for some minutes. My suspicion is this happens because of "Doze". I tried to reproduce the issue with a fairphone 3 by setting force-idle, which makes notifications stop working.
As far as I understand the docs about fcm data messages the default priority is "normal" and thus does not wake up the device from "Doze", so I created this PR.
I would need help testing this to check if it has the desired effect.