I've made several tests using different playback methods.
What makes this audio-suppression complex difficult to diagnose: There are multiple overlapping issues that can easily be conflated. Additionally, seemingly similar audio players and sources are treated quite differently by the OS + Vanadium.
So far I've isolated at least 2 issues which I can consistently reproduce on a Pixel 8. I expect there are more, but the following should be relatively simple to grasp (which does not necessarily equate to easy to fix).
If you want to help with error analysis, I invite to reproduce them.
Recommended prerequisites to test and isolate below audio-issues:
- Disable battery saver.
- Use the device with external power source connected.
- This way I'd expect that the influence of power saving features is minimized
Settings >Search for: lock --> choose Lock after screen timeout , set radiobutton to 30 minutes
- This is to disentangle two very distinct, although by-default closely associated functionalities: The screen timeout and the (AFU) locking of the device.
- NOTE: This is for testing only and only if you consider your device at a safe place (or don't care for its unlocked content) since this setting per se raises the risk that your device might be accessed with dark but unlocked screen. Remember to set back to your favorite setting after the testing.
- BTW: This setting will show, that below issues 1 and 2 happen after the screen goes dark, but are NOT a matter of locking. Consequently they should not originally be related to some hardening function; fixing below behavior should not significantly weaken the system (at least not regarding device locking).
- Set
Settings > Display > Screen timeout: 15 seconds
- This is just to provoke our test results faster (and disentangle screen timeout and locking even further). You can ofc keep the default settings, but will have to spend significantly more time for each test case, then...
- Set
Settings > Display > Lock screen > Lift to check phone: Off
- The reason for this is that we want to exactly control, when the phone (screen) is awake. Otherwise the "Lift to check"-feature would be prone to provoke unexpected reactivations of the screen.
- Before I disabled "Lift to check" for good (ca. 2 years ago) even stomping on the ground next to wooden furniture carrying the phone could wake the phone up. I personally found this highly annoying and never missed it.
- Optionally: Have a stopwatch ready or another visible, precise clock to track how much time passed after inactivity etc.
- Put your phone is in a safe position that should prevent further touches or movement from anyone but you. (No curious cats touching the screen or the like ;-))
1. Issue: Offline (file-based) playback is stopped ca. 5 to 45 s after screen timeout
This happens completely offline without any installed apps. Simply store an audio file in your device's filesystem and play it with the built-in player from default file manager ("Files").
More detailed steps-to-reproduce:
- Download demo ogg file that is at least 2 minutes long. Longer is better.
Files > (by default this should start with open downloads folder; ensure that you are in the folder where your demo audio file is stored) - Note the time or start your stopwatch + click the demo file
- Leave the phone (with file manager and player in foreground) alone. No touches and no moving it (particularly if you still have "Lift to check phone" on; you shouldn't, cp. recommended prerequisites above). Watch the time.
--> Expectation: The screen goes dark (according to Screen timeout settings, see above), while audio plays indefinitely.
--> What actually happens: The screen goes dark as expected, but the playback is stopped -- and that means actually stopped in the player, not just played silently -- ca. 5 to 45 s after screen timeout.
- Additional strangeness: In my case the above "Rondo Alla Turka"-ogg-file was always stopped after constant ca. 5 s. However, another file - an mp3 which I stored from Molly - is stopped after a variable time, somewhere between 5 s and ca. 45 s. I've no clue why these are treated differently. Anyway, constant of variable, it's both unexpected for me.
2. Issue: Online audio content on certain pages is muted 5 s after screen timeout
After the Android 17 upgrade, at certain pages' audio content is not longer treated as screen-timeout-compatible audio media in Vanadium.
Steps-to-reproduce:
- Vanadium
- Make sure that there is no tab with audio playback currently active. Ideally close all tabs to be sure.
- Access https://mynoise.net/NoiseMachines/windSeaRainNoiseGenerator.php ,
- Make sure, that the wind and sea noise plays.
- Leave the phone (with vanadium and the page in foreground) alone. Again, no touches and not moving phone (particularly cp. above comments about interference of "Lift to check phone")
--> Expectation: The screen goes dark (according to Screen timeout settings, see above), while audio plays indefinitely. If you lock the phone with the site buttons and click again to show the screen content, a small control field should give basic infos and playback control buttons.
--> What actually happens: The screen goes dark as expected, but the playback is muted after 5 s. If you lock the phone via side button presses and click again to show the screen content, no control field tells about the generator.
It's important to note, that other sites (e.g. bandwagon.fm) might still work (at least for about 30 minutes).
Before, with Android 16, you could listen to these, as long as Vanadium was in focused in foreground when the screen was dark. Note that my test case was a bit different then, since screen timeout setting and display lock had been happening in close succession. (No disentanglement, as I set up for this test case.) But even this - more difficult - case worked in the past.
Further Issues ?
Again, there can easily be further issues, more related to power saving or security functions. The way you put your older comments read like there could be such further complications. Hence, with above prerequisites I tried to avoid these for the test cases at hand.
Concluding Remarks
In case anyone has knows a solution how to configure the phone so that above two cases work without root access and or ADB magic (unless officially authorized), I'd be very glad to read it. Same goes for improved ways to test these, particularly in case I made any significant mistake or suffered a misunderstanding.
Friendly reminder for all testers: After testing, set the Lock after screen timeout back to your preferred setting. :-)
PS: This was written entirely with HI, noAI, even if the formatting might look a bit like the style text generator apparently default to nowadays. Or maybe I am just already drilled to put text like LLMs do.
TL;DR
Bimmy describes how to test and reproduce two separate audio supression issues that might or might not be related to other people's observations. Welcomes attempts to reproduce his cases.