[GH-ISSUE #1035] LineageOS delays notification, despite io.heckel.ntfy.MESSAGE_RECEIVED intent being sent #728

New issue

Open

opened 2026-05-07 00:26:57 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:26:57 +02:00

Owner

Originally created by @aerusso on GitHub (Feb 25, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1035

🐞 Describe the bug
Hello! I've been trying to dig into getting actually instant notifications, and right now the phone can take up to 180 seconds to make any indication that a message has been sent to it.

💻 Components impacted
This is up-to-date F-droid app, and up-to-date self-hosted server. This is a Moto x4 running up-to-date LineageOS. I originally thought those might have been implicated but the logs indicate otherwise:

💡 Screenshots and/or logs

1708824393065 2024-02-24 18:26:33.065 D NtfyWsConnection <REDACTED_SERVER>/<REDACTED_TOPIC>,upAV6Eas7B6tU6 (gid=8, lid=3): Received message: {"id":"eyrYLXZqciYf","time":1708824392,"expires":1708867592,"event":"message","topic":"wow","message":"hello"}

1708824393101 2024-02-24 18:26:33.101 D NtfySubscriberService [https://<REDACTED_SERVER>/<REDACTED_TOPIC>] Received notification: Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false)
1708824393135 2024-02-24 18:26:33.135 D NtfySubscriberService [https://<REDACTED_SERVER>/<REDACTED_TOPIC>] Dispatching notification Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false)
1708824393136 2024-02-24 18:26:33.136 D NtfyNotifDispatch Dispatching Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) for subscription Subscription(id=7402353, baseUrl=https://<REDACTED_SERVER>, topic=<REDACTED_TOPIC>, instant=true, mutedUntil=0, minPriority=0, autoDelete=-1, insistent=-1, lastNotificationId=gDtJmPpS6LtK, icon=null, upAppId=null, upConnectorToken=null, displayName=null, dedicatedChannels=false, totalCount=1, newCount=1, lastActive=1708824203, state=CONNECTED)
1708824393136 2024-02-24 18:26:33.136 D NtfyNotifService Displaying notification Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false)
1708824393155 2024-02-24 18:26:33.155 D NtfyBroadcastService Sending message intent broadcast: io.heckel.ntfy.MESSAGE_RECEIVED with extras Bundle[{base_url=https://<REDACTED_SERVER>, message_bytes=[104, 101, 108, 108, 111], message_encoding=, priority=3, tags_map=, attachment_name=, attachment_size=0, attachment_type=, attachment_expires=0, id=eyrYLXZqciYf, tags=, time=1708824392, click=, muted=false, title=, topic=<REDACTED_TOPIC>, attachment_url=, message=hello, muted_str=false}]

I sent this message around 18:26:31, so the message intent broadcast is made less than 2 seconds after the actual send (which, by the way, is awesome!)

However, the phone didn't make any sound for a good 40 seconds after this! This is entirely reproducible, as long as the phone is not plugged in (i.e. charging) and not hasn't been recently interacted with.

🔮 Additional context
Is there some other mechanism in Android that delays the wake-and-make-sound step? I'm not even sure where to start looking/what to search for on the web. Is this a Lineage bug?

Originally created by @aerusso on GitHub (Feb 25, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1035 :lady_beetle: **Describe the bug** Hello! I've been trying to dig into getting actually instant notifications, and right now the phone can take up to 180 seconds to make any indication that a message has been sent to it. :computer: **Components impacted** This is up-to-date F-droid app, and up-to-date self-hosted server. This is a Moto x4 running up-to-date LineageOS. I originally thought those might have been implicated but the logs indicate otherwise: :bulb: **Screenshots and/or logs** ``` 1708824393065 2024-02-24 18:26:33.065 D NtfyWsConnection <REDACTED_SERVER>/<REDACTED_TOPIC>,upAV6Eas7B6tU6 (gid=8, lid=3): Received message: {"id":"eyrYLXZqciYf","time":1708824392,"expires":1708867592,"event":"message","topic":"wow","message":"hello"} 1708824393101 2024-02-24 18:26:33.101 D NtfySubscriberService [https://<REDACTED_SERVER>/<REDACTED_TOPIC>] Received notification: Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) 1708824393135 2024-02-24 18:26:33.135 D NtfySubscriberService [https://<REDACTED_SERVER>/<REDACTED_TOPIC>] Dispatching notification Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) 1708824393136 2024-02-24 18:26:33.136 D NtfyNotifDispatch Dispatching Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) for subscription Subscription(id=7402353, baseUrl=https://<REDACTED_SERVER>, topic=<REDACTED_TOPIC>, instant=true, mutedUntil=0, minPriority=0, autoDelete=-1, insistent=-1, lastNotificationId=gDtJmPpS6LtK, icon=null, upAppId=null, upConnectorToken=null, displayName=null, dedicatedChannels=false, totalCount=1, newCount=1, lastActive=1708824203, state=CONNECTED) 1708824393136 2024-02-24 18:26:33.136 D NtfyNotifService Displaying notification Notification(id=eyrYLXZqciYf, subscriptionId=7402353, timestamp=1708824392, title=, message=hello, encoding=, notificationId=706226588, priority=3, tags=, click=, icon=null, actions=null, attachment=null, deleted=false) 1708824393155 2024-02-24 18:26:33.155 D NtfyBroadcastService Sending message intent broadcast: io.heckel.ntfy.MESSAGE_RECEIVED with extras Bundle[{base_url=https://<REDACTED_SERVER>, message_bytes=[104, 101, 108, 108, 111], message_encoding=, priority=3, tags_map=, attachment_name=, attachment_size=0, attachment_type=, attachment_expires=0, id=eyrYLXZqciYf, tags=, time=1708824392, click=, muted=false, title=, topic=<REDACTED_TOPIC>, attachment_url=, message=hello, muted_str=false}] ``` I sent this message around 18:26:31, so the message intent broadcast is made less than 2 seconds after the actual send (which, by the way, is awesome!) However, the phone didn't make any sound for a good 40 seconds after this! This is entirely reproducible, as long as the phone is not plugged in (i.e. charging) and not hasn't been recently interacted with. :crystal_ball: **Additional context** Is there some other mechanism in Android that delays the wake-and-make-sound step? I'm not even sure where to start looking/what to search for on the web. **Is this a Lineage bug?**

BreizhHardware added the

🪲 bug

label

2026-05-07 00:26:57 +02:00

BreizhHardware commented

2026-05-07 00:26:58 +02:00

Author

Owner

@aerusso commented on GitHub (Feb 25, 2024):

Ok, I'm trying to understand what is going on from the logs.

First of all, looking through the from-app captured log, i see a Sending message intent broadcast: line, but no corresponding Broadcast received: line (?!?).

Are those logs collated somewhere else? Where can I find those?

That said, from the Displaying notification Notification(...) log entry, it seems that NotificationService.display is getting called, but is it completing? And moreover, is the subsequent call to NotificationManager.notify (from within displayInternal) getting the wakelock handed off to it (or held for it? I don't know the convention here).

In short: I think that that UserActionManager is being tasked to handle two kinds of work: tasks that should be handled once the phone wakes up (like sending network responses) and also things that need to be handled immediately (like sending notification to the user, passing off unifiedpush messages to other phone apps).

Shouldn't those two kinds of tasks be handled separately? Both seem to be enqueued at the same time there?

@aerusso commented on GitHub (Feb 25, 2024): Ok, I'm trying to understand what is going on from the logs. First of all, looking through the from-app captured log, i see a `Sending message intent broadcast:` line, but no corresponding `Broadcast received:` line (?!?). **Are those logs collated somewhere else? Where can I find those?** That said, from the `Displaying notification Notification(...)` log entry, it seems that NotificationService.display is getting called, but is it completing? And moreover, is the subsequent call to NotificationManager.notify (from within displayInternal) getting the wakelock handed off to it (or held for it? I don't know the convention here). In short: I think that that `UserActionManager` is being tasked to handle two kinds of work: tasks that should be handled once the phone wakes up (like sending network responses) and also things that need to be handled immediately (like sending notification to the user, passing off unifiedpush messages to other phone apps). Shouldn't those two kinds of tasks be handled separately? Both seem to be enqueued at the same time there?

BreizhHardware commented

2026-05-07 00:26:58 +02:00

Author

Owner

@wunter8 commented on GitHub (Feb 25, 2024):

To address your first point (no corresponding broadcast received), I wouldn't expect ntfy to receive its own intent. I'm pretty sure (without digging into the code right now) that the message intent broadcast line corresponds to the setting in the Android app settings called "Broadcast Messages."

If you disable "Broadcast Messages", I would expect that line in the logs to go away. I believe the Broadcast Messages setting is only there for automation apps, like Tasker and MacroDroid, to react to received notifications. I'm pretty sure UnifiedPush continues to work (e.g., broadcast message intents to UP apps) in the background, even if that setting is disabled

@wunter8 commented on GitHub (Feb 25, 2024): To address your first point (no corresponding broadcast received), I wouldn't expect ntfy to receive its own intent. I'm pretty sure (without digging into the code right now) that the message intent broadcast line corresponds to the setting in the Android app settings called "Broadcast Messages." If you disable "Broadcast Messages", I would expect that line in the logs to go away. I believe the Broadcast Messages setting is only there for automation apps, like Tasker and MacroDroid, to react to received notifications. I'm pretty sure UnifiedPush continues to work (e.g., broadcast message intents to UP apps) in the background, even if that setting is disabled

BreizhHardware commented

2026-05-07 00:26:58 +02:00

Author

Owner

@aerusso commented on GitHub (Feb 26, 2024):

Doesn't BroadcastReceiver in BroadcastService.kt receive the SEND_MESSAGE intent? The comment there at least suggests it does. But thank you for pointing out another thing it should be doing, and also explaining why it shouldn't be showing up! Anyway, it doesn't really matter.

I am able to confirm that holding the wakelock for another few seconds causes the phone to respond to incoming messages nearly instantaneously. I've put this into a WIP patch.

@wunter8 I'd really appreciate your insight in that PR when you have time.

@aerusso commented on GitHub (Feb 26, 2024): Doesn't `BroadcastReceiver` in `BroadcastService.kt` receive the SEND_MESSAGE intent? The comment there at least suggests it does. But thank you for pointing out another thing it should be doing, and also explaining why it shouldn't be showing up! Anyway, it doesn't really matter. I am able to confirm that holding the wakelock for another few seconds causes the phone to respond to incoming messages nearly instantaneously. I've put this into a [WIP patch](https://github.com/binwiederhier/ntfy-android/pull/73). @wunter8 I'd really appreciate your insight in that PR when you have time.

BreizhHardware referenced this issue

2026-05-07 01:01:54 +02:00

[PR #728] [MERGED] set attachment filename when download through browser #1392