zlacker

fopen(), fwrite(), etc. are a part of libc and as such are officially supported [1], but they become somewhat useless with SAF. (It makes sense that you'd at least have to use some Java to open a file picker and request access, but why not provide native access as well when a file is picked?)

[1] https://developer.android.com/ndk/guides/stable_apis

>>NotPra+(OP)
And they can be used the same as java.io.File, inside the application sandbox.

Other than that, it boils down to:

" - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

- Reuse your own or other developers' C or C++ libraries. "

From https://developer.android.com/ndk/guides

And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files.

>>NotPra+(OP)
Yeah, I personally think Scoped Storage on Android was a bit misdesigned and it would probably be much easier for all app developers if they (ab)used FUSE to present allowlisted directories inside app-specific mounts.

>>pjmlp+on
Those are vague examples of what the NDK could be used for, not an exhaustive list of all supported use cases. And Syncthing is really just trying to re-use their existing code on Android (example use case #2). It doesn't even require low-level syscalls, it just needs to be able to call fopen() on files which the user has explicitly granted to the app, which you'd expect would be available within the application sandbox.

> And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files

You might as well just axe the entire NDK if you're worried about unsafe code.