[Android Apps and Games] bubbleguuum:
First some general explanation on settings and how this all works. This can be complicated due to the number of possible scenarios.

In Android BubbleUPnP, BubbleUPnP Server bitrate settings ('Settings > Internet access with BubbleUPnP Server > WiFi/Eth max bitrate' and 'Mobile max bitrate' apply only for local music playback, eg playing to the Local Renderer. These settings are grouped in the 'Music playback transcoding to local renderer' section which attempts to make it explicit but it can be overlooked and I suppose you expected those settings to also apply to external renderers: they do not. The reason is that when this feature was implemented (transcoding to a lower bitrate), it was with local Android playback over a mobile connection in mind, where bandwidth is limited. For external renderers (a less common use case), it is assumed they have a regular high speed internet connection supporting the bandwidth required for FLAC. Admittedly, this is a broad assumption.

The UPnP tethering (named 'Advertise on LAN') setting in Android BubbleUPnP simply readvertises on the local LAN the media servers managed by BubbleUPnP Server.

So if you browse the readvertised servers from a renderer's UI (scenario 2), this is the renderer that will entirely choose which stream to play depending on its internal logic.

In scenerio 1, this is Android BubbleUPnP that has its own logic to determine which of the available stream exposed by the media server it will pick to play to the renderer.

In BubbleUPnP Server, the 'Transcode high-res audio to 44.1/16 or 48/16 FLAC' will make BubbleUPnP Server add (as first stream) a FLAC 44.1 or 48/16 transcode for browsed tracks that are high res (eg > 48 kHz or > 16 bit or multichannel or a combination of these). It was introduced some time ago because a user had the bandwidth to stream 16/44.1 (and 16/48) FLAC on its phone via LTE but not hi-res FLAC. Since this FLAC transcode stream is added server-side, the renderer can pick it up in scenario 2 (tethering) for playback.

In scenario 1, Android BubbleUPnP can also transcode to WAV or LPCM to honor 'Individual UPnP/DLNA renderer settings' or if there's no other solution for track to play (not the case here but suppose we want to play ALAC to a renderer not supporting ALAC, then transcoding to PCM kicks in).

To conclude, there is no way to force BubbleUPnP Server to add mp3 transcode streams, so currently your requirement of playing mp3 to these external renderers is not possible except... there is a third way: the BubbleUPnP Server tether client (that you run on the same network than the target renderers) provides the same tether functionality than Android BubbleUPnP except that transcoding is configurable (option -transcodeAudioMaxBitrate).

Under scenario 2, I assume the original FLAC plays. Under scenario 1 and assuming what you saw is 16/48 (and not 16/44.1) the only explanation I have is that it is Android BubbleUPnP doing the transcoding due to honoring settings in 'Individual UPnP/DLNA renderer settings' or because ReplayGain is enabled (this forces PCM).

For the phone playback, these are 'Settings > Internet access with BubbleUPnP Server' transcode settings applied.

For Chromecast playback, I must say I don't understand how it could play mp3.

What's missing I guess in Android BubbleUPnP is BubbleUPnP Server transcode settings for playback to external renderers.

https streams are not supported with BubbleUPnP Server because:

- at the time I implemented this feature (years ago, circa Android 3.0), Android APIs would have trouble with https audio streams (mostly not the case today)

- many external renderers do not support streaming via https

- https is more complicated and source of problems and failures (even for local playback on Android), especially with certificate handling and other obscure TLS failures

- https is slightly more CPU intensive as the stream must be decrypted

- I'm not entirely sure Chromecast can stream https from a server with self-signed certificates

- supporting it adds quite a bit of complexity to BubbleUPnP Server (and even Android BubbleUPnP) for (IMHO) little benefit

Long story short: using regular http for streams is simple and universally works while https is sure to cause problems. Other than that, there is no hard technical impossibility to have https streams.

No, I think I did not do it because it was more problematic to do than it looks for again very little benefit.