Yes, you'll need a little bridge to get a ParcelFileDescriptor. Lots of stuff in Android does not work directly with native code (Permissions, Camera/Media recording, HttpURLConnection, sensors/location services, ...), and storage access is now sandboxed in a similar way and needs a few lines of Java/Kotlin. I fully see that this is annoying, and Android is tiring developers with constant changes like these, but on the other hand, I guess most people would agree that securing storage access is a good thing.
It would not be much effort at all for google to make native hooks into these APIs. Certainly less effort than dealing with constant complaints from developers. It feels like they're trying to force lock-in.
With file access, the sensible solution would have been of course to just overlay the permissions onto the regular files API (like I think every other sandboxing solution does), so everything that uses files could keep working as usual and you'd just have to add some limited code to request the appropriate permissions [1], but I guess that would have been too sensible, and when all you've got is a SAF, everything looks like a nail or something…
From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that, doubly so when you're using a library that expects regular files, plus performance is somewhat lacking, too (judging from complaints and bug reports I've seen, both in that it is easy to run into performance pitfalls, but also that even best-case performance is still worse than classic file access).
> From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that
That pretty much matches my experience. Single file picker flows can often be implemented with a simple callback.
But for folders it falls apart.
Thanks for mentioning scoped storage. Maybe that provides some sort of solution. I vaguely remember when I was first dealing with this circa 2021 that they had some sort of a low-performance solution that was supposed to work for NDK code.
