Unify cover art sources in a configurable manner
@tianyif is already working on this.
Since May 20, 2024.
- Dominant language
- Java
- Stars
- 3k
- Forks
- 955
- Avg merge
- 12d 14h
- Merged PRs (30d)
- 2
Description
[REQUIRED] Use case description
My app has two sources of cover art. It has a Coil setup with a bunch of extensions/settings options that would ideally be provided by BitmapLoader, and just plain MediaStore URIs stored in MediaItems. However, It seems as if ExoPlayer seemingly erratically uses three different cover art sources depending on what's being applied.
- The
MediaSessionCompatcover metadata is directly read from theMediaMetadata.artworkUriorMediaMetadata.artworkDataof aMediaItem, judging by this code. This is not configurable. - The media notification reads from
BitmapLoader, which can be configurable. - Since ExoPlayer does auto-parse metadata, it's also possible for cover art data extracted from there to be used as well. I don't know when this is triggered and it's not configurable from what I know.
This leads to several issues.
- There is no way to definitely ensure that album covers are being loaded through your own source of data, such as Glide/Coil.
BitmapLoaderwill only apply to the notification, not theMediaSessionCompat. - If the sources of cover data differ for whatever reason between the notification and session, the media notification will begin to behave erratically from Android 11 onwards, often picking random covers. This makes it impossible to even use
BitmapLoaderin it's current form, since you have no idea if it's going to randomly pick some other cover source.
Please correct me if I don't fully understand the behavior or reasoning here.
Proposed solution
Make updates to the covers in media notification, MediaSessionCompat, and other places rely on a synchronized call to BitmapLoader that allows full configuration on what cover data should be used. The only place this can be excluded is anything related to the MediaBrowser, since I know that's a little infeasible.
Alternatives considered
I can somewhat alleviate this on my end by unifying my cover sources with my own internal URI-based system, but this is extremely complicated and I can't do this right now. It also doesn't rule out the case of ExoPlayer auto-parsing it's own metadata and overriding mine, since I don't know what conditions trigger that.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.