5 ms·

The article finishes by asking: Would it really be so bad to include libsqlite in the NDK? Good question! Why is the NDK so underpowered? Why are they so reluc

The article finishes by asking: Would it really be so bad to include libsqlite in the NDK? Good question! Why is the NDK so underpowered? Why are they so reluctant (or unable) to publish some useful, stable native APIs? It's missing things like curl, sqlite, icu, OpenSSL. Most of these are built into the OS but not accessible via the NDK. (OpenSSL isn't a great library, I know, but it's patchable. And they could start now with something better.) The only useful native third-party libraries you get are: zlib, OpenGL ES, OpenSL ES. Apart from that, there are a bunch of wrappers for a small subset of Java APIs (AssetManager, Bitmap and so on). These are tedious to use, and seem to have been written by hand so in some cases they're buggy -- for example, incorrect string handling in AStorageManager: https://code.google.com/p/android/issues/detail?id=41983 https://code.google.com/p/android/issues/detail?id=41983

ndesaulniers 10y ago
Then they have to maintain those versions of those libs forever. Most devices don't have enough storage space for 9 copies of the past major versions of all of these libs.
- iainmerrick 10y ago
  Well, that's the importance of stable APIs. You only need a new copy on major revisions, which are rare. libcurl, for example, claims to have had a stable API and ABI since 2006 (https://curl.haxx.se/libcurl/features.html#stableapi https://curl.haxx.se/libcurl/features.html#stableapi). Why do we only get zlib? I bet many Android devices already have at least 9 copies of sqlite, since so many apps ship their own copy.
izacus 10y ago
Most likely Google (and OEMs) want to keep the flexibility of changing implementations without having to code and patch those libraries you listed forever. NDK team doesn't look like it's expansive or prioritized at all, so I doubt they have resources or will to do that. TBH I'd rather they focus at improving the tooling and debugging, we can ship our own libraries with our own options compiled in. Heck even on iOS we have to ship a custom SQLite to get all the needed capability.
- corysama 10y ago
  Can anybody speak to the current size of the NDK team? I met with one of them many years ago when the team had only two (2) full-time engineers. Google has one of the largest software engineering populations of any company in the world. It supports one of the largest developer ecosystems in the world. Games are the largest catagory in their ecosystem. 2 engineers supporting the NDK...
  - iainmerrick 10y ago
    Yeah, that's exactly what I was getting at. They don't seem to take the NDK seriously. It's very weird.
    - pjmlp 10y ago
      It is not weird if you think they would rather not have it at all. It wasn't there until 2.2, only got added due to community pressure and they always did the minimum amount of work. When the migration to Android Studio was announced, we got left with no migration plan. Only after JET Brains announced CLion, almost 2 years later, did they announce the migration to Studio. Likewise they moved into Gradle without plan for C NDK support and it took three generations of build tools until they decided to settle on CMake.
      - iainmerrick 10y ago
        Yes! But why? As an earlier commenter mentioned, games are one of the biggest app categories and many games rely on the NDK. Pro audio could be another big category, but I think Apple has the market sewn up there because Android is still way behind.
        pjmlp 10y ago
        I guess, because a few key figures come from Sun's Java team and WebOS, with politics having a big role.
  - 10y ago
pjmlp 10y ago
On top of that lets not forget that libraries like Skia are only exposed via Java. So anyone that wants 2D graphics from NDK side either needs to call into Java, or bring their own library on top of OpenGL. And the whole mismanaged way how the C++ IDE and build system migration was handled.
- iainmerrick 10y ago
  I'm not sure Skia has a sufficiently stable API. And graphics are actually an OK case -- OpenGL ES is the key API here, and it's provided. What you want is stable APIs for things that interact in fiddly ways with the rest of the system, so they're more easily managed at the OS level. Networking, shared databases. (Edit to add: localization) zlib is nice to have, but it's also really portable and lightweight. It would be easy for apps to bundle their own copies. Something like libcurl is a lot more awkward (what do you use for https? bundle your own SSL too!)
  - pjmlp 10y ago
    Using a 2D library with canvas operations is not the same as rendering triangles. In any case that was just an example. Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.
    - iainmerrick 10y ago
      Agreed. Even if you don't need a whole 2D library, it would be very useful to have a stable API for reading the system fonts, so apps don't have to ship their own.
    - vetinari 10y ago
      Because Android's OS APIs are in Java for a reason. Yes, if you insist on using C++ with the OS APIs, you are pushing a square peg into a round hole, so enjoy JNI.
      - pjmlp 10y ago

ndesaulniers 10y ago

Then they have to maintain those versions of those libs forever. Most devices don't have enough storage space for 9 copies of the past major versions of all of these libs.

iainmerrick 10y ago
Well, that's the importance of stable APIs. You only need a new copy on major revisions, which are rare. libcurl, for example, claims to have had a stable API and ABI since 2006 (https://curl.haxx.se/libcurl/features.html#stableapi https://curl.haxx.se/libcurl/features.html#stableapi). Why do we only get zlib? I bet many Android devices already have at least 9 copies of sqlite, since so many apps ship their own copy.

izacus 10y ago

Most likely Google (and OEMs) want to keep the flexibility of changing implementations without having to code and patch those libraries you listed forever. NDK team doesn't look like it's expansive or prioritized at all, so I doubt they have resources or will to do that. TBH I'd rather they focus at improving the tooling and debugging, we can ship our own libraries with our own options compiled in. Heck even on iOS we have to ship a custom SQLite to get all the needed capability.

corysama 10y ago
Can anybody speak to the current size of the NDK team? I met with one of them many years ago when the team had only two (2) full-time engineers. Google has one of the largest software engineering populations of any company in the world. It supports one of the largest developer ecosystems in the world. Games are the largest catagory in their ecosystem. 2 engineers supporting the NDK...
- iainmerrick 10y ago
  Yeah, that's exactly what I was getting at. They don't seem to take the NDK seriously. It's very weird.
  - pjmlp 10y ago
    It is not weird if you think they would rather not have it at all. It wasn't there until 2.2, only got added due to community pressure and they always did the minimum amount of work. When the migration to Android Studio was announced, we got left with no migration plan. Only after JET Brains announced CLion, almost 2 years later, did they announce the migration to Studio. Likewise they moved into Gradle without plan for C NDK support and it took three generations of build tools until they decided to settle on CMake.
    - iainmerrick 10y ago
      Yes! But why? As an earlier commenter mentioned, games are one of the biggest app categories and many games rely on the NDK. Pro audio could be another big category, but I think Apple has the market sewn up there because Android is still way behind.
      - pjmlp 10y ago
        I guess, because a few key figures come from Sun's Java team and WebOS, with politics having a big role.
- 10y ago

pjmlp 10y ago

On top of that lets not forget that libraries like Skia are only exposed via Java. So anyone that wants 2D graphics from NDK side either needs to call into Java, or bring their own library on top of OpenGL. And the whole mismanaged way how the C++ IDE and build system migration was handled.

iainmerrick 10y ago
I'm not sure Skia has a sufficiently stable API. And graphics are actually an OK case -- OpenGL ES is the key API here, and it's provided. What you want is stable APIs for things that interact in fiddly ways with the rest of the system, so they're more easily managed at the OS level. Networking, shared databases. (Edit to add: localization) zlib is nice to have, but it's also really portable and lightweight. It would be easy for apps to bundle their own copies. Something like libcurl is a lot more awkward (what do you use for https? bundle your own SSL too!)
- pjmlp 10y ago
  Using a 2D library with canvas operations is not the same as rendering triangles. In any case that was just an example. Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.
  - iainmerrick 10y ago
    Agreed. Even if you don't need a whole 2D library, it would be very useful to have a stable API for reading the system fonts, so apps don't have to ship their own.
  - vetinari 10y ago
    Because Android's OS APIs are in Java for a reason. Yes, if you insist on using C++ with the OS APIs, you are pushing a square peg into a round hole, so enjoy JNI.
    - pjmlp 10y ago