Open ashwin-phadke opened 4 years ago
andyholmes
commented
4 years ago All your logs show is that Android keeps sending the notifications, so there's not much that GSConnect can do about that. Unless the notification ID changes, repeats are muted and your logs don't include the notifications so it's hard to tell if that's what's happening.
ashwin-phadke
commented
4 years ago Well there was actually too much info in the notifications hence I've excluded those. I could anonymize them and add for info if you'd want so.
What I understand from the comment is that Android is sending the notifications again after it receives a new notifications is that so?
That's strange from Android's perspective though, because then in that situation the notifications should also reappear on the phone I suppose.
Any changes that I can do on the phone's side to solve the issue?
ashwin-phadke
commented
4 years ago To add to the issue : there's also one more behavior I've noticed after I allowed permissions for SMS is that some random messages from phone appear as unread on the GSConnect side. I rechecked to see whether I actually did not read the message on the phone but it was not so as the message was already read and it also shows random messages from very long ago as unread.
ferdnyc
commented
4 years ago What I understand from the comment is that Android is sending the notifications again after it receives a new notifications is that so?
That's strange from Android's perspective though, because then in that situation the notifications should also reappear on the phone I suppose.
Well, not exactly — it's not Android's perspective, per se, but really the KDE Connect app's. It may be sending through what appears to be a new notification, because (for instance) it was updated on the device side by the app that created it.
As @andyholmes said, Android notifications are a complex beast, and apps actually have a lot of control over how they manage their notifications. (More than ever, now that notifications can have response actions associated with them.) They can do things like rewrite existing notifications, removing a previous notification and putting up an updated one in its place. To KDE Connect, that may just look like a new notification — there's really no established API for letting other apps know exactly how to display a particular notification.
The SMS issue is similar. GSConnect tries to interpret the content of the SMS list as best it can, in order to follow conversations and match messages to contacts. But there's too little data available in the information it's able to access, and what's there is too unstructured, for its interpretation to always be 100% accurate.
ferdnyc
commented
4 years ago As @andyholmes said,
(Oh, my mistake. He didn't say that here, it was over in https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/788#issuecomment-599423904.)
ashwin-phadke
commented
4 years ago @ferdnyc thank you for the description. I guess then there is nothing much to do in this case then. I'll see if the situation changes later in the Android updates.
As you rightly mentioned android notifications is indeed a complex element overall.
Thank you for your help.
andyholmes
commented
4 years ago Well there was actually too much info in the notifications hence I've excluded those. I could anonymize them and add for info if you'd want so.
We don't really need the content of the notifications, but knowing whether the ID, body and title change will help determine if that's why this is happening.
That's strange from Android's perspective though, because then in that situation the notifications should also reappear on the phone I suppose.
The Android app can query what notifications are in the message tray, so each time you connect it will send a list of all the current notifications. Usually the IDs don't change, but they will in some circumstances like if you reboot your phone.
I rechecked to see whether I actually did not read the message on the phone but it was not so as the message was already read and it also shows random messages from very long ago as unread.
There is no way to change the written status of a message in the database, from kdeconnect-android or GSConnect, so that has to happen on your phone. Unfortunately, that makes it hard to change the "read" status of messages in the window, without making them full GObjects and thus using up a lot more memory.
ashwin-phadke
commented
4 years ago Well there was actually too much info in the notifications hence I've excluded those. I could anonymize them and add for info if you'd want so.
We don't really need the content of the notifications, but knowing whether the ID, body and title change will help determine if that's why this is happening.
I tried to recreate the scenario by sending notifications. Found out that, the notifications do appear multiple times and the id's were found out to be different
That's strange from Android's perspective though, because then in that situation the notifications should also reappear on the phone I suppose.
I tried recreating the scenario and before I could generate logs the notifications were delivered as I do not have access to app from application menu and have to open it from software everytime. I will update whenever I will be able to create a log. As for the notifications in log I was able to create all the id's were different.
UPDATE : Tried to recreate the scenario using a public chat group.
[1]
Mar 23 20:26:12 org.gnome.Shell.Extensions.GSConnect[1966]: [/service/protocol/core.js:receive/<:298]: Galaxy M10: {
"id": 1584975371885,
"type": "kdeconnect.notification",
"body": {
"payloadHash": "31b034e0634ccc8b0532fd84b9f4d787",
"actions": [
"Mark as read"
],
"id": "0|org.telegram.messenger",
"onlyOnce": false,
"isClearable": true,
"appName": "Telegram",
"time": "1584975371770",
"ticker": "ML Jobs: https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/",
"title": "ML Jobs",
"text": "https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/\n"
},
"payloadSize": 3066,
"payloadTransferInfo": {
"port": 1740
}
}
[2]
}
Mar 23 20:27:32 org.gnome.Shell.Extensions.GSConnect[1966]: [/service/protocol/core.js:receive/<:298]: Galaxy M10: {
"id": 1584975372191,
"type": "kdeconnect.notification",
"body": {
"actions": [
"Mark as read"
],
"id": "0|org.telegram.messenger",
"onlyOnce": false,
"isClearable": true,
"appName": "Telegram",
"time": "1584975372051",
"ticker": "ML Jobs: https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/",
"title": "ML Jobs",
"text": "https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/\n"
}
}
[3]
Mar 23 20:27:42 org.gnome.Shell.Extensions.GSConnect[1966]: [/service/protocol/core.js:receive/<:298]: Galaxy M10: {
"id": 1584975381656,
"type": "kdeconnect.notification",
"body": {
"actions": [
"Mark as read"
],
"id": "0|org.telegram.messenger|",
"onlyOnce": false,
"isClearable": true,
"appName": "Telegram",
"time": "1584975381504",
"ticker": "ML Jobs: https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/",
"title": "ML Jobs",
"text": "https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/\n"
}
}
[4]
Mar 23 20:27:42 org.gnome.Shell.Extensions.GSConnect[1966]: [/service/protocol/core.js:receive/<:298]: Galaxy M10: {
"id": 1584975391455,
"type": "kdeconnect.notification",
"body": {
"payloadHash": "31b034e0634ccc8b0532fd84b9f4d787",
"actions": [
"Mark as read"
],
"id": "0|org.telegram.messenger|",
"onlyOnce": false,
"isClearable": true,
"appName": "Telegram",
"time": "1584975388584",
"ticker": "ML Jobs: https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/",
"title": "ML Jobs",
"text": "https://www.facebook.com/groups/AnalyticsEdge/permalink/2603236166558006/\n"
},
"payloadSize": 3066,
"payloadTransferInfo": {
"port": 1740
}
}
The Android app can query what notifications are in the message tray, so each time you connect it will send a list of all the current notifications. Usually the IDs don't change, but they will in some circumstances like if you reboot your phone.
Oh.
I rechecked to see whether I actually did not read the message on the phone but it was not so as the message was already read and it also shows random messages from very long ago as unread.
There is no way to change the written status of a message in the database, from kdeconnect-android or GSConnect, so that has to happen on your phone. Unfortunately, that makes it hard to change the "read" status of messages in the window, without making them full GObjects and thus using up a lot more memory. Thanks @andyholmes urge you to let me know if personally identifying information is slipped from me in the log.
andyholmes
commented
4 years ago @andyholmes urge you to let me know if personally identifying information is slipped from me in the log.
Nope, it looks all good :)
Do any of the original notifications carry a field called requestReplyId? If so, then I may see what's been happening here.
andyholmes
commented
4 years ago Nevermind, I was mistaken. We already account for changing requestReplyId's.
Are you sure you don't have any other extensions installed that modify notifications?
ferdnyc
commented
4 years ago "onlyOnce": false,Well, it's not lying!
ashwin-phadke
commented
4 years ago Nevermind, I was mistaken. We already account for changing
requestReplyId's.Are you sure you don't have any other extensions installed that modify notifications?
I had initially installed kdeconnect but that did not work for me and removed it when I found GSConnect as a shell extension, although I tried installing GSconnect earlier using the git repo too, I don't think that's still there though. So as far as multiple apps are concerned I don't think it's that, apart from that, there are no other extensions that could change the notifications. I also encounter this exact same issue using KDEConnect too(FYI).
andyholmes
commented
4 years ago I'm not sure I see why this is happening, so there's not much I can do until I can find a way to reproduce it.
I'll mark this help wanted and leave it open, until there's some more information or further progress.
ferdnyc
commented
4 years ago Are you sure you don't have any other extensions installed that modify notifications?
I also encounter this exact same issue using KDEConnect too(FYI).
How about apps installed on your phone that might alter notifications? If the same thing was happening with both the kdeconnect desktop client and GSConnect, it kind of has to be a phone-side problem. It sounds like your phone is exhibiting atypical behaviors for some reason.
Do you have any sort of notification-management or enhancing app installed on the device? Is it possible your carrier/vendor preinstalled some software that would insert itself into the notification-handling process, something that might be throwing KDEConnect Android off its game?
ferdnyc
commented
4 years ago Since it's a Galaxy device, you don't by any chance have the Android parts of Galaxy Flow installed, do you? (Flow is Samsung's own, Windows-only answer to KDEConnect / GSConnect / Apple Continuity, and it would definitely have system-level permission to manage notifications on the phone.)
ashwin-phadke
commented
4 years ago Are you sure you don't have any other extensions installed that modify notifications?
I also encounter this exact same issue using KDEConnect too(FYI).
How about apps installed on your phone that might alter notifications? If the same thing was happening with both the
kdeconnectdesktop client and GSConnect, it kind of has to be a phone-side problem. It sounds like your phone is exhibiting atypical behaviors for some reason.Yes although it does appear on both the platforms but there is a slight difference to it, on windows the notifications do not reappear that often like Linux. I am currently trying one more method to clear the notifications from notification panel on Fedora and check if the notifications reappear then.
UPDATE : Yes some notifications did reappear even after cleaning from notification tray in Fedora.
Do you have any sort of notification-management or enhancing app installed on the device? Is it possible your carrier/vendor preinstalled some software that would insert itself into the notification-handling process, something that might be throwing KDEConnect Android off its game?
I have no other app installed that could potentially just manage notifications and change the behaviour for it.
Since it's a Galaxy device, you don't by any chance have the Android parts of Galaxy Flow installed, do you? (Flow is Samsung's own, Windows-only answer to KDEConnect / GSConnect / Apple Continuity, and it would definitely have system-level permission to manage notifications on the phone.)
I did not even know about that app until I read it here tbh.
andyholmes
commented
4 years ago UPDATE : Yes some notifications did reappear even after cleaning from notification tray in Fedora.
Unless your device is connected when you close the notifcation, GSConnect can't tell your device to close the notification. In other words, if you close a notification when the device is disconnected you will definitely get that notification when the device reconnects.
Are these the types of repeats you're talking about?
ashwin-phadke
commented
4 years ago UPDATE : Yes some notifications did reappear even after cleaning from notification tray in Fedora.
Unless your device is connected when you close the notifcation, GSConnect can't tell your device to close the notification. In other words, if you close a notification when the device is disconnected you will definitely get that notification when the device reconnects.
Are these the types of repeats you're talking about?
No not these type of notification repeats. I was just trying to use all types of methods at my disposal to figure out what might be causing the issue.
gaussandhisgun
commented
11 months ago i am utterly deranged, its 2am and i've found the most likely cause and a probable fix for this.
if you disable the Enhanced Notifications thing, which was added in android 12 and is usually on the very bottom of Settings → Notifications, you can (albeit, from the second try) dismiss the notification on GSConnect side in a way it gets dismissed on android side as well. android 13, redmi note 9s.
all of this time, ANDROID SYSTEM INTELLIGENCE was the "notification-management or enhancing app installed on the device". tho idk what was happening back in 2020, but i would assume samsung had some sort of knox crap bundled in for the same stuff.
well, now we have a thing to report to their bugzilla
gaussandhisgun
commented
11 months ago update: this worked for some notifications, but not for the others. huh
femans
commented
7 months ago Has there been any progress with this? I see it is an old ticket. I just installed this app and I find that the messages keep coming back in Gnome. If I click "all clear", a few seconds later all messages come back. This makes a great plugin suddenly rather annoying. The first time they have nice pictograms, the second time and following times just an icon of a phone.
andyholmes
commented
7 months ago Any progress would listed here on the issue. If I recall, I could never reproduce this behaviour so not much to go on unfortunately.
Describe the bug
Very recently the notifications have started to continuously reappear mostly from the beginning after certain number of intervals or any new notification appears and then is followed by previous few notifications after that.
Email notifications are well delayed. They appear after a long time and even after you have opened them already on your phone .
Expected behavior
Only new notification shoudl show up once it arrives and also notifications shouldn't repeat after a certain time.
System Details (please complete the following information):
GSConnect environment (if applicable):
Support Log