So C++ applications on Android that wish to use Skia, do have to use the Java API via JNI (android.graphics.Canvas) with the respective performance impact due to marshaling, or package their own Skia version, thus increasing their APK size and having to deal with a build system that only makes sense for Google employees.
Everything else should be done at Java level.
I understand from the point of view of security, but what is safer, provide bindings to libraries already validated and installed on the device or forcing devs to package something else?
Also even though they implement native APIs in nice C++ with RAII and stuff, it gets exposed as unsafe C APIs, so the security story isn't 100% correct.
And in any case, creating a 2D abstraction layer stable API on top of platforms specific version APIs, specially given that all NDK APIs are C based even if written in C++, it is not rocket science, rather a matter of wanting to do it.
It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries. They're a bit bigger (may God provide mercy, and huge amounts of free diskspace to those fools that enable debug), but the odds of them working flawless on a given device are much higher.
You lost me there. I wouldn't call JNI boilerplate a C API.
> It is quite normal and traditional though, for C/C++ developers to work with what they call statically built binaries.
Polyglot dev here, including C and C++.
The way a library is linked is orthogonal to be made available on the SDK.