Opening a directory via ACTION_VIEW with a content:// URI (e.g. from DiskUsage) shows raw "java.lang.UnsupportedOperationException"

Steps to reproduce

1. Install DiskUsage (com.google.android.diskusage).
2. Scan a storage, tap a directory, and press "Show" in the menu.
3. Choose Material Files in the chooser.

Expected behavior

Either the directory opens, or a clear error message is shown.

Actual behavior

Material Files opens on an empty list and displays the raw exception string "java.lang.UnsupportedOperationException" as the error text (and subtitle "Error" in the toolbar).

Cause

DiskUsage sends ACTION_VIEW with mime type inode/directory and a content:// URI produced by its own androidx FileProvider (content://com.google.android.diskusage.provider/root/...). Material Files matches this intent (AndroidManifest.xml declares VIEW + DEFAULT + inode/directory), converts the data URI into a ContentPath via Intent.extraPath → Paths.get(URI), and then fails when listing it:

• FileListLiveData.loadValue() calls path.newDirectoryStream()
• ContentFileSystemProvider.newDirectoryStream() unconditionally throws UnsupportedOperationException() (content URIs cannot be listed as directories)
• FileListFragment.onFileListChanged() displays throwable.toString(), hence the raw "java.lang.UnsupportedOperationException".

Suggested improvement

Since a content:// URI from an arbitrary FileProvider can never be listed as a directory, Material Files could detect this case (e.g. ContentPath with a directory MIME type in the VIEW intent) and show a user-friendly message such as "This location cannot be browsed" instead of the raw exception. The functional fix arguably belongs in DiskUsage (sending a file:// URI for directories), but the current error message is confusing.

Update: a fix has been submitted on the DiskUsage side: https://github.com/WhiredPlanck/diskusage/pull/2

Start with FileListLiveData.loadValue(), ContentFileSystemProvider.newDirectoryStream(), and FileListFragment.onFileListChanged(), following the ACTION_VIEW path described in the issue. Verify how directory content:// URIs reach the listing code and how the resulting error is displayed. Done means the case produces a clear user-facing message rather than the raw exception; the functional URI fix is being pursued in DiskUsage.