4

If I call DocumentFile.fromTreeUri() on main directory and I list its content, it returns all DocumentFile object related to folders and files contained in the directory as expected, but when I try to call DocumentFile.fromTreeUri() on the Uri of one of the DocumentFile folders inside it, rather than returning all DocumentFile objects related to folders and files contained in the subdirectory as expected, it actually returns exactly the same content of the call on its root Uri

E.g. I have a Download folder with 3 files and a subfolder with 2 files contained in it structured in this way

Download
-->file1
-->file2
-->file3
-->Subfolder
----->subfile1
----->subfile2

If I call DocumentFile.fromTreeUri().listFiles() on the Download folder Uri picked through intent callback content://com.android.externalstorage.documents/tree/primary%3ADownload It returns me

-->file1
-->file2
-->file3
-->Subfolder

Till now all it's ok, now if I try to get Uri of DocumentFile object related to Subfoldercalling mysub.getUri() I get content://com.android.externalstorage.documents/tree/primary%3ADownload/document/primary%3ADownload%2FSubfolder that apparently would seem correct, but If I call DocumentFile.fromTreeUri().listFiles()on it, when I list its content I get again

-->file1
-->file2
-->file3
-->Subfolder

Exactly as the call on the main Download folder Uri. The same happens if I call mysub.listFiles() directly. This seems a totally illogical design.

How could I actually get correctly the DocumentFile objects related to Subfolder from DocumentFile related to its parent in order that Subfolder DocumentFile can list its content rather than content of its parent?

AndreaF
  • 11,975
  • 27
  • 102
  • 168
  • "calling mysub.getUri()" -- rather than getting the `Uri`, then re-wrapping it in a `DocumentFile`, try calling `listFiles()` on `mysub`. – CommonsWare Jun 14 '20 at 17:13
  • @CommonsWare This is an horrible design that can lead to a lot of problems. Is there a way to check if an `Uri` will be treated as current `DocumentFile` `Uri` or as "its dad" `Uri`? – AndreaF Jun 14 '20 at 17:47
  • "This is an horrible design that can lead to a lot of problems" -- I cannot argue with that. "Is there a way to check if an Uri will be treated as current DocumentFile Uri or as "its dad" Uri?" -- I do not know what you mean by that. A tree has two `Uri` values, one for itself (`buildTreeDocumentUri()` on `DocumentsContract`) and one representing the collection of children (`buildChildDocumentsUri()` on `DocumentsContract`). I think `isTreeUri()` on `DocumentsContract` will distinguish between them, though I am not certain. – CommonsWare Jun 14 '20 at 17:54
  • @CommonsWare However I have tried to call listFiles on mysub as suggested in your first comment and problem remains exactly the same: even `mysub.listFiles() ` returns files of the root. – AndreaF Jun 14 '20 at 20:06
  • Sorry, but I haven't had a need to try traversing a document tree (going into sub-trees), so I'm just trying to point out known problems. Given [the limitations of `listFiles()`](https://commonsware.com/blog/2019/12/14/scoped-storage-stories-listfiles-woe.html), you may be better served working with `DocumentsContract` for your tree traversal. Also, you might check out https://stackoverflow.com/q/47366768/115145 and https://stackoverflow.com/q/41096332/115145. – CommonsWare Jun 14 '20 at 20:18
  • @CommonsWare `DocumentContract` seems another complicated mess. Not sure how I can migrate all without another hell of issues. Anyway I have seen that `DocumentFile` method `listFiles()` under the hood uses exactly `DocumentContract` method `buildChildDocumentsUriUsingTree`, so likely I will have same issue even with `DocumentContract`. Such method apparently seems meant to give childs, it seems too senseless I actually get the root content. I'm starting to have the doubt there is some serious bug in the SAF itself. – AndreaF Jun 14 '20 at 20:32

1 Answers1

9

I have the same problem. I solved it after upgrading the documentfile version.

implementation 'androidx.documentfile:documentfile:1.0.1'

sowhat
  • 131
  • 1
  • 6
  • 3
    This works! But why is this "new" DocumentFile dependency not being automatically rolled into whatever androidx library it's a part of? This bug was fixed in February 2019 so what gives? https://developer.android.com/jetpack/androidx/releases/documentfile#1.0.1 – Gavin Wright Sep 16 '21 at 07:30
  • Thanks for this. In my case it was androix.appcompat 1.4.1 that was including the 1.0.0 dependency. – nmw Feb 17 '22 at 13:51