Foreground Service behaviour in Android 13 and 14

[ainnotate]

Hi, Thanks for the wonderful package.

Foreground service behaves little different in Android 14. Post registering the service, I'm using asForegroundService: true as shown below to attach the notification to the foreground service.

      await notifee.displayNotification({
        id: notification_id,
        title: notificationTitle,
        body: notificationBody,
        android: {
          channelId,
          asForegroundService: true,
          // pressAction is needed if you want the notification to open the app when pressed
          pressAction: {
            id: 'default',
          },
        },
      });

All good until Android 13.

In Android 14, I see the below behaviour,

1. Users are able to swipe out the notification from the notification drawer
2. The foreground service runs only when the application is running in the foreground. When we go to home screen, the foreground service is paused and starts again when the applcation is opened again.

I see that, Android 14 onwards, there is a behavioral change in the way foreground service is used.

Applications must specify the service type in startForeground() function.

Question: Is this support (for Android 14) planned any time soon?

Thank you.

[gtom84]

It doesn't seem to be related to startForeground in Android 14 as docs already tell you to provide Service with Type

<manifest>
    ...
    <!-- For example, with one service type -->
    <service android:name="app.notifee.core.ForegroundService" android:foregroundServiceType="location" />

     <!-- Or, with multiple service types -->
    <service android:name="app.notifee.core.ForegroundService" android:foregroundServiceType="location|camera|microphone" />
</manifest>

However ability to dismiss Foreground service also affects "ongoing" notifications which doesn't require foreground service registration.

notifee.displayNotification({
  body: 'Ongoing notification',
  android: {
    ongoing: true,
  },
});

[brimby]

Yes, I have noticed all of these scenarios. Namely 1) foregrounded notifications can be swiped away, 2) foreground processes pause when app is backgrounded, and 3) "ongoing" messages are also able to be swiped away.

Does anyone know if it's still possible that an update to Notifee can achieve the old behavior for foreground service and ongoing messages, or have changes in Android made it impossible?

Edit: oh I see. Android requires the type to be set now https://developer.android.com/about/versions/14/changes/fgs-types-required#google-play-enforcement . Guess I'll add some type to the manifest and see if anything changes.

[gtom84]

This is related to

User can dismiss notification by default

Starting in Android 13 (API level 33), users can dismiss the notification associated with a foreground service by default. To do so, users perform a swipe gesture on the notification. Traditionally, the notification isn't dismissed unless the foreground service is either stopped or removed from the foreground.

If you want the notification non-dismissable by the user, pass true into the setOngoing() method when you create your notification using Notification.Builder.

[brimby]

@gtom84 You're describing native code methods, but is it possible to achieve this with Notifee configurations? I think I already had android: {ongoing: true} previously, but I'll try it again to make sure. However, the setOngoing() documentation you linked to says:

Ongoing notifications cannot be dismissed by the user on locked devices, or by notification listeners, and some notifications (call, device management, media) cannot be dismissed on unlocked devices, so your application or service must take care of canceling them.

So it seems like the only notifications not dismissible by users on an unlocked screen are call, device management, and media.

[ainnotate]

@brimby, @gtom84 Thanks for your inputs.

I'm using notifee for dataSync and I'm using Foreground Service (asForegroundService: true) for this purpose. Here is my observation on different android versions

Android 12 and older:

• Notification is not dismissable by user
• Foreground service doesn't stop when app is in background (minimized)

• Foreground service doesn't stop whenthe app is killed

  Result: All works expected. This is my expected behaviour.

Android 13

• Notification is not dismissable by user
• Foreground service stops when app is in background (minimized)
• Foreground service continues when app is opened from tray
• When app is in background/minimized, Foreground service never starts when the app is killed directly from tray (without opening)
• Foreground service doesn't stop whenthe app is killed

Android 14

• Notification is always dismissable by user. This is the design of Android 14 Foreground service
• Foreground service stops when app is in background (minimized)
• Foreground service continues when app is opened from tray
• When app is in background/minimized, Foreground service never starts when the app is killed directly from tray (without opening)
• Foreground service doesn't stop when the app is killed

To me, the foreground service not running when app is in background or minimized is of concern.

This issue (of foreground service being stopped when app is minimized) is raised at #940 and a workaround is also suggested. However, the workaround suggested isn't straightforward from my usecase (local notification)

Any pointer would help.

[gtom84]

Hi @ainnotate

thanks for the summary, one note "Notification is always dismissable by user. This is the design of Android 14 Foreground service" is not my understanding of what they say in Ongoing flag which to my understanding is there on Android 14 specifically to make a FG service non dismissible.

`User can dismiss notification by default

Starting in Android 13 (API level 33), users can dismiss the notification associated with a foreground service by default. To do so, users perform a swipe gesture on the notification. Traditionally, the notification isn't dismissed unless the foreground service is either stopped or removed from the foreground.

If you want the notification non-dismissable by the user, pass true into the setOngoing() method when you create your notification using Notification.Builder.`

-- https://developer.android.com/develop/background-work/services/foreground-services#user-dismiss-notification

[ainnotate]

Hi @gtom84

If you want the notification non-dismissable by the user, pass true into the setOngoing() method when you create your notification using Notification.Builder.`

-- https://developer.android.com/develop/background-work/services/foreground-services#user-dismiss-notification

This is the behaviour of Android 13. The behaviour has again changed in Android 14.

[github-actions[bot]]

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.

[ninjz]

This is still an issue.

[shahbaz422]

I have a video calling app, I was using the foreground service to show video call information like duration and callee name, but from Android 14, users can dismiss the foreground service by swiping it, This is impacting my use cases, Is there a way by which users can't swipe foreground service notification just like android 13.

[keshavoh]

Facing the same issue as well, have a similar usecase but is there a workaround for atleast the service not being killed as i have some data to be synced in the background. Persistent notification is not a major concern, the operation however is.

[abdoutech19]

This is still an issue app crashes on Android 14

[github-actions[bot]]

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.