This is not only WebView's issue, Chrome for Android has the same issue, so removing WebView component. While FireFox for Android does work as reporter expected.

From the spec, https://html.spec.whatwg.org/multipage/media.html#attr-media-preload

> The preload attribute is intended to provide a hint to the user agent about what the author thinks will lead to the best user experience. The attribute may be ignored altogether, for example based on explicit user preferences or based on the available connectivity.

From MDN https://developer.mozilla.org/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Cross-browser_audio_basics

> Note: This value (preload) is often ignored on mobile platforms.

So Chrome for Android and Android WebView may not support this while Chrome desktop does support it. Even Chrome desktop with mobile mode (via devtools) doesn't support this.

Tentatively add component internals>media, please help to triage, thanks!

In the past when this fails it's due to the server sending a different content-length upon resume and Chrome can't ensure the new data belongs with the old stream. 

=>hubbe who's looked into these in the past.

On playing/resuming if the content-length changes chrome should be able to refresh the metadata and resume playing the stream on it's own, provided the stream url isn't broken. It could identify the stream with the url and not wholly rely on metadata as it may vary as stations constantly upload new tracks.
Also there could be a tag that displays metadata info without the need for unnecessary javascript.

I tried this on desktop, but the provided URL doesn't seem to work for some reason. However, if I isolate one of the <audio> tags, I can sort of see what the problem is.

With preload=metadata, the <audio> tag tries to load a little bit of data from the stream to see what kind of stream it is. However, it noticed that the stream is not seekable, so it tries to keep it open so that it can resume loading when you press play.

Eventually, the connection gets closed anyways, and when you press play, you only get the preloaded part.

Using preload=none solves many of these issues, as the audio tag won't try to open the source at all.

Chrome could probably do a better job of supporting these kind of always-changing media resources, but an MSE based solution will always work better I think.

AFAIK, preload=none is the right workaround for this case, and so I don't think there is anything to do here.

Preload=none doesn't solve the problem and isn't a valid workaround as the
play button needs to be tapped at least 2-3 times in order for it to start
playing.
On the first tap, it loads the metadata and only after it loads the
metadata the play button will respond. Quite a frustrating experience.
It feels as if the stream is broken and the end user navigates away from
the player.

On Sat, Dec 1, 2018, 6:00 AM hu… via monorail <
monorail+v2.1990096764@chromium.org wrote:

I tried the URL given in chrome on android, which seems to behave the same as chrome on my desktop. Some radio stations get a skip after a few seconds, some fail and has to be re-started by pressing the play button.

None of them needed to be pushed more than twice. There may be a second problem here that is also causing problems for you, but I'm reasonably certain that preload=none is going to work better than any other form of preload for this particular use case, so I would recommend updating the app (and the HTML page) to use preload=none if possible.