Notifications from the IFTTT app on android are not synced

[svjmtn]

ATTENTION: GSConnect only supports the latest, stable version of GNOME. We are no longer accepting bug reports for previous versions.

Describe the bug

Notifications from the IFTTT app on android are not displayed by GSConnect.

Steps To Reproduce:

1. Set up an activity on the IFTTT app that will push a notification to the phone

Expected behavior

Notifications from the IFTTT app are shown when they appear.

Screenshots

If applicable, add screenshots to help explain your problem. You can drag-and-drop or cut-and-paste images directly into this edit window, to include them in your report.

Support Log

Please generate a support log (Instructions) and paste any messages related to this issue between the two ``` lines below.

GSConnect Version: 39
GSConnect Install: user
GJS: 16403
XDG_SESSION_TYPE: wayland
GDMSESSION: gnome
--------------------------------------------------------------------------------
-- Logs begin at Tue 2020-03-10 08:30:19 IST, end at Fri 2020-07-24 20:14:48 IST. --
Jul 24 20:14:03 wpa_supplicant[958]: nl80211: send_and_recv->nl_recvmsgs failed: -33
Jul 24 20:14:44 org.gnome.Shell.Extensions.GSConnect[2307]: [/service/protocol/core.js:receive/<:298]: Redmi Note 5: {
                                                              "id": 1595601882370,
                                                              "type": "kdeconnect.notification",
                                                              "body": {
                                                                "id": "0|com.google.android.googlequicksearchbox|-1873494995|n|10050",
                                                                "isCancel": true
                                                              }
                                                            }
Jul 24 20:14:48 org.gnome.Shell.Extensions.GSConnect[2307]: [/service/protocol/core.js:receive/<:298]: Redmi Note 5: {
                                                              "id": 1595601887142,
                                                              "type": "kdeconnect.notification",
                                                              "body": {
                                                                "id": "0|com.google.android.gm|0|gig:1658138032:CLASSIC_INBOX_ALL_MAIL|10076",
                                                                "isCancel": true
                                                              }
                                                            }
Jul 24 20:14:48 org.gnome.Shell.Extensions.GSConnect[2307]: [/service/protocol/core.js:receive/<:298]: Redmi Note 5: {
                                                              "id": 1595601887143,
                                                              "type": "kdeconnect.notification",
                                                              "body": {
                                                                "id": "0|com.google.android.gm|1226657976|gig:1658138032:CLASSIC_INBOX_ALL_MAIL|10076",
                                                                "isCancel": true
                                                              }
                                                            }

System Details (please complete the following information):

• GSConnect version: 39
  • Installed from: GNOME Extensions Website
• GNOME/Shell version: 3.36.4
• Distro/Release: Fedora 31

GSConnect environment (if applicable):

• Paired Device(s): Redmi Note 5
• KDE Connect app version: 1.14.2
• Plugin(s): Notification sync

Additional Notes:

Other notifications from Whatsapp, GMail, Calendar, some other apps, SMS etc are being synced correctly.

[ferdnyc]

@enigma0160 Can I assume that you did something to cause an IFTTT notification to be generated while collecting logs, and the included output shows an example of an IFTTT notification not being received by GSConnect?

If the notifications aren't being sent by the KDE Connect app, there's really nothing GSConnect can do about that — we can only display what we receive. So, if anything it sounds like this is possibly an Android app bug.

I should mention, though, that the Android app's notification sync plugin has the ability to enable or disable notification relaying per app in its preferences. Have you checked there to make sure that mirroring for IFTTT notifications is enabled?

[svjmtn]

Yes, the log was taken while a notification was shown on the phone but not by GSConnect.

That may be possible. Any way I can get a log from the KDEConnect app to confirm?

Yes, I double-checked the per-app preference, sync is enabled for IFTTT.

[ferdnyc]

You'd have to debug the app using an ADB connection; you can find general info on using ADB in the Android Studio docs, and @andyholmes offered some info on debugging KDE Connect specifically in https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/581#issuecomment-527709134

[ferdnyc]

Before going through all of that, it might be worth it to just check the system logs on your phone with a log reader app, see if there's anything in there that might help track down the issue.

[ferdnyc]

(Also, though it's cliche: "Have you tried turning it off and on again?" Sometimes a reboot really can do the trick.)

[andyholmes]

Those packets are all the "notification closed" packets for notifications. Usually if you're getting just those, these notifications are considered system notifications that aren't forwarded: Play Store updates, things like that.

So as @ferdnyc says, this is Android not sending the notifications probably because the app is in some kind of "category" or type that KDE Connect doesn't send on purpose. Could also be a bug in kdeconnect-android though.

[ferdnyc]

Something else I thought of: I know IFTTT has a strong web-services component to it. Are the notifications you're looking for native Android app notifications, or are they HTTPS push notifications perhaps? Because, if the latter,

1. Possibly they'd register as coming from somewhere other than the IFTTT app itself (a browser app, for example).
2. KDE Connect might intentionally not forward those.

[svjmtn]

Before going through all of that, it might be worth it to just check the system logs on your phone with a log reader app, see if there's anything in there that might help track down the issue.

Thanks for the quick replies and sorry for the late reply. I'll try to see if there is anything suspicious in the logs.

(Also, though it's cliche: "Have you tried turning it off and on again?" Sometimes a reboot really can do the trick.)

Yep :smile:, but didn't work.

Something else I thought of: I know IFTTT has a strong web-services component to it. Are the notifications you're looking for native Android app notifications, or are they HTTPS push notifications perhaps? Because, if the latter,

1. Possibly they'd register as coming from somewhere other than the IFTTT app itself (a browser app, for example).
2. KDE Connect might intentionally not forward those.

Looks like a normal notification, in the sense that I can press and hold and get the notifications settings for IFTTT in Android Settings

[svjmtn]

I was checking the logs and triggering some notifications that usually are synced by GSConnect. But for some reason I am not getting any notifications synced to my desktop now. I don't know why. Notification preferences are enabled for all the apps. Previously I used to get notifications synced from Gmail and WhatsApp, but even those are not working now. Logs some suspicious things:

07-31 19:31:17.581 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 321, previously 323
07-31 19:31:17.581 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 128, previously 390
07-31 19:31:18.929 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:32:04.932 12040 12040 W NotificationReceiver: Notification listener service not yet bound.

07-31 19:31:15.970 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:31:15.984 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:31:15.992 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 316, previously 395
07-31 19:31:15.993 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 165, previously 633
07-31 19:31:15.999 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:31:16.016 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:31:16.020 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 182, previously 187
07-31 19:31:16.020 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 349, previously 357
07-31 19:31:16.020 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.021 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 1054, previously 1137
07-31 19:31:16.021 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 2469, previously 2470
07-31 19:31:16.021 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 1230, previously 1669
07-31 19:31:16.021 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 2497, previously 11465
07-31 19:31:16.021 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 149, previously 787
07-31 19:31:16.022 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 104, previously 105
07-31 19:31:16.022 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.023 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 154, previously 156
07-31 19:31:16.023 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 353, previously 355
07-31 19:31:16.023 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.024 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 181, previously 182
07-31 19:31:16.024 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.025 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 25, previously 26
07-31 19:31:16.025 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 186, previously 184
07-31 19:31:16.025 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.026 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 231, previously 229
07-31 19:31:16.026 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.026 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 30, previously 29
07-31 19:31:16.026 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.027 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 278, previously 311
07-31 19:31:16.027 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.028 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 62, previously 66
07-31 19:31:16.028 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.028 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 21, previously 29
07-31 19:31:16.028 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.029 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 155, previously 156
07-31 19:31:16.029 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.029 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 9, previously 15
07-31 19:31:16.029 12040 30366 W ResourceType: Found multiple library tables, ignoring...
07-31 19:31:16.030 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 148, previously 149
07-31 19:31:16.030 12040 30366 W ResourceType: ResTable_typeSpec entry count inconsistent: given 431, previously 429
07-31 19:31:16.030 12040 30366 W ResourceType: Found multiple library tables, ignoring...

[ferdnyc]

I suspect those ResTable_typeSpec log messages are harmless, they appear to be a normal consequence of running lookups in Android's resources system (the contents of which are constantly in flux), this Stack Overflow question about the same thing is unanswered, but shows the same thing caused by simple lookups which makes me think it's just business as usual.

Slightly greater cause for concern might be these two. Though even there it could be nothing, just transient failures caused by out-of-order operations. (It does say "not yet bound", after all).

07-31 19:31:18.929 12040 30366 W ResourceType: No package identifier when getting name for resource number 0x00000000
07-31 19:32:04.932 12040 12040 W NotificationReceiver: Notification listener service not yet bound.

If you're suddenly not getting ANY notifications sent to your desktop... well, if the GSConnect debug log doesn't show any messages being received, then something must have gotten messed up with KDE Connect. Standard Android troubleshooting, I'd say:

1. Check the in-app preferences to make sure they're still set right
2. Check the Android app settings to make sure it's allowed to operate as a service (background data enabled in Mobile data, background activity allowed in Battery, etc.)
3. Try clearing the app Cache
4. Try clearing the app Data (which I think will necessitate re-pairing, after)
5. Uninstall/reinstall

[ferdnyc]

I experimentally installed IFTTT on my (Android 9) phone, and just created some simple actions to display a notification every hour with the current time and date. (Actually I created two, since IFTTT has both regular notifications, and 'rich' notifications that can include a link and/or photo.)

I can confirm that neither type gets relayed to my desktop, whereas the similar test alert I set up in the Samsung Reminders app was.

[svjmtn]

I experimentally installed IFTTT on my (Android 9) phone, and just created some simple actions to display a notification every hour with the current time and date. (Actually I created two, since IFTTT has both regular notifications, and 'rich' notifications that can include a link and/or photo.)

I can confirm that neither type gets relayed to my desktop, whereas the similar test alert I set up in the Samsung Reminders app was.

Thanks @ferdnyc ! Clearing App data seems to fix some issues. I am getting notifications synced as usual, but the IFTTT app is still not syncing.

[ferdnyc]

@enigma0160

Yeah, @andyholmes is pursuing the IFTTT issue with the KDE Connect developers. It seems like there's some issue with mirroring notifications from certain apps, as it may be affecting at least the M$ Outlook app as well. (#902).

[ferdnyc]

@enigma0160

Yeah, @andyholmes is pursuing the IFTTT issue with the KDE Connect developers. It seems like there's some issue with mirroring notifications from certain apps, as it may be affecting at least the M$ Outlook app as well. (#902).

Scratch that, I should've said: he recommends that you pursue it with the KDE Connect developers, since it appears to be an issue with the app's handling (or not) of notifications generated by IFTTT (and possibly other apps).

You can file a bug against KDE Connect Android via this link, though I'd suggest searching for any open bugs first rather than possibly duplicating another report. (I took a quick look and didn't see anythng that appeared relevant, but I didn't look very hard.)

[svjmtn]

Thanks for your help!

Bug report filed on the KDEConnect Bug tracker: https://bugs.kde.org/show_bug.cgi?id=424982

[ferdnyc]

So, using my most recent debug-logging build of the Android app, I was able to determine that IFTTT notifications are ignored due to them having a flags value of 273, which corresponds to 0x111. That's:

    /**
     * Bit set in the Notification flags field when LEDs should be turned on
     * for this notification.
     */
    public static final int FLAG_SHOW_LIGHTS        = 0x00000001;
   /**
     * Bit set in the Notification flags field if the notification should be canceled when
     * it is clicked by the user.
     */
    public static final int FLAG_AUTO_CANCEL        = 0x00000010;
   /**
     * Bit set in the Notification flags field if this notification is relevant to the current
     * device only and it is not recommended that it bridge to other devices.
     */
    public static final int FLAG_LOCAL_ONLY         = 0x00000100;

The third of those is an exclusion criterion. So it seems that IFTTT is explicitly flagging its notifications as only relevant to the local device, preventing them from being mirrored.

I'm guessing this is because, since they're being delivered to the specific device in question by a remote (web) service, notifications from IFTTT could in principle be set up so they're delivered directly to the other device(s), so by blocking them from being relayed they prevent feedback loops.

...I wouldn't be surprised if Outlook uses the same LOCAL_ONLY flag for their notifications, which may explain bug #902.

[svjmtn]

That explains it. I am assuming a fix for this would require changes in the KDEConnect Android App?

[ferdnyc]

@enigma0160

Indeed. And not just changes in the bugfix sense, it'd require changing the behavior of the notifications plugin in way that would affect other apps.

IOW, this isn't strictly a KDE Connect app bug, either — it's working as designed. Including the exclusion of any notification with flags indicating, as the Android API documentation says, "it is not recommended that it bridge to other devices".

So, unless either the KDE Connect developers choose to ignore that status and mirror the notifications anyway (which seems a hard sell), or IFTTT stop setting the LOCAL_ONLY flag on their notifications, we're kind of at an impasse here.

[andyholmes]

So, unless either the KDE Connect developers choose to ignore that status and mirror the notifications anyway (which seems a hard sell), or IFTTT stop setting the LOCAL_ONLY flag on their notifications, we're kind of at an impasse here.

Given that the IFTTT app has a stable ID (which makes sense), @enigma0160 could request KDE Connect to let those notifications pass. Sort of the opposite of what they do with their own notifications' ID. I don't know that they want to maintain a list of App IDs like that, but you could ask.

[ferdnyc]

Ah, that makes sense!

And there's also this weirdo bit of code, establishing even more precedent for app-specific rules:

        if ("com.facebook.orca".equals(packageName) &&
                (statusBarNotification.getId() == 10012) &&
                "Messenger".equals(appName) &&
                notification.tickerText == null) {
            //HACK: Hide weird Facebook empty "Messenger" notification that is actually not shown in the phone
            return;
        }

[svjmtn]

@andyholmes Will do. @ferdnyc Thanks for figuring out the issue!

[andyholmes]

Closing this one, since it's an upstream issue. Feel free to re-open this issue or a new one if work on our side is needed.