Use case description

My app allows users to download tracks, one at a time, via a queue backed up by ExoPlayer's DownloadManager. It features a screen with a list of all ongoing downloads. Each entry has a button which the user can click to send the download up the list, making it the active one (no concurrency in this case). To try to make it so DownloadManager re-prioritizes clicked downloads, my plan was to remove all others added prior and then add the clicked one back, and re-add all others back. Unfortunately it seems that this ends up in DownloadManager marking downloads to be removed and then undoing so very quickly, often resulting in wrong behavior.

Proposed solution

A new public method on DownloadManager, setDownloadPriority, taking a request id and an int representing a priority, so that download manager always attempts to be downloading the requests with the highest priority, up to the concurrency limit.

Alternative solutions

• Using different request ids. This will work, but it will waste progress on de-prioritized items, which is undesirable.
• Separately manage my own queue for full flexibility and have DownloadManager handle truly only ongoing requests, so that DownloadManager only needs to be made aware of "real changes". This will work too, but it feels counterintuitive to have a class like DownloadManager, with thread safety constructs and APIs to handle multiple items, require this additional work on top.