User kill app, notification not remove

[expmaestro]

Hi i use this plugin in Android app now. When user or OS kill app notification does not disappear. Please help to solve this.

[lcaresia]

Some update?

[NorthFred]

This is valid at least on Android 10+.

When there is music playing by the Ionic app, the Music Controller won't be closed when killing the app. However, when you PAUSE the music first (actually when issuing an updateIsPlaying(false) and then kill the app, the Controller is destroyed.

Also when issuing the destroy() command from the code, while the isPlaying setting is true, the Music Controller does not get dismissed. It works however, when first explicitly setting updateIsPlaying(false)...

When a .destroy() is called, it shouldn't matter if isPlaying == true...

[kpwa]

Faced this problem as well, i had to write a custom service to remove the persisting notification after app kill.

[gondp]

Faced this problem as well, i had to write a custom service to remove the persisting notification after app kill.

@kpwa You can indicate more about this. Thanks

[srividya-sharma]

Faced this problem as well, i had to write a custom service to remove the persisting notification after app kill. I am facing the same problem. I want to destroy the Music Controls when app is force closed when music is still playing. @gondp @kpwa Can you please explain how to write custom service to achieve this? Thank you.

[ddurham2]

I'm not clear on the description of this problem... but I'll add some things I've observed.

On my Android 12 (S21) device, and on the simulator, notifications are not visible in the notification pull down after I swipe away the app. So maybe the original problem as reported is fixed by Android itself, though, it probably also depends on the UI flavor in use.

However, notifications do build up under App Info -> Notifications -> Notification Categories in that a new one is created each time I kill the app while the notification is active. I've tracked this back to the random UUID assigned to the CHANNEL_ID in MusicControlsNotification.java. If I assign a static value to this variable instead, then they stop multipling.

I've seen at least one other fork make a similar change.

It appears that @ghenry22 changed it to the random UUID back in this change, which appears to fix an issue where multiple app don't intend to share the same CHANNEL_ID. But the effect of creating new ones each time a notification is shown is a potential build up of notifications internally. I would suggest letting the user pass in their own CHANNEL_ID (or if convenient, make one up one time, and store in app data)

But, after I removed the random channel id here, I'm finding that each time my app updates the notifications (e.g. starts a new track) it is only reflecting the next-to-last title/image that I gave it. The NotificationManager.notify() docs say that it will update an existing notification, but it's clearly not doing that consistently. Logging shows that I am in deed building a new notification with the expected information, but it's not showing after calling notify(). But that older information will show up the next time it calls notify() with new information.

-- Update -- I believe I have tracked the issue with the notification down to the use of the Notification.MediaStyle() and it's connection to a MediaSession. If I comment out the use of MediaStyle(), the data supplied to the builder is used correctly every time. Leaving the MediaStyle() in play, I found that it's the use of the ThreadPool in MusicControls.java' handling of the "create" command. Since I'm using a URL for the artwork, I believe there's a race between 'create' and 'updateIsPlaying' which is immediately invoked just afterward. I think it's commiting to the use of presently obtained information and the thread bool later completes its fetching the artwork, but it's not reflected in the notification at that time for some reason. I found that if I call notification.updateIsPlaying(infos.isPlaying); towards the end of the run() function in the 'create' handler, then things work perfectly. It looks like updating the MediaSession's information doesn't necessarily update the notification, and that the notification will use the MediaSession's information over the notification's information the next time around. yuck

[Topiya]

@kpwa Can you give me a sample custom service to remove the notification after app kill?

Any one else found any solution to this?