Low-resolution artwork URI's in notification tray on Android 13

[iTaysonLab]

Media3 Version

1.0.0-beta02

Devices that reproduce the issue

• Pixel 4a (5G) running Android 13

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

1. Play any audio file in the demo app
2. Open the notification tray

Expected result

The image is shown in normal quality

Actual result

The image is shown in low-resolution

Media

Any media file with artwork URI set in MediaMetadata, like: Album Folder > Jazz & Blues Album Folder > Youtube Audio Library Rock (2)

(The demo app is demo-session, not the main one, because it includes a background service)

Bug Report

• [X] You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[marcbaechinger]

By default and in the demo session app, the SimpleBitmapLoader is used for downloading the image and it does not scale the image but instead decodes the bitmap from the exact byte array that has been downloaded. The bitmap is then passed to SystemUI by adding it to the notification as the large icon as a Bitmap.

I'm not quite sure what SystemUI is then doing with the bitmap, but I don't think the Media3 library is doing any scaling. If you think the Media3 library can somehow improve the quality of the bitmap please let me know. It's well possible I don't see something that you want to point out some further.

[robm92]

Experiencing the same issue on both Android 12 & 13 - the image appears to be heavily compressed. Android 12 still appears to be very pixelated but it is acceptable at the thumbnail size. Android 13 has exacerbated the compression used.

I am building a MediaMetadata object with .setArtworkUri(imageUri)

Original image uri - https://media.architecturaldigest.com/photos/5890e88033bd1de9129eab0a/4:3/w_960,h_720,c_limit/Artist-Designed%20Album%20Covers%202.jpg

Android 13

Android 12

[robm92]

I have tested downloading the bitmap data myself (using COIL) and providing with .setArtworkData(imageData, MediaMetadata.PICTURE_TYPE_FRONT_COVER) This resolves the issue but is not ideal.

[marcelpallares]

I can confirm I'm facing the same issue and manually setting the image via .setArtworkData() solves it

[marcbaechinger]

System UI picks the URI/bitmap in the following precendence:

• MediaMetadata.METADATA_KEY_ALBUM_ART_URI
• MediaMetadata.METADATA_KEY_ART_URI
• MediaMetadata.METADATA_KEY_DISPLAY_ICON_URI
• MediaMetadata.METADATA_KEY_ART
• MediaMetadata.METADATA_KEY_ALBUM_ART
• Notification largeIcon

Not that URIs are only used if they have one of the following schemes: content://, file:// or android.resource://.

If the largeIcon is used, the image is scaled down which results in the pixelated background images reported here in this issue.

We think about how we can improve this with the Media3 library. We will update this issue when we have some changes regarding this.

[TStrothjohann]

Hi @marcbaechinger , I don't want to stress. But I would like to ask what you recommend. We are having the described blurry thumbnail on Android 13 in the ZEIT ONLINE Android app. Should we try to find a workaround on our side or are you expecting to deploy some fix for the issue soon? Thank you very much!

[marcbaechinger]

We are working on a solution that provides the Bitmap in an efficient way to all places where it is required on all API levels. The largeIcon being scaled down by the system that much on Android 13 caught us a bit on the wrong foot tbh. We need to redesign the internal implementation and the API for this. It's likely that we need to change the API surface for this which means that the solution for the upcoming 1.0.0 release will be an @Unstable API. We certainly hope and believe that this API will stick, but we can't officially change the API for 1.0.0 because we are already in beta.

After this lengthy comment about rather unimportant things it's no surprise that I don't have a good answer for your actual question. We are working on it. It will be part of the stable 1.0.0 release, but I can't give you a concrete timeline for this I'm afraid. It will land on the mainbranch earlier at which point we will update the issue here with the commit number.

It will be rather December than earlier to give you a conservative guess that is my own and it's based a bit on sand as of now. I'm sorry for not being able to give you a better answer.

[TStrothjohann]

Thank you Marc! I think we better live with the tiny thumbnails until December than wasting time in a hacky workaround.

[chvp]

I think this was fixed, either by platform changes or beta-03? At least I can't reproduce this anymore with the same code as I had in november.

[marcbaechinger]

Thanks for verifying! The Media3 library has been changed to dance around the issue. I'm closing.