setArtworkUri could accept file:// and content:// Uris

[y20k]

Use case description

I develop and maintain an audio app that stores the covers for its media as files locally (in external storage). I want to use those local files as the artwork in a MediaItem.

Proposed solution

setArtworkUri in MediaMetadata.Builder could accept Uris with the scheme file:// and content://

Alternatives considered

(1) I can convert the local cover file into a ByteArray and pass that to setArtworkData. But that solution uses more memory compared to just setting that artwork Uri.
(2) setArtworkUri somewhat works with file://-Uris ... in the sense that the correct cover is displayed in the app's Notification. But MediaDataManager throws a FileNotFoundException (Permission denied). So I guess other clients of my app will not be able to see the cover.

[marcbaechinger]

Thanks!

We recently added DataSourceBitmapLoader that is able to download from content:// URIs. I think this should work with file:// URIs as well.

For proper integration we should:

1. Use DataSourceBitmapLoader in the demo app to test and showcase it in use.
2. In addition we should investigate whether we can just send artworkUris with schemes content:// and file:// to the legacy media session without downloading and converting the bitmap. The reason for this is that content:// and file:// are directly supported by SystemUI and we can avoid sending byte arrays over the binder.

[marcbaechinger]

But MediaDataManager throws a FileNotFoundException (Permission denied). So I guess other clients of my app will not be able to see the cover.

For sharing with other apps you probably need to use a content://. The other app can then use a DataSourceBitmapLoader to download the bitmap from the content URI.

[y20k]

Hi @marcbaechinger

Thank you. I will try out DataSourceBitmapLoader when it becomes available - in the next RC release I presume. That sounds like very good solution. And if in the future setArtworkUri will automagically be able to fetch artwork from local Uris, that would be great (and in my opinion intuitive). But as long as the problem can be solved by using DataSourceBitmapLoader, that totally fine, too.