The music stops after 3-6 minutes as soon as the device is in idle mode (on my test device, Samsung Galaxy Note8, Android 9 - identical to the Galaxy S8). This is a long known issue related to Doze mode. To avoid it, a Foreground service must be used.
I have pointed out this problem many times and years ago (e.g. also in the old AI2 forum, Niotron, Kodular forum).
Thanks for your observations Anke. Yes, that is an issue but not the only solution.
A Stay Awake routine can also prevent the screen from closing.
Either
Be aware using either an extension or a block routine drains your device battery rapidly . These work around methods are not running the app in the Background, they force the app screen to stay open.
So far, my experience has been similar to yours. My screen time out is set by the Android settings for a longer period than yours (5 minutes) so I experience:
Using installed apk:using ListViewer select on an Android 13, Samsung A(13) cell phone and used Wifi
Started Classic FM 02:16
Screen went to sleep at 02:21
Still playing audio stream at 02:27
Audio paused 02:29
Using ListViewer restarted at 02:29
continued through 02:42 screen went to sleep.
coninued playing through 2:48
that is essentially 22 continuous minutes.
Previously ran continuously for almost an hour by occasionally tapping the screen to stay open.
Can I equip your app with a stream finder that I use on my ESP32 internet radio? In my case, on android 9, the app crashes in companion. Ok, I see it's because of the custom font :).
I was going to guess the font made the issue. Great detective work. I did not anticipate that. Need to place a caution in the write up letting others know with Android 9 and possibly lower coders need to use the default fonts. 
Is this what you are talking about https://www.instructables.com/Internet-Radio-Using-an-ESP32/ .
Sure. The Radio Stream player code is for everyone to experiment. I am trying to produce something that is stable and that a visually impaired individual could actually use.
I'm aware of all the ways to keep the screen alive. Having published numerous apps in the Play Store (Android) and App Store (iOS) for more than 10 years, I know very well how users react to such KeepScreenOn variants.
It shouldn't be a coincidence that almost everything has been done on both Android and iOS in recent years to reduce battery consumption (on Android, e.g. since API 23 through the introduction of the Doze mode). In this respect, the only option left is to use a Foreground service (at least with Android on devices with API 23+).
Yes, the battery is still a problem in new devices. The development of the battery does not keep up with the development of technology. In the past, an 800mAh battery lasted several days in phones, now 5Ah is not enough ... and we know that a larger battery is a bigger, thicker and heavier device... That's why they come up with newer and newer optimizations for apps...
Similar design but by a different author. I found on github.
Here is your radio with search and favorites list.
RadioStreamVI_SR.aia (230.0 KB)
Yes, in some instances this code works
except when the WebView displays this rotating icon .
Any ideas? I will continue to experiment and try to trap the error message associated with the failure.
Perhaps this for errors?
Also, this seems to work well using the native webviewer, what is the need for CustomWebview? (although nothing wrong with using it 
)
Nice idea but using it refused to identify any errors I was getting. I tried the CustomWebView and it works to find errors.
Later today I will try your method of restart. Thanks
The only problem is that at this point when playback stops, CustomWebView doesn't return any error. He just freezes. I haven't noticed any dependencies either. I tried different streams mp3, aac, with different bitrates and the error occurs randomly.
Maybe it will be more stable just with some player. where you will also get metadata with the title of the song being played. I don't know if it makes sense to break down doors that are open.
It doesn't matter what audio format is used. The stream breaks off after a few minutes (~3-6 min randomly) in idle mode. I tested it (years ago) intensively and extensively on all AI2 distros. Doze mode shuts down all possible functions after a while to save battery power.
Again, the only way to avoid the problem is to use a Foreground service (at least if the app is going to be published on the Play Store; otherwise, there is a workaround).
It's not about idleness. We're talking about another bug, when switching streams sometimes some streams stop the player and then no other stream can be played. it's like webview is hanging... Then you have to turn the app off and on again. But later on the same link works that previously failed...
For that matter, I'm already experimenting with the Itoo extension, and your ActivityLifecycle. Is there any extension you recommend for the Foreground service?
I also made an extension that fetches Metadata from the url link, useful when using a WebView instead of a player.
It may be because it takes some time to buffer.
Taifun
Tried using open another screen screenName Block as you suggested. Unfortunately it does not unlock the Custom Web Viewer. Interesting potential work around but it is not a solution. Thanks
Can you make the webview freeze on demand, I have not had it freeze on me yet?
I'm having this bug too. And it cannot be done by demand. You can try changing the stream often.
Congratulations.
I've done a radio app before. You can update the radio list via google drive. No problem so far though
The radio was a problem when the phone rang. You had to turn off the radio. That's why I added dialing blocks. If a call comes in, the radio is switched to mute. After the call ends, the radio starts playing again.
I was making it keep playing with the clock block in the background.
Maybe you can add something like this.
I would recommend.
Be good if you could show your blocks coding for this, so that others can learn....
