Android MediaItem is not updating on car display through bluetooth

[bypass112]

Documented behaviour

Broadcasting state changes
Your audio handler must broadcast state changes so that the system notification and smart watches (etc) know what state to display. Your app's Flutter UI may also listen to these state changes so that it knows what state to display. Thus, the audio handler provides a single source of truth for your audio state to all clients.

Broadcast the current media item:
class MyAudioHandler extends BaseAudioHandler ... {
...
mediaItem.add(item1);
...

Actual behaviour

While having an Android connected to the car Bluetooth media, the current MediaItem metadata won't update if the phone screen is turned off and if the player is connected to an ICY stream.
The metadata will update after interacting with the Android notification, or car controlls, but not on itself.
On the iOS side this works fine and also while having the Android connected to a smartwatch, or an Android device with the screen on.

Minimal reproduction project

Official example: main.dart

Reproduction steps

1. Connect with any Android device through Bluetooth to any car display
2. Play an ICY enabled stream like https://listen.radioking.com/radio/350731/stream/399784
3. Turn off the Android display.
4. Wait for the song / metadata title to change
5. The car screen won't update it's display but the MediaItem is updated in the Android system.

Output of flutter doctor

[√] Flutter (Channel stable, 2.10.1, on Microsoft Windows [Version 10.0.19044.1566], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
[√] Chrome - develop for the web
[!] Visual Studio - develop for Windows (Visual Studio Community 2017 15.9.21)
    X Visual Studio 2019 or later is required.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components
[√] Android Studio (version 2020.3)
[√] Connected device (4 available)
[√] HTTP Host Availability

! Doctor found issues in 1 category.

Devices exhibiting the bug

All versions of Android with api level >= 28.

[ryanheise]

Broadcasting state changes
Your audio handler must broadcast state changes so that the system notification and smart watches (etc) know what state to display. Your app's Flutter UI may also listen to these state changes so that it knows what state to display. Thus, the audio handler provides a single source of truth for your audio state to all clients.

Yes, but this doesn't say anything about icy metadata. There is in fact no notion of icy metadata within this plugin, there is only MediaItem data, the use of which is to be decided by the app itself. If you want to put Icy metadata into that object, you can do that, for example via the MediaItem.title field. The main.dart example certainly does not intend to do that, so your minimal reproduction project does not in fact reproduce any bug.

If you want to keep this issue open, you will need to provide an actual minimal reproduction project and describe specifically which "audio_service" API isn't working. For example, is it MediaItem.title that isn't working? That would be an example of an actual audio_service API (whereas ICY metadata is not, that's application-specific data which you could at your own choice plug into one of the fields in MediaItem)

[bypass112]

Hello, thanks for the quick reply, I'll provide a minimal repro project in the next hours.
As a sidenote how the code is implemented:

1. There is a just_audio icyMetadataStream that listents to the ICY and calls the audio_service mediaItem.add for the updated MediaItem.
2. The app and any Bluetooth device updates the display info based on the first step.
   The issue it seems that the Android bluetooth doesn't transfer the metadata further to the car display if the Android screen is locked/ the Android device is in sleep mode.

[ryanheise]

I think for a "minimal" reproduction project, you don't actually need ICY metadata because audio_service is ignorant of what the data means. If the API that's failing is MediaItem.title, you just need to write an example that attempts to broadcast a new title (e.g. changing the title from "a" to "b") and shows it not actually updating on the car display.

[bypass112]

Hello, I've published a repo: https://github.com/bypass112/audio_service_bt
It's modified from the example https://github.com/ryanheise/audio_service/tree/minor/audio_service/example
In the main.dart it has a method: _autoIncrementTitleName that generates new titles like: title_1, title_2, title_3 and so on.
I've tested this on the car display though Bluetooth and it is still not updating if the Android device has it's screen turned off.

[ryanheise]

Maybe this a more widespread bug in Android Auto? It seems to be happening even in Spotify:

https://support.google.com/androidauto/thread/100067522/spotify-changes-song-but-does-not-update-the-title-or-album-on-screen?hl=en-gb
https://community.spotify.com/t5/Android/AndroidAuto-App-not-updating-current-song-playing/td-p/4864334

[bypass112]

Yes, Spotify seems to had this problem: https://community.spotify.com/t5/Ongoing-Issues/Wrong-metadata-displayed-on-car-radio-via-Bluetooth/idi-p/5154639#comments
But I don't think the problem is on the Android Auto stack, but on the Bluetooth stack of the phone.
I tested this with Spotify:

• with a Bluetooth connection the info is displayed properly with the Android phone screen turned off
• through Android Auto the info is also displayed properly with the Android phone screen turned off

Maybe the Smartwatch display works fine because the phone isn't sending extra info through the Bluetooth audio channel? Something else I've noticed is that when the phone is locked the car commands Play/Pause have a delay compared to when the phone isn't locked. Maybe the phone is deciding to reduce the priority/bandwidth of the Bluetooth connection?

[ryanheise]

If it's in Android, that doesn't bode well for fixing this. Android bugs reported to Google can take years before they're addressed, if ever. I think the best shot will be to try to find an open source Android app that has the desired behaviour (e.g. if it has some workaround we don't know about), and then emulate what it does.