Foreground service freezes when app dismissed

[jektvik]

Have tried about just about every config concievable to get the foreground service running but it just won't continue executing as soon as I dismiss the parent app to the background.

await notifee.registerForegroundService((notification: Notification) => {
    return new Promise(resolve => {
      const interval2 = setInterval(() => console.log('testmessage'), 6000);

      notifee.onBackgroundEvent(async event => {
        if (event.type === EventType.DISMISSED) {

          await notifee.cancelNotification(notification.id || '');
          console.log('Handled DISMISSED onBackgroundEvent');
        }

        return resolve();
      });

      notifee.onForegroundEvent(async event => {
        if (event.type === EventType.DISMISSED) {
          await notifee.cancelNotification(notification.id || '');
        }

        return resolve();
      });
    });
  });
```

The above 'test message' will continue displaying every 6 s as long as the app is on the foreground but as soon as I return to main screen that execution freezes (i.e. it's not properly attached to the foreground service). When I open the app again, it may unfreeze.
The testmessage code is meant to actually be a 'refreshNotification' type of function, but it never worked therefore I'm attaching this simplified example.

Android logs keep spamming
`08-08 10:55:06.711   583   818 W IPCThreadState: Sending oneway calls to frozen process.`

Which I think may be indicative of what the issue is, i.e. the setInterval function isn't properly attached to any process (foregroundProcess?) which is meant to stay alive when the app is in the background.

Similarly, functions like

  await notifee.stopForegroundService();
  await notifee.cancelAllNotifications();
  
  seem to have no effect, i.e. even after I call them, the interval messages will keep executing if they'd been started like above.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[jektvik]

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?
Defeinitely still alive

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[shubhamnandanwar]

I am facing the same issue.

[mikehardy]

I can reopen this but there is a very constrained amount of dev time I have - if anyone that is affected by this can dig in to troubleshoot it, that's the way to move this forward.

Note that this may be affected by new architecture being enabled or not - if you are on react-native 0.76+ with bridgeless enabled this package is mostly working but there are reports that the new architecture mode causes foreground-service freezing. That may be the same issue as originally logged here it may not, I am unsure. But testing with new architecture enabled vs disabled is a good first step at diagnosis. Beyond that, unsure.

[shubhamnandanwar]

Hey @mikehardy, I don't have access to Android 14 but a lot of users has reported this issue. My app has a timer feature that users a foreground service to resume/pause the timer. The feature works fine initially but after around 5 minutes closing the app, it freezes. Nothing works. I am not able to recreate it on Emulator. Do you know how it can be recreated? Also, is there a workaround to fix the freeze temporarily?

[mikehardy]

I wasn't even aware this is a problem as I don't use the module like this in any way - so I don't reproduce it either and I'm unaware of any workarounds. The only thing I know is that it may be related to new architecture. But it may not.

Someone who is impacted and motivated to troubleshoot will have to start instrumenting the code and finding reproduction scenarios and determine a root cause. Getting access to an Android 14 phone should be possible on the used market perhaps if a real device (not emulator) is required to reproduce.

Perhaps someone else impacted is able to reproduce this on the emulator, that would be useful to know if so.