I'm starting my first piece of Android programming, porting some libraries written in C and C++ to Android. I am not building an app, except for testing the libraries: the product is the libraries, which will be supplied to my customers. The libraries are mathematical modelling, running on the device, and have no web or cloud interfaces: customers who want to run them in the cloud already do that, using the Linux or Windows builds.
My initial customer is using NDK 14b. I could use that, or I could use the latest NDK, 16b. If I compile C code with NDK 16b, a compatible instruction set and the same C++ run-time and target API version as my customer, will they be able to use static libraries that I've built in their NDK 14b app?
The other way around is also interesting: if I use NDK 14b, and another customer comes along who uses NDK 16b, will static libraries I've built with 14b work in their 16b-built app? I'd be targeting an equal or earlier API to them, and the same instruction set and C++ run-time.
Addendum, much later: Building .so libraries turned out to be so easy that I've never used anything else.
You kindof cannot target the same C++ runtime when you use a different NDK release. The STL versions do not change too much, but there is no contract of their stability.
Except from this remark, static lib from NDK r16 will cooperate correctly with r14 and vice versa, but the bigger the gap is, the more glitches you should expect to handle.
In general, NDK improvements involve bug fixing, so there is an incentive to use the latest release. But major progress is done in support of newer platform versions. This means that if your library will be linked into an app that targets Lollipop, the advantages of r16 will be less prominent.
Note that if you can ship your library as a linked shared library (so), your interdependency with the host app will be significantly less, and in my experience this improves stability and reduces clashes. If that is relevant, this way is also more secure.