📻 WebView Radio Stream Player

I'm having this bug too. And it cannot be done by demand. You can try changing the stream often.

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

It might be worth a try creating an html file to play back the audio streams, then you could use javascript to detect/handle any errors in the playback stream....

Regarding a foreground service

I modified Ullis' Keep Alive Service example as follows .

The code plays a single radio stream in excess of 45 minutes in the foreground while allowing you to use other apps concurrently.

I will clean up this example up and integrate KAS into a version of Radio Stream Player later today or tomorrow (unless someone else post a more detailed example first) that supports doze mode. Be aware, like a Stay Awake routine, KAS eats battery energy.

Tested on an Android 13 Samsung A13. Played the stream continuously for over 45 minutes (when I stopped testing) while allowing a phone call and use of other apps while streaming. :astonished:

This is how I used phone call blocks in my radio show.
My app used to work better. It even worked on Android 2.4 version.
But it started to cause problems in higher versions. I did not fix the program afterwards. I am doing the update from a file on google drive.
I haven't updated my radio app because of this.
I moved it to the internet.
It can be listened through the internet browser.


MY source code :
SAFAK_RADIO_V3.aia (203.9 KB)

1 Like

You are using the player component. I tested yesterday with the Player, loading the stream to the Player is synchronous and freezes the entire app for a while or longer. Are you experiencing this? This is especially noticeable in the ListView.

I did some tests with custom <audio> and custom <video> in html. Unfortunately, I cannot make the playback start automatically like it does with the original player. I have the autoplay control set.

Yes, I had a play with this too. Requires some form of interaction from the user.

Thanks, will try with <iframe> later.

Doesn't work, Chrome blocked that too. To play sound, user must interact with the web page (touch/click), you cannot program it (e.g. with javascript).

Isn't there some permission to ask for autoplay to work? Strange that the original WebView browser has autoplay.

If calling a url directly into the webview, it will play automatically. Any kind of web page that has a sound source will not play unless the user interacts with the webpage to say "yes, I want sound"

This stops all websites from playing sound automatically in their ads etc. You can autoplay a sound file, but it has to be muted, the user then has to unmute the playback by interacting with the web page.

<audio id="radio" autoplay muted>
		<source src="http://stream.live.vc.bbcmedia.co.uk/bbc_radio_two">
	Your browser does not support the audio element.

<button id="unmuteButton">UNMUTE</button>

var radio = document.getElementById('radio');
unmuteButton.addEventListener('click', function() {
radio.muted = false;

So unmute or play can't be called from outside? So Google thinks for us again and knows better what people want. And it would be enough for them to add some permission so that the user can decide what he wants to play automatically and what not...

-- Steve

When I first did it on Android 2.4, this problem seemed very minimal. It wasn't a problem. But as android versions got higher, there were more and more problems. Now I can't use it because of this freezing problem.
But I didn't bother to improve. I made a radio website and it serves from there. It can be used with an internet browser.

could it be like this?


I've lost a bit of an overview of what this is actually about and where exactly the problems are and on which Android versions they are relevant (they can occur).

As far as I have tested, streams can also be played continuously with the player component if you accept a certain buffer time and use a Foreground service (from Android 23 to prevent Doze mode).

Try this one:

I have noticed that some radio stations are temporarily unavailable (neither via the app nor via my computer (Chrome / Firefox). The app tries to connect (buffer) the radio station for 15 seconds, then it is aborted and recommended to try another.

The app can also be operated from the background and/or the locked screen. The stream shouldn't break off even in idle mode.

As I already said, since the introduction of Doze (Android 6, API 23):