Media/alarm audio channels reliant on notification audio channel

[tyleroconnell]

First thank you for making such a wonderful app, it's been really helpful for grounding myself in the present moment!

---

I've noticed the bell configuration's audio channels are not working as I expected, so I'll describe what I'm seeing below to determine whether the behavior is just a limitation of Android notifications.

If I set the audio channel, regardless of whether set to notification, media, or alarm, I am able to hear my selected bell when pressing play if that channel has it's volume above zero for my phone's respective Sound & vibration setting. If, however, I wait until the scheduled notification, I will only hear the bell if my phone's Sound & vibration setting has Ring & notification volume set above zero, in addition to the volume of the specific channel I've selected (if not notification).

My hope by selecting the audio channel was that I would be able to continue to keep my normal notifications on vibrate with Ring & notification volume set to zero, while selecting the alarm audio channel in mindfulnotifier to leverage my Alarm volume being a non-zero value (in the same way Clock's alarm makes sound even when my Ring & notification volume is set to zero because my Alarm volume is set above zero).

Though this is my first time hearing of Dart, I tried to identify what may be causing this. After inspecting audio.dart and notifier.dart, I don't see a distinction being made in the AndroidAudioAttributes that would lead me to expect that alarm audio is reliant on the notification channel being non-zero.

Device Info:

• Pixel 5, Android 11 (RQ3A.210705.001)
• Mindful Notifier 1.0.18:30
• Battery optimization disabled

[tyleroconnell]

I saw a comment related to this after the implementation of #31 but this seems different enough from #22 that I felt I should create a separate GitHub issue

[kmac]

I think I'm understanding this. I'll take a look at the code and see if I can see a reason for this behaviour.
(btw, I'm new to dart as well - I just figured it looked like an easy way to do an android app/UI)

[kmac]

It must be this code in notifier.dart, line 213, where it checks the ringerModeStatus

    if (!mute) {
      String ringerStatus = await SoundMode.ringerModeStatus;
      if (ringerStatus == "Normal Mode") {
        audioPlayer = getAudioPlayer(ds);
        audioPlayer.playBell();
      }
    }

I'll give this some thought, I may want to make a new option to override the phone ringer status. You'd still be able to mute via the 'mute' button on the main app screen.

And yes, I believe this issue is actually the same as what @lkblkb was referring to. I didn't realize I'd put in that check for ringer mode status though - I thought from the earlier comment that this behaviour was coming from the library.

Your hint about it sounding when playing from the test sound was key. Thanks for pointing that out.

I'll hopefully get some time over the next few days to figure something out for this.

[tyleroconnell]

Ah perfect, I'm really glad to hear it's not a limitation in Android itself and the above helped identify the culprit!

It's great to hear you're looking to take this on so quickly but please don't feel time pressured. In the meantime, I've set my notifications audio channel to the lowest setting and it's honestly so quiet that I barely notice alerts outside of the much louder alarm audio.

I'll give this some thought, I may want to make a new option to override the phone ringer status. You'd still be able to mute via the 'mute' button on the main app screen.

This seems like a reasonable approach to me. My original thought was users changing the audio channel to something other than notification (assuming that's the default) should then expect this to make noises on their phone if the selected audio channel isn't zero; in which case, I'm not sure that toggle would be entirely necessary. Adding that toggle under sound as you described would likely be the safer route though, since it wouldn't rely on my assumption of what users expect.

[kmac]

My original thought was users changing the audio channel to something other than notification (assuming that's the default) should then expect this to make noises on their phone if the selected audio channel isn't zero; in which case, I'm not sure that toggle would be entirely necessary.

This is a very good point. I think I was probably misunderstanding the entire reason for issue #31.

Given the above, yeah, I'm not sure I need to provide a toggle for this behaviour.

To summarize, it would work as follows:

• Notification channel: honours the phone mute & vibrate setting
• Media or Alarm channel: phone mute setting is ignored, the bell is only governed by the volume setting of the selected channel.
• Always mute if mute is set within the app itself

This makes sense, right?

[tyleroconnell]

Yep, that makes perfect sense to me!

The one remaining question I have is how the audio channels would react to do not disturb being enabled. If audioPlayer.playBell() is tied to the notification regardless of the audio channel, a user can long press for the option to override do not disturb as desired and this would fit in well with what I would see as expected behavior.

If, however, that call unexpectedly circumvents do not distrub, I think adding a toggle as to whether to honor do not distrub would be worthwile. In which case, the if (!mute) { could then be replaced with something to the effect of if (!mute && (!isDoNotDisturbActive || !isDoNotDistrubHonored)) {.

[kmac]

Do Not Disturb seems to be a bit of a challenge. It looks like it depends a lot on the Android version for the behaviour.

I'm seeing in Android 10 that you can allow alarms or media sounds through, but the notification itself (i,e., the popup) is squelched.
In Android 11 you can allow apps to override DND, so if you want you could get the notification back. But I would have to figure out how to determine if my app has been bypassed - I may need to find a flutter plugin to handle that case.

I think for now I will just put something in where, if DND is active, then there will at minimum be no sound. There may be a notification (if the app is bypassed in Android 11), but there will be no sound. This seems reasonable to me for now, and I may revisit the DND behaviour for Android 11 in the future.

[kmac]

Fixed in Release 1.0.19+31

Thanks very much for your input on this!

[tyleroconnell]

@kmac thank you for fixing this so quickly!

I have an F-Droid rookie question: is there a propogation delay between GitHub releases and F-Droid updates?

Looking at f-droid/fdroiddata, I see an entry for fdroiddata/metadata/com.kmac5dev.mindfulnotifier.yml that was updated to 1.0.19 by the F-Droid checkupdates bot yesterday. I presume this was automated by F-Droid and tied to the 1.0.19+31 GitHub release that you published. What I'm a little confused on is why even after the fdroiddata update, I don't see an update available in F-Droid and the Mindful Notifier page still indicates the last release was a month ago (which aligns with the 1.0.18+30 version I have on my phone).

[kmac]

I think it usually takes a few days to get a build from fdroid. It should get queued in the fdroid build after I created the v1.0.19 tag in github. I think it just hasn't built it yet.

[tyleroconnell]

Makes sense, thanks again! I'll have to research a bit more on how F-Droid functions since this whole setup is very intriquing; it's awesome having open source apps tied directly to an open source app store.