This repository has been archived by the owner on Dec 3, 2024. It is now read-only.
Disable badge for persistent notification (fixes #1305) #1307
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose:
As mentioned in #1305, some users don't like the "dot" (badge) displayed when there is not really new info available.
Changes:
The current behavior is that the dot is always shown when syncthing has a notification open - usually the persistent
Syncthing is running
message used for the background service.This PR changes this behavior and disables the dot/badge when only the
Syncthing is running
notification is displayed. This does not affect the operation of the notification or the service.Please note that this only affects the
Syncthing is running
notification. TheSyncthing is disabled
message or other info notifications will still get a badge. This is intentional, because I think these notifications deserve attention from the user.Tests:
I verified this briefly on Android Emulators running Android 8.1, 7.0 and 4.4. On API level >= 26 (Oreo) this works as intended, on lower Androids this has no effect because this feature does not exist.
Compatibility note:
NotificationChannel.setShowBadge()
was added in API level 26. The buildscript currently targets/compiles this API level, therefore I concluded that usage of this method is unproblematic. The method call is guarded by a version comparison, to avoid calling this on anything lower than Oreo.