> 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.
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.