Should this happen asynchronously?

The name implies blocking work. Thing about how would you use it: call clear then call .with.into, how would you make clear finish before checking the cache during processing the request?

I think I'm not 100% clear on the use case. If you're trying to make sure all entries are removed, there's no guarantee (asynchronous or not) that in flight requests won't still complete having loaded data from the cache after this method is called.

Can anyone share a use case or two? What's the goal of clearing the cache?

I'm still inclined to say a version number might be the best way to do this, because it would at least let you provide some guarantees (ie no request will complete with old data if you pass in an incremented disk cache version number to Glide as part of the GlideBuilder). Again though I'm not 100% clear on the use case.

I found a use case: ApplicationManifest.xml > application > @manageSpaceActivity, this attribute replaces the "Clear Data" button with a "Manage Storage" button which starts the above activity. An example I could think of is if a user needs space and sees that the app is huge, pressing "Clear Data" would wipe out all personalization/data. I know there's a "Clear Cache", but a lot of apps don't put their volatile data there for some reason. Anyway, I would put a "Clear image cache" button in my storage manager to allow freeing up space. Weirdly the API for "Clear Data" button was added in API 19, while the attribute existed since API 1...

Add an assertion that this is on a background thread (https://github.com/bumptech/glide/blob/master/library/src/main/java/com/bumptech/glide/util/Util.java#L135), and a comment that says it must be called from a background thread.