Signal-android: Signal allows device to sleep while playing audio

[prg318]

• [x ] I have searched open and closed issues for duplicates
• [x ] I am submitting a bug report for existing functionality that does not work as intended
• [x ] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [x ] This isn't a feature request or a discussion topic

---

Bug description

When a signal user plays an audio file in that another signal user has sent them inside the signal app, signal does nothing to prevent the device from "going to sleep" or turning the screen off while the audio is being played. If a user tries to play a clip that's longer than ~30 seconds (or whatever the timeout is configured to be), the audio clip will pause and the user will need to unlock the phone to continue playing the audio clip.

Steps to reproduce

• Receive a long (longer than the screen timeout; try any song 2 minutes or more) audio file in signal
• Play the audio file in signal
• Don't touch the phone, just try to listen to the whole file

Actual result: Phone screen shuts off and also pauses audio playback
Expected result: phone should not go to sleep during audio playback - audio playback should continue until end of file

Screenshots

Not necessary

Device info

Google Pixel XL 128GB
Android 9 (December update)
Signal 4.31.6 (installed from Google Play)

Link to debug log

this is not necessary (but let me know if you somehow cannot reproduce this - would be happy to help!)

[wesinator]

The better solution to this should be to keep playing audio with control notification when screen locks, like most audio/music apps do.
Instead of just keeping the screen on which drains more power.

cc #8470

[florisvanvugt]

I experience the same issue, I would much appreciate a fix along the lines of what wesinator suggests. I have no experience with developing for this platform but please let me know if I can contribute anything.

[thomaseizinger]

Does this also apply to voice messages being sent?

The solution proposed in @wesinator's comment makes sense for audio file playback but it is strange for voice messages.

I would expect the following behaviour (which, if I understand correctly, contradicts with the solution proposed in https://github.com/signalapp/Signal-Android/pull/9063):

1. Playing a voice messages prevents the phone from going to sleep.
   The intention here is that I want to listen to the full voice message AND reply to it after the voice message is finished. Having the phone go to sleep and interrupt the voice message blocks this workflow.

2. Actively locking the phone should stop the playback.
   Actively locking the phone should be treated as "I am not interested in using the phone anymore so the playback should stop". The same thing applies with closing Signal or leaving the conversation.

[dwong]

@thomaseizinger besides choosing a file to send vs recording and then sending directly from Signal, there isn't a difference between those audio files. At the end of the day it's still just an audio file being sent. So yes, this change would also apply to voice messages.

[thomaseizinger]

@dwong thanks for your answer!

If there is no difference between those files, any chance we can get a different behaviour (closer to what I described above)?
Having to unlock my phone again to answer a message, just because the audio message is longer than my screen timeout is a bit annoying :/

I would be very much in favor of your original solution: https://github.com/signalapp/Signal-Android/pull/8470.

The better solution to this should be to keep playing audio with control notification when screen locks, like most audio/music apps do.
Instead of just keeping the screen on which drains more power.

For what it's worth: I believe the main point is that audio messages are not about music but communicating. Hence, it is an active use of the phone, contrary to listening to music where you don't need your screen turned on or just basic controls like play, pause, next or previous.

[dwong]

@thomaseizinger I guess it doesn't matter that much to me, but I'll leave it to a signal dev to determine which behavior they want. As a signal user, I probably prefer #9063 instead of #8470, but I don't feel very strongly.

[thomaseizinger]

@dwong Whichever behaviour makes it into master, thank you for your work :)

[basileradisson]

Hi everyone,
I have the same problem with a pocophone f1 (miui11)

[Tomptez]

Oh, nice, when will this pull request be merged? Really looking forward to this!

[Totorrr]

This bug seems to be a duplicate of #7954

[Campano]

+1 for merging ASAP, I had a non-technical friend complaining about this being a major pain point.

[Totorrr]

Looking forward to this. Signal is so cool, but having to touch the screen every 25 seconds to be able to listen to a 3 minutes vocal message is such a pain!

I asked my friends to leave other untrusted apps for Signal, and for some of them this issue is a no-go. Some see it as a significant regression in usability when coming from other apps.

Apparently, _fumiakiy_ (from #7954) implemented an audio playback service, which would be the perfect option for peace of mind IMHO:
https://github.com/fumiakiy/Signal-Android/commit/170ffee89ba67025d81dd75fa40d621a662451d4

[jadster]

Same here. Looking for a secure app that suits everyone in our family. This issue is a showstopper as we like to communicate with voice messages that often are a few minutes long. One of my family members‘ phone goes to sleep after 30sec and the play stops.

This is on an "honor" 7X phone running newest version of system software and Signal.

[quintrino]

So this issue is now resolved in the beta (possibly even in public release) so you shouldn't have to wait too long at all!

[Totorrr]

I can confirm there is a new audio playing service within Signal. Thank you very much to people involved in this change. That makes Signal voice messages much more usable for me and some of my friends!

I observe a few bugs with the audio playing interface, but overall I like it a lot more. :)

@greyson-signal maybe you want to close this? or leave it open for feedback/bugs on the new feature

[prg318]

The new audio playing service is a great solution to this issue! The time and effort gone into this is greatly appreciated by my bandmates and me. Great job to everyone involved. Cheers!

Thanks again!