-
-
Notifications
You must be signed in to change notification settings - Fork 654
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.
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
Use a distinct Zulip notification sound, on Android #3150
Comments
Thank you for raising this issue. I can see how that is important. |
I'm not sure what you mean by a different default sound. It's using the default notification sound as dictated by Android. I can change this in the Android settings, so it's not a problem with the particular sound. I would definitely like to be able to set a customized sound particular to Zulip. Having this on the roadmap is good enough for me. I don't have any experience with Android development, though I've been meaning to pick it up. Might see if I can take a crack at it if I can find the time. |
I think I did explain it incorrectly. I meant different default sound for the Zulip app (not the system). But if you are interested in trying to do it yourself, would be even cooler. 👍 |
No, I was referring to the sound played by the push notifications. |
Huh. Looking into this, Android vastly changed the way notifications work as of Android 8. Zulip is already providing a Notification Channel, which provides a native interface for managing notification priority/sound. I'm still running Android 7 on my phone, so I don't get said options. Per stream notification settings would still be nice, which I gather would involve creating a new notification channel per stream (when the user indicates they want to receive notifications for that stream), rather than just using a single channel like it is now. Might still see if I can write some Android 7 specific code to provide the option. What's the stance on code that's exclusively for backwards compatibility around here? Wider support is always valuable, but there's definitely a maintenance burden involved, so the stance "just upgrade" is certainly understandable. |
Cool, you have been reading the right stuff. 👍 We definitely intend to support older Android versions for a long time (7 is not that old in Android's world). Currently, we support 4.4 and newer |
Thanks @kalzekdor for writing in! Zulip actually has a custom notification sound specific to Zulip, which we've used in the webapp for a long time and which we recently fixed our notifications on iOS to use. There's code in the app that's intended to do this for Android too -- so the fact that it isn't is a bug. It sounds like if we fixed that bug it would largely cover what you really want here, so I've taken the liberty of retitling this issue to reflect that bug. Conveniently we also just added support in the webapp for customizing the notification sounds, which in the future the mobile app will also support; see #3204 for that. Personally I normally have notification sounds disabled system-wide on my phone ("ring volume" turned down to zero), so I've never noticed. I tested just now (on Android 9), and I reproduce -- I get the system default sound just as you do. So we just need to debug and fix. |
PS: here's that code in the app:
The sound that's intended to play is |
@zulipbot claim |
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
@gnprice Sounds good! I tried looking into implementing a setting for a custom sound, but I ran into some problems getting the React framework communicating with native android intents. I unfortunately don't have a lot of time to spare for side projects, so glad to hear about those changes. |
The wix notification library's manifest file has this element with `android:maxSdkVersion="18"`, so it only applies on API <= 18 (which we don't even support). That appears to be intended as a workaround for an ancient Android bug, fixed in Android 4.2.1 and 4.3 here: https://android.googlesource.com/platform/frameworks/base/+/cc2e849fa Notification vibration improvements: [DO NOT MERGE] - When notifications vibrate as a fallback (that is, because they want to play a sound but the device is in vibrate mode), this no longer requires the VIBRATE permission. - As a bonus, if your notifications use DEFAULT_VIBRATE, you don't need the VIBRATE permission either. - If you specify a custom vibration pattern, you'll still need the VIBRATE permission for that. - Notifications vibrating in fallback mode use same vibration pattern but can be changed easily in future. - The DEFAULT_VIBRATE and fallback vibrate patterns are now specified in config.xml. (That commit appears in `git log android-4.2_r1..android-4.2.1_r1`, and is present in `android-4.3_r1` too. Android 4.2 is API 17, and Android 4.3 is API 18.) OK, but we *do* specify a custom vibration pattern. So we need the VIBRATE permission even after this bug fix. And we've had this element in our manifest to do that... but when the Android build system merges our manifest with the library's, that extra `android:maxSdkVersion` attribute from the library gets merged into this element, so the much narrower workaround-request in the library effectively clobbers our broader request. As a result, our custom vibration pattern has basically never worked, except for the few users on API <=18 back when we even supported that. Fix the manifest so it can work. It still doesn't work on API >=26, for the same reason as zulip#3150: we need to specify the pattern on the channel, not the individual notification. We'll fix that separately.
The wix notification library's manifest file has this element with `android:maxSdkVersion="18"`, so it only applies on API <= 18 (which we don't even support). That appears to be intended as a workaround for an ancient Android bug, fixed in Android 4.2.1 and 4.3 here: https://android.googlesource.com/platform/frameworks/base/+/cc2e849fa Notification vibration improvements: [DO NOT MERGE] - When notifications vibrate as a fallback (that is, because they want to play a sound but the device is in vibrate mode), this no longer requires the VIBRATE permission. - As a bonus, if your notifications use DEFAULT_VIBRATE, you don't need the VIBRATE permission either. - If you specify a custom vibration pattern, you'll still need the VIBRATE permission for that. - Notifications vibrating in fallback mode use same vibration pattern but can be changed easily in future. - The DEFAULT_VIBRATE and fallback vibrate patterns are now specified in config.xml. (That commit appears in `git log android-4.2_r1..android-4.2.1_r1`, and is present in `android-4.3_r1` too. Android 4.2 is API 17, and Android 4.3 is API 18.) OK, but we *do* specify a custom vibration pattern. So we need the VIBRATE permission even after this bug fix. And we've had this element in our manifest to do that... but when the Android build system merges our manifest with the library's, that extra `android:maxSdkVersion` attribute from the library gets merged into this element, so the much narrower workaround-request in the library effectively clobbers our broader request. As a result, our custom vibration pattern has basically never worked, except for the few users on API <=18 back when we even supported that. Fix the manifest so it can work. It still doesn't work on API >=26, for the same reason as zulip#3150: we need to specify the pattern on the channel, not the individual notification. We'll fix that separately.
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
The wix notification library's manifest file has this element with `android:maxSdkVersion="18"`, so it only applies on API <= 18 (which we don't even support). That appears to be intended as a workaround for an ancient Android bug, fixed in Android 4.2.1 and 4.3 here: https://android.googlesource.com/platform/frameworks/base/+/cc2e849fa Notification vibration improvements: [DO NOT MERGE] - When notifications vibrate as a fallback (that is, because they want to play a sound but the device is in vibrate mode), this no longer requires the VIBRATE permission. - As a bonus, if your notifications use DEFAULT_VIBRATE, you don't need the VIBRATE permission either. - If you specify a custom vibration pattern, you'll still need the VIBRATE permission for that. - Notifications vibrating in fallback mode use same vibration pattern but can be changed easily in future. - The DEFAULT_VIBRATE and fallback vibrate patterns are now specified in config.xml. (That commit appears in `git log android-4.2_r1..android-4.2.1_r1`, and is present in `android-4.3_r1` too. Android 4.2 is API 17, and Android 4.3 is API 18.) OK, but we *do* specify a custom vibration pattern. So we need the VIBRATE permission even after this bug fix. And we've had this element in our manifest to do that... but when the Android build system merges our manifest with the library's, that extra `android:maxSdkVersion` attribute from the library gets merged into this element, so the much narrower workaround-request in the library effectively clobbers our broader request. As a result, our custom vibration pattern has basically never worked, except for the few users on API <=18 back when we even supported that. Fix the manifest so it can work. It still doesn't work on API >=26, for the same reason as zulip#3150: we need to specify the pattern on the channel, not the individual notification. We'll fix that separately.
The wix notification library's manifest file has this element with `android:maxSdkVersion="18"`, so it only applies on API <= 18 (which we don't even support). That appears to be intended as a workaround for an ancient Android bug, fixed in Android 4.2.1 and 4.3 here (and yes, the "DO NOT MERGE" is in the original, lol): https://android.googlesource.com/platform/frameworks/base/+/cc2e849fa Notification vibration improvements: [DO NOT MERGE] - When notifications vibrate as a fallback (that is, because they want to play a sound but the device is in vibrate mode), this no longer requires the VIBRATE permission. - As a bonus, if your notifications use DEFAULT_VIBRATE, you don't need the VIBRATE permission either. - If you specify a custom vibration pattern, you'll still need the VIBRATE permission for that. - Notifications vibrating in fallback mode use same vibration pattern but can be changed easily in future. - The DEFAULT_VIBRATE and fallback vibrate patterns are now specified in config.xml. (That commit appears in `git log android-4.2_r1..android-4.2.1_r1`, and is present in `android-4.3_r1` too. Android 4.2 is API 17, and Android 4.3 is API 18.) OK, but we *do* (attempt to -- see below) specify a custom vibration pattern. So we need the VIBRATE permission even after this bug fix. And we've had this element in our manifest to do that... but when the Android build system merges our manifest with the library's, that extra `android:maxSdkVersion` attribute from the library gets merged into this element, so the much narrower workaround-request in the library effectively clobbers our broader request. As a result, our custom vibration pattern couldn't ever have worked, except for the few users on API <=18 back when we even supported that. Fix the manifest so that any non-default vibration settings can possibly work at all. Even after this fix, we don't actually get non-default vibration behavior, due to additional layers of confusion which have been surrounding this bug. First, despite calling `setVibrate` on the `Notification.Builder` to attempt to set a custom vibration pattern, we've also been calling `setDefaults` -- which overrides any value set with `setVibrate`. (As well as our `setSound`, and any custom lights settings if we'd had any.) On top of that, on API >=26 any vibration settings on the notification itself are ignored completely, deferring to the settings on its channel instead. Compare zulip#3150. In subsequent commits we can address these two other issues, and start actually choosing vibration settings.
The wix notification library's manifest file has this element with `android:maxSdkVersion="18"`, so it only applies on API <= 18 (which we don't even support). That appears to be intended as a workaround for an ancient Android bug, fixed in Android 4.2.1 and 4.3 here (and yes, the "DO NOT MERGE" is in the original, lol): https://android.googlesource.com/platform/frameworks/base/+/cc2e849fa Notification vibration improvements: [DO NOT MERGE] - When notifications vibrate as a fallback (that is, because they want to play a sound but the device is in vibrate mode), this no longer requires the VIBRATE permission. - As a bonus, if your notifications use DEFAULT_VIBRATE, you don't need the VIBRATE permission either. - If you specify a custom vibration pattern, you'll still need the VIBRATE permission for that. - Notifications vibrating in fallback mode use same vibration pattern but can be changed easily in future. - The DEFAULT_VIBRATE and fallback vibrate patterns are now specified in config.xml. (That commit appears in `git log android-4.2_r1..android-4.2.1_r1`, and is present in `android-4.3_r1` too. Android 4.2 is API 17, and Android 4.3 is API 18.) OK, but we *do* (attempt to -- see below) specify a custom vibration pattern. So we need the VIBRATE permission even after this bug fix. And we've had this element in our manifest to do that... but when the Android build system merges our manifest with the library's, that extra `android:maxSdkVersion` attribute from the library gets merged into this element, so the much narrower workaround-request in the library effectively clobbers our broader request. As a result, our custom vibration pattern couldn't ever have worked, except for the few users on API <=18 back when we even supported that. Fix the manifest so that any non-default vibration settings can possibly work at all. --- Even after this fix, we don't actually get non-default vibration behavior, due to additional layers of confusion which have been surrounding this bug. First, despite calling `setVibrate` on the `Notification.Builder` to attempt to set a custom vibration pattern, we've also been calling `setDefaults` -- which overrides any value set with `setVibrate`. (As well as our `setSound`, and any custom lights settings if we'd had any.) On top of that, on API >=26 any vibration settings on the notification itself are ignored completely, deferring to the settings on its channel instead. Compare #3150. In subsequent commits we can address these two other issues, and start actually choosing vibration settings.
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
From API >= 26, Android added support of Notification channels. So now notifications sounds are handelled by channels, not by notification itself. So set sound to our one and only defualt channel. Fixes: zulip#3150
I've retitled this to reflect what we actually want to do here, for the reasons I explained at #3233 (comment) back in 2018. New chat discussion here: |
I've recently started using the Zulip client for Android. One thing that seems missing is the option to use a custom notification sound. Any notifications use the default notification sound. I heavily prefer having different notification sounds for different things, so I can tell without looking at my phone what's asking for my attention. The ability to customize the notification sound is a major QoL feature for me, even better would be the ability to set a per-stream notification sound.
Are there any plans along these lines?
The text was updated successfully, but these errors were encountered: