Google does not seem interested in making the NDK anything more than implementing Java native methods, 3D graphics, audio or porting code from other platforms.

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.

Java APIs ARE C APIs, for obvious reasons. There doesn't have to be any difference in security.

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.

> Java APIs ARE C APIs,

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.

Skia does not have a stable ABI, which is a requirement for inclusion in the NDK: https://github.com/google/skia/blob/master/experimental/c-ap...

It has a stable API for Java clients on Android, if Google actually would care they could expose that one.

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.