Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't forward ephemeral download/service notifications to wearable devices #6510

Closed
3 tasks done
digitalcircuit opened this issue Jun 7, 2023 · 5 comments
Closed
3 tasks done

Don't forward ephemeral download/service notifications to wearable devices #6510

digitalcircuit opened this issue Jun 7, 2023 · 5 comments
Labels
Functionality: Interacting devices Anything related to Android Auto, smart watches & smart speakers Type: Feature request

Comments

@digitalcircuit
Copy link

digitalcircuit commented Jun 7, 2023 •
edited

Checklist

  • I have used the search function for open and closed issues to see if someone else has already submitted the same feature request.
  • I will describe the problem with as much detail as possible.
  • This request contains only one single feature, not a list of multiple (related) features.

App version

3.0.2

Where did you get the app from

F-Droid

Problem you may be having, or feature you want

Currently, AntennaPod download and service notifications are forwarded to wearable devices, e.g. the Bangle.js watch when paired with Gadgetbridge.

This results in spamming the list of notifications when refreshing podcasts and with every percentage change when downloading media, and generates a useless Loading. If this does not go away, play any episode and contact us. message, too.

Suggested solution

AntennaPod should specify setLocalOnly(true) for download and service notifications.

E.g. this (untested) change to PlaybackServiceNotificationBuilder.java:

@@ -150,6 +150,10 @@
         } else {
             notification.setContentTitle(context.getString(R.string.app_name));
             notification.setContentText("Loading. If this does not go away, play any episode and contact us.");
+            // Don't show on wearable devices if possible
+            if (Build.VERSION.SDK_INT >= 20) {
+                notification.setLocalOnly(true);
+            }
         }
 
         notification.setContentIntent(getPlayerActivityPendingIntent());

And this (untested) change to DownloadServiceNotification.java:

@@ -69,6 +69,10 @@
         notificationCompatBuilder.setContentTitle(contentTitle);
         notificationCompatBuilder.setContentText(contentText);
         notificationCompatBuilder.setStyle(new NotificationCompat.BigTextStyle().bigText(bigText));
+        // Don't show on wearable devices if possible
+        if (Build.VERSION.SDK_INT >= 20) {
+            notificationCompatBuilder.setLocalOnly(true);
+        }
         return notificationCompatBuilder.build();
     }

This copies the approach taken by a recent KeePass2Android update, which removed some useless notifications from showing up on wearables there, too.

Screenshots / Drawings / Technical details

This makes use of the Notification.Builder setLocalOnly() function:

Set whether or not this notification should not bridge to other devices.

Some notifications can be bridged to other devices for remote display. This hint can be set to recommend this notification not be bridged.
@digitalcircuit digitalcircuit changed the title Don't forward ephemeral download/service notifications to paired wearable devices Don't forward ephemeral download/service notifications to wearable devices Jun 7, 2023
@keunes keunes added Type: Enhancement Functionality: Interacting devices Anything related to Android Auto, smart watches & smart speakers labels Jun 7, 2023
@ByteHamster
Copy link
Member

Hmm, I don't think it is a good idea to generally hide all download notifications from connected devices. That could be unexpected for other users.

This results in spamming the list of notifications when refreshing podcasts and with every percentage change

AntennaPod already specifies setOnlyAlertOnce, so this sounds like a problem in GadgetBridge ignoring the flag.

@digitalcircuit
Copy link
Author

Hmm, I don't think it is a good idea to generally hide all download notifications from connected devices. That could be unexpected for other users.

Fair point - I s'pose I could imagine someone wanting to monitor the download progress from their watch or computer (e.g. KDE Connect) if their connection is rather slow.

Considering I never see the Loading. If this does not go away, play any episode and contact us. notification on my phone, I'm guessing that might be a separate bug with Gadgetbridge and/or Bangle.js not deleting the notification.

AntennaPod already specifies setOnlyAlertOnce, so this sounds like a problem in GadgetBridge ignoring the flag.

Hmm. In that case, I'm not sure if it's Gadgetbridge ignoring the flag, or the way the Bangle.js handles receiving alerts from Gadgetbridge. The frequent notification percentage updates seems to temporarily overwhelm the watch as it can take 15+ seconds just to stop showing updates once AntennaPod finishes.

I've linked to this issue on the Espruino forums for Bangle.js over here: https://forum.espruino.com/conversations/388123/

@ByteHamster
Copy link
Member

Closing, as AntennaPod behaves as intended (using setOnlyAlertOnce and updating, not re-creating, the notification). The issue seems to be somewhere in Bangle.js or Gadgetbridge.

@digitalcircuit
Copy link
Author

I'll continue the discussion with the Bangle.js/Gadgetbridge community, thank you!

@digitalcircuit
Copy link
Author

Small positive update: With the changes to service notifications in AntennaPod 3.1.0, I haven't recreated the issue with refreshing/downloading notifications spamming my watch via Gadgetbridge (0.75.1; not upgraded to 0.76 yet as it hasn't yet rolled out over F-Droid).

The "Loading... If this does not go away" message still occasionally lingers, but I suspect that's a Gadgetbridge bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Functionality: Interacting devices Anything related to Android Auto, smart watches & smart speakers Type: Feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@digitalcircuit @ByteHamster @keunes