AsyncTask's get() function, when called from a UI thread, blocks the UI on a lower priority thread (right now, it's being block on a BACKGROUND priority thread, which is very low priority).

After auditing some of the get() callsites, they appear to be sensible locations to call get(), and a refactor to move them off get() might be difficult. Specifically, they tend to be places where a resource will be needed "soon-ish" and so the resource is warmed up on an AsyncTask. Eventually, the resource is actually needed, so they call get(), and the majority of the time the get() returns instantly. However, in the case where the AsyncTask hasn't already returned, it then blocks.

We have two possible solutions, which could both be implemented:
1) Calling get() tries to cancel the task if it is not in progress and runs it on the UI thread
2) Calling get() raised the priority of the thread the task is running on

One issue with these solutions is serial execution - if we call get on a task that is in a serial executor, we have to ensure we boost all tasks that are ahead of it in the queue.