If the URls are not stable, then your approach sounds a bit fragile, since you can't predict whether audio_service will resolve the URLs before they expire. You would be better off doing this in a more controlled manner where you obtain your perishable URLs, then preemptively download them to local files in your app's local store, and then simply pass file:// URIs into artUri.

Aside from that, I'm not comfortable with adding a field to MediaItem that isn't actually understood by the native platform, and indeed isn't included in toMessage() for that purpose. Typically non-standard fields should be included in extras but as I said above, the idea of unstable URIs just seems like it is not going to work with the way media sessions work, and the preemptive downloading approach seems safer.

The URLs don't expire, they're token based and can change because the salt used to generate them changes, or because a user changes their password, etc. I don't want to re-download the image every time in these cases and I'd like to use the cache managers I'm already using with these custom cache keys. I also don't really want to implement my own image pre-caching system outside the cache manager as it does a pretty good job of it already.

If adding a field to MediaItem isn't a good way to do it, an alternative approach I considered was to have an additional param on AudioService.init() for a cacheKeyResolver function that could take a media item and return a cache key. Would that be acceptable?

I suppose that could work. There is also "maybe" a possibility to implement a custom cache manager (although I don't have the API in front of me right now to confirm that).

That's what I'm already doing now actually, although not heavily, so I can customize the amount of time things are kept for and a few other things, and I pass that cache manager to audio_service and use it in my app to display the same images from cache with cached_network_image. There are potentially a lot of images I'm putting on a user's device so I want to avoid caching them more than once.

I'm not sure it's possible to customize the cache key resolution in the cache manager without really reworking how it's built, since it allow you to pass a cache key on your own with the URI. Other packages like cached_network_image that also rely on flutter_cache_manager allow passing the cache key when you pass the URI so I figure it'd be reasonable to allow some way to do it here too.

Understood. I suppose that the cacheKeyResolver approach could be more flexible, since if your cache key can be derived from the URI, it wouldn't require storing extra fields, but if not, you could just store your key into the extras and use cacheKeyResolver to pull it out of the extras.

I don't want to rush API design decisions, so perhaps you can also think on these options and see what you feel is going to be best taking into account all of the considerations.

Cool, I have another branch with the cacheKeyResolver function but haven't tried implementing it in my app yet, I'll give it a go and see how it feels, and then open a PR if it seems alright.

Been testing that PR in my app, and it works flawlessly.