> No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
You can call `contentResolver.openFileDescriptor` on a a `content://` Uri from SAF, and get a `ParcelFileDescriptor`, which can be turned into a real unix fd by calling `detach()` on it. Passing this fd into native code just works.
That's not to say that, you know, SAF is actually sane, though. `DocumentFile` lazily IPCs to some StorageProvider process every time you retrieve a property of the file (mtime, size, whatever). There are ways to speed this up by retrieving everything via the lower level `DocumentContract` API, but it definitely feels like it was poorly thought out.
That's still a one file at a time operation, right? Unless there's a way to te7a native Unix reference to the folder itself(In a way that doesn make Google unhappy and block your app), then you still need to do some fairly deep platform compatibility work or use some kind of abstraction layer.
You can call `contentResolver.openFileDescriptor` on a a `content://` Uri from SAF, and get a `ParcelFileDescriptor`, which can be turned into a real unix fd by calling `detach()` on it. Passing this fd into native code just works.
That's not to say that, you know, SAF is actually sane, though. `DocumentFile` lazily IPCs to some StorageProvider process every time you retrieve a property of the file (mtime, size, whatever). There are ways to speed this up by retrieving everything via the lower level `DocumentContract` API, but it definitely feels like it was poorly thought out.