As always, this is the same behavior as Android... But I think this is a very good point and we want some consideration.

In Android, downloaded files are usually saved at /sdcard/Download directory, not at its subdirectories, because Android users don't care about real file system structure. However, in Chrome OS, directories are a useful tool for users to organize their files, and especially since Downloads is the only local folder in Chrome OS, it is typical that users create subdirectories under Downloads.

My suggestion is to put all files under Downloads (including its subdirectories) into single "Download" view (e.g. Downloads/a/b/c.jpg -> Images/c.jpg). Though replicating the original folder hierarchy would work as well (e.g. Downloads/a/b/c.jpg -> Images/Downloads/a/b/c.jpg), I think keeping the hierarchy flat as far as possible would make it more like media "view".

Also, in order to keep consistency between Chrome OS and Android UI, this would be done in Android media provider side.

Weifang, WDYT?

Oops, I have a correction:

Flattened example: Downloads/a/b/c.jpg -> Images/Download/c.jpg
Hierarchical example: Downloads/a/b/c.jpg -> Images/Download/a/b/c.jpg

I looked at Android MediaProvider code. In MediaProvider, every media file tracked by it has an entry in its sqlite database, and an entry has BUCKET_DISPLAY_NAME column which holds its parent directory name (e.g. Downloads/a/b/c.jpg -> "b"). The column is used to decide which virtual folder a media file appear in media documents providers.

If we want to change the virtual folder name in media documents providers, an ad-hoc way is to leave the column as-is and rewrite the values on the fly when entries are queried. However this is very tricky since apps can query media entries filtered with specific BUCKET_DISPLAY_NAME value. It is very tricky to handle such queries correctly while rewriting the values on the fly, and also it will be very inefficient and impacts performance.

A promising way is to change the way to compute BUCKET_DISPLAY_NAME column values and update the sqlite database. Changing the schema requires incrementing sqlite database version number which is expected to increase monotonically and one can determine the database schema from the version number alone. For this reason it is difficult to change the schema only for ARC++ due to version number conflicts and correct schema updates.

So if we were to make this change, the ideal way is to submit the change to AOSP ToT, and then cherry-pick to ARC++ branch. But I guess it would be a bit controversial to treat Download directory specially in all Android devices and may take some time to get agreements. WDYT?

Assigning to weifangsun@ for product decisions.

Merging this into  crbug.com/749924  as I believe the correct solution is to flatten the Media Views.