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.

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

Closed
kalzekdor opened this issue Nov 16, 2018 · 11 comments · Fixed by #5221
Closed

Use a distinct Zulip notification sound, on Android #3150

kalzekdor opened this issue Nov 16, 2018 · 11 comments · Fixed by #5221

Comments

@kalzekdor
Copy link

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?

@borisyankov
Copy link
Contributor

Thank you for raising this issue. I can see how that is important.
We have thought about that but I don't think we considered this a priority.
The more we hear about a certain feature requested, the more we bump it up.
Do you expect the default sound to be different/better or customizable and be able to be set by you? (I think the first option, being simpler has better chance of being implemented sooner)

@kalzekdor
Copy link
Author

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.

@borisyankov
Copy link
Contributor

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. 👍

@kalzekdor
Copy link
Author

No, I was referring to the sound played by the push notifications.

@kalzekdor
Copy link
Author

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.

@borisyankov
Copy link
Contributor

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

@gnprice gnprice changed the title Custom notification sound on Android Android notifications don't use Zulip's notification sound Dec 21, 2018
@gnprice
Copy link
Member

gnprice commented Dec 21, 2018

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.

@gnprice
Copy link
Member

gnprice commented Dec 21, 2018

PS: here's that code in the app:

android/app/src/main/java/com/zulipmobile/notifications/GCMPushNotifications.java

        if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP) {
            AudioAttributes audioAttr = new AudioAttributes.Builder()
                    .setUsage(AudioAttributes.USAGE_NOTIFICATION).build();
            builder.setSound(Uri.parse("android.resource://" + mContext.getPackageName() + "/" + R.raw.zulip), audioAttr);
        } else {
            builder.setSound(Uri.parse("android.resource://" + mContext.getPackageName() + "/" + R.raw.zulip));
        }

The sound that's intended to play is android/app/src/main/res/raw/zulip.mp3.

@jainkuniya
Copy link
Member

@zulipbot claim

jainkuniya added a commit to jainkuniya/zulip-mobile that referenced this issue Dec 22, 2018
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
jainkuniya added a commit to jainkuniya/zulip-mobile that referenced this issue Dec 22, 2018
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
@kalzekdor
Copy link
Author

@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.

gnprice added a commit to gnprice/zulip-mobile that referenced this issue Dec 27, 2018
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.
gnprice added a commit to gnprice/zulip-mobile that referenced this issue Dec 27, 2018
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.
jainkuniya added a commit to jainkuniya/zulip-mobile that referenced this issue Dec 30, 2018
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 pushed a commit to jainkuniya/zulip-mobile that referenced this issue Jan 5, 2019
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 added a commit to gnprice/zulip-mobile that referenced this issue Jan 5, 2019
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.
gnprice added a commit to gnprice/zulip-mobile that referenced this issue Jan 5, 2019
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.
gnprice added a commit that referenced this issue Jan 5, 2019
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.
jainkuniya added a commit to jainkuniya/zulip-mobile that referenced this issue Jan 8, 2019
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
jainkuniya added a commit to jainkuniya/zulip-mobile that referenced this issue Jan 8, 2019
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 gnprice changed the title Android notifications don't use Zulip's notification sound Use a distinct Zulip notification sound, on Android Nov 20, 2021
@gnprice
Copy link
Member

gnprice commented Nov 20, 2021

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:
https://chat.zulip.org/#narrow/stream/48-mobile/topic/notification.20sound/near/1280133

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment