[GH-ISSUE #385] Missing notifications: Android app doesn't start target app when receiving a notification? #296

New issue

Closed

opened 2026-05-07 00:22:43 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:22:43 +02:00

Owner

Originally created by @christophehenry on GitHub (Aug 20, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/385

So this is more of a question than a bug as Android's power management is still very obscure to me, in particular its behaviour between versions…

I've been using ntfy for Fedilab and Matrix for a few days now and correctly receive notifications… Most of the time. But every now and then, I start either Matrix or Fedilab and realise that some notifications have been lost in oblivion.

So I made a test and killed both these apps manually using the Force stop button and provoked a push notification to be distributed for both of them: no notification appeared in Android.

So my theory is: sometimes the target apps miss notifications because, being in the background for too long, the system reclaims their memory and kills them. Then ntfy seems unable to restart them. This is the behaviour that I think reproduced using the Force stop button.

Does this ring a bell? Has anyone else noticed this problem?

I'm on Lineage (microG for Lineage, specifically) 19.1 on OnePlus 5T.

Originally created by @christophehenry on GitHub (Aug 20, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/385 So this is more of a question than a bug as Android's power management is still very obscure to me, in particular its behaviour between versions… I've been using ntfy for Fedilab and Matrix for a few days now and correctly receive notifications… Most of the time. But every now and then, I start either Matrix or Fedilab and realise that some notifications have been lost in oblivion. So I made a test and killed both these apps manually using the *Force stop* button and provoked a push notification to be distributed for both of them: no notification appeared in Android. So my theory is: sometimes the target apps miss notifications because, being in the background for too long, the system reclaims their memory and kills them. Then ntfy seems unable to restart them. This is the behaviour that I think reproduced using the *Force stop* button. Does this ring a bell? Has anyone else noticed this problem? I'm on Lineage (microG for Lineage, specifically) 19.1 on OnePlus 5T.

BreizhHardware

2026-05-07 00:22:43 +02:00

closed this issue
added the
android-app

question
labels

BreizhHardware commented

2026-05-07 00:22:44 +02:00

Author

Owner

@binwiederhier commented on GitHub (Aug 21, 2022):

When you Force stop an app, it cannot do anything. It's dead. Force stopping is the only reliable way to actually kill an app and all of its background processes.
ntfy doesn't start anything. It forwards messages as Android intent broadcast. If there is no application running to receive them, Android discards the message. ntfy does not buffer or re-send the message. It is lost.

As long as you see the foreground notification (the notification that you cannot get rid of), ntfy should be running and receive/forward messages. Whether someone receives them is not up to ntfy. In fact, UnifiedPush doesn't even support/allow resending. There was talk about that, but it was never implemented. You may be able to keep your Matrix client alive by changing its power settings (like you did for ntfy), but that's not up to ntfy.

I hope that answered your questions.

@binwiederhier commented on GitHub (Aug 21, 2022): 1. When you _Force stop_ an app, it cannot do anything. It's dead. Force stopping is the only reliable way to actually kill an app and all of its background processes. 2. ntfy doesn't start anything. It forwards messages as Android intent broadcast. If there is no application running to receive them, Android discards the message. ntfy does not buffer or re-send the message. It is lost. As long as you see the foreground notification (the notification that you cannot get rid of), ntfy should be running and receive/forward messages. Whether someone receives them is not up to ntfy. In fact, UnifiedPush doesn't even support/allow resending. There was talk about that, but it was never implemented. You may be able to keep your Matrix client alive by changing its power settings (like you did for ntfy), but that's not up to ntfy. I hope that answered your questions.

BreizhHardware commented

2026-05-07 00:22:44 +02:00

Author

Owner

@christophehenry commented on GitHub (Aug 21, 2022):

I see. I suppose it corresponds to this code. I have had the occasion to play with BroadcastReceiver and sendBroadcast() yet so I'm mostly guessing here. But from what I'm reading, you're only using setAction for Android to determine which app should handle the Intent which leaves the system search through the BroadcastReceiver that are already registered.

Since you already know which app a notification is destined to, you could be using setPackage.

As a side note, distributing the Intent to every app could be a (tiny) security hole.

I'm gonna experiment that solution.

@christophehenry commented on GitHub (Aug 21, 2022): I see. I suppose it corresponds to [this code](https://github.com/binwiederhier/ntfy-android/blob/main/app/src/main/java/io/heckel/ntfy/msg/BroadcastService.kt#L20-L45). I have had the occasion to play with `BroadcastReceiver` and `sendBroadcast()` yet so I'm mostly guessing here. But from what I'm reading, you're only using [`setAction`](https://developer.android.com/reference/android/content/Intent#setAction(java.lang.String)) for Android to determine which app should handle the Intent which leaves the system search through the `BroadcastReceiver` that are already registered. Since you already know which app a notification is destined to, you could be using [`setPackage`](https://developer.android.com/reference/android/content/Intent#setPackage(java.lang.String)). As a side note, distributing the Intent to every app could be a (tiny) security hole. I'm gonna experiment that solution.

BreizhHardware commented

2026-05-07 00:22:44 +02:00

Author

Owner

@binwiederhier commented on GitHub (Aug 21, 2022):

The code you linked is not used for UnifiedPush. It's used in general to integrate with automation apps (https://ntfy.sh/docs/subscribe/phone/#react-to-incoming-messages). You can turn off forwarding (if you have security concerns) in the ntfy settings.

This is the code you'll want to look at for UnifiedPush: https://github.com/binwiederhier/ntfy-android/blob/main/app/src/main/java/io/heckel/ntfy/up/Distributor.kt -- As for what I do and do not set, that's in the UP spec and I cannot influence that.

@binwiederhier commented on GitHub (Aug 21, 2022): The code you linked is not used for UnifiedPush. It's used in general to integrate with automation apps (https://ntfy.sh/docs/subscribe/phone/#react-to-incoming-messages). You can turn off forwarding (if you have security concerns) in the ntfy settings. This is the code you'll want to look at for UnifiedPush: https://github.com/binwiederhier/ntfy-android/blob/main/app/src/main/java/io/heckel/ntfy/up/Distributor.kt -- As for what I do and do not set, that's in the UP spec and I cannot influence that.

BreizhHardware commented

2026-05-07 00:22:44 +02:00

Author

Owner

@christophehenry commented on GitHub (Aug 21, 2022):

You're right, unfortunately. I've spent the last few hours trying to find a way around but couldn't. There's no way to bring an app back to life except Context.startActivity(). Which is doable, but since there's no way that I am aware of to detect if an app is running or not, it's more or less a no go.

I opened UnifiedPush#31 to discuss a better way. I suppose this can be closed.

@christophehenry commented on GitHub (Aug 21, 2022): You're right, unfortunately. I've spent the last few hours trying to find a way around but couldn't. There's no way to bring an app back to life except `Context.startActivity()`. Which is doable, but since there's no way that I am aware of to detect if an app is running or not, it's more or less a no go. I opened [UnifiedPush#31](https://github.com/UnifiedPush/android-connector/issues/60) to discuss a better way. I suppose this can be closed.