Notification Image Not Updating

[Tr736]

Version

Media3 1.2.0

More version details

I am using a MediaLibrarySession and Controller.

Im wanting to update the lockscreen/notification image dynamically

This is the code I am using...

` fun updateNowPlayingMetadata(call: MethodCall, result: Result) {
val artworkUri = BundleUtils.parseMethodCall(call)?.getString("image")?.let { Uri.parse(it) }
Log.d("MediaController", "updateNowPlayingMetadata $artworkUri")

    val updatedItem = controller?.currentMediaItem?.buildUpon()?.apply {
        setMediaMetadata(MediaMetadata.Builder()
        .setArtworkUri(artworkUri)
        .build())
    }?.build()

    updatedItem?.let {
        controller?.replaceMediaItem(0, it)
        MediaItemTree.addItem(it)
    }

    result.success(null)
}`

and in my PlaybackService: MediaLibraryService

// ============================================================ // updateNotification fun updateNotification(){ Log.d("PlaybackService", "updateNotification ") onUpdateNotification(Settings.session!!, false) }

If I set the title during the update, the title changes, but the image remains the same. I've confirmed multiple times that the imageURL is changing to what I expect, but the issue is that the images don't change.

Devices that reproduce the issue

Pixel 5

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

Play a library item and notice the original image in the Lock Screen
Update the image
Notice the Lock Screen image dosnt change

Expected result

Lockscreen/ Notification Image should change

Actual result

Lockscreen / notification image remains as the initial image

Media

you can do this with any two image urls during playback

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[tianyif]

Hi @Tr736,

Thanks for reporting! For me, on Android 14, the issue was reproducible with the test controller app connecting with the demo session app.

After the artworkUri was changed at the controller, things worked fine to replace the MediaItem to the session, and session triggered onMediaMetadataChanged event. While in updateMediaMetadataIfChanged in MediaSessionLegacyStub (which is going to update the System UI notification), I found that the artworkData coming with the newMediaMetadata was not null. Thus, the default implementation of the BitmapLoader would decode the artworkData instead of loading from artworkUri.

In fact, this artworkData is coming from the media itself. The ApicFrame got decoded and populated to the MediaMetadata. When the ExoPlayer updates the playbackInfo, it will build a MediaMetadata based on the metadata from the media and the metadata from the MediaItem. The strategy is, the metadata from the MediaItem will be prioritized, as long as they are non-null.

The MediaItem I have was not set with artworkData, thus the artworkData was filled with the data from the ApicFrame. This probably be your situation as well I assume? Actually this means that when you have a MediaItem with only artworkUri set, which corresponds to bitmap A, yet in the presence of the artworkData from the media which corresponds to bitmap B, you won't see the bitmap A showing on the notification, without needing to go through the replaceMediaItem step.

This is a bug that we should fix our side. I'm not sure if your app mostly uses artworkUri as the bitmap information for the session, if yes, as a temporary mitigation step, you can customize you BitmapLoader by overriding this method with prioritizing the loading from artworkUri.

We will provide a solution to this and update this issue. Thanks for reporting this bug!