Dave owns this now.

We open the downloaded file in direct response to a user request, so we made an intentional decision to allow the strict mode violation rather than queue up an AsyncTask. If we queue a task, the file will open at some unspecified point in the future rather than immediately.

This is documented in the DownloadUtils#getUriForItem():

// #getContentUriFromFile causes a disk read when it calls into FileProvider#getUriForFile.
// Obtaining a content URI is on the critical path for creating a share intent after the
// user taps on the share button, so even if we were to run this method on a background
// thread we would have to wait. As it depends on user-selected items, we cannot
// know/preload which URIs we need until the user presses share.

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot