Not to diminish the fine work that CrystaX does, but I want to emphasise to the community that the CrystaX NDK != the Android NDK. Configuring build support specific to the Android NDK is straightforward if not well documented: if necessary to your Jamfile you add config for target-os=android as this is a cross compilation scenario. Similarly, when building Boost to target Android you pass target-os=android to b2.
Yes, building Boost libraries with Google's Android NDK is straightforward, but just build libraries is not enough; it's good to have them _work_, not just _build_. Some Boost libraries are working good being built with Google's NDK, some not. And this is main difference between CrystaX NDK and Google's Android NDK - we're going to make _all_ Boost libraries work on Android, and the only way to do that is to use own NDK, because it impossible to do with Google's one. I'll describe it more detailed below.
I'll also add some of my own experiences as I formalised the port of Thread to Android, plus AFIO v1.3 is now regularly CI tested on Android. Firstly, the STL default configured by the Android NDK is woefully defective, however the good news is that the recent NDKs can be asked to use libc++ and that's a very recent edition of libc++, so you get excellent C++ 14 STL support.
To be more specific: Google's Android NDK offer several implementations of C++ Standard Library - system (default), stlport, gnustl, libc++ (I'm naming them here as they are named in Google's NDK). Default one (system) is not actually real implementation - it only contains implementation of operator new; nothing more. stlport - well known STL implementation working on multiple platforms. However, it's a) not full C++ Standard Library implementation and b) it doesn't support C++11/C++14. gnustl - it's GNU libstdc++ from GCC upstream with Google's modifications. Even though it is GCC's implementation of C++ Standard Library, don't expect good C++ support from it - mainly because of defective Android libc implementation. On build stage, GNU libstdc++ configure scripts detect many things supported on target platform and, since many of them are not supported on Android, many C++ Standard Library features are become disabled. For example, you will not get std::stol, std::stoul etc - they are just not available in Google's gnustl. So it's not full implementation too. Another problem is std::chrono::monotonic_clock - do you know it's actually std::chrono::system_clock? I.e. you will not get any compiler/linker error - it just will not work properly. There are huge number of such problems, and all of them caused by defective Android libc implementation. libc++ - it's LLVM libc++ from LLVM upstream with Google's modifications. In contrast with GNU libstdc++, it implemented even worse. It doesn't test features available on target platform on build stage, so Google's guys modified it much more than they did in GNU libstdc++. Unfortunately, all modifications lead to "get it built", not to "get it working". Thus, it's in "experimental" state in Google's NDK, and very unstable, crashing very frequently on real usage. Again, this happens because of bad Android libc implementation. Now, what we did in CrystaX NDK to solve those problems. We have implemented big part of libc required by C standard in additional library libcrystax.so, which is added transparently to the link process _before_ Android libc, thus getting overridden buggy and non-implemented functions from Android libc. We've also significantly modified sysroot headers, making them much more POSIX-conforming than original. That allowed us to make GNU libstdc++ implementation _full_. We've paid special attention to that, fixing all things it expected from libc but not detecting on target platform. So using CrystaX NDK you'll get _actually_ full C++ Standard Library implementation, not _nominally_, as it is in Google's NDK. BTW, we've made this library 'default' in CrystaX NDK instead of defective 'system'. Second, we throw away Google's modifications of LLVM libc++ and using upstream LLVM libc++ with slight modifications, allowing use it with gcc, not only with clang. Again, this made it _much_ more stable, since we touched it minimally, preferring to fix underlying layer to fulfill standards rather than fixing LLVM libc++ itself. So developers have choice which C++ Standard Library implementation to use in CrystaX NDK - GNU libstdc++ or LLVM libc++. We offer both, and both working better than in Google's NDK.
My suggestion to the community is to try and target as a minimum 100% green for Android 5.0 only with the libc++ STL only. Maintainers may choose to exceed that of course. If you target that one single target and keep it all green, that makes the life of CrystaX much easier because effectively speaking what he's done is port newer STLs etc to the older API versions, so really all you need to maintain is the occasional #ifdef __ANDROID__ to work around Android's weird libc and library config and in theory at least, it ought to be good from there.
Of course, this is choice of library maintainers. However, my personal opinion is that would be better to fix underlying layer (what we do in CrystaX NDK) than fixing Boost code itself. Mainly because it will become nightmare to support all Android versions and take into account all peculiarities and bugs on Android libc (and remember, you'll need to add run-time checks to detect real Android version on device and apply different workarounds for different Android versions). This looks really wrong for me as for developer, so we offer another way - just use CrystaX NDK (which provide standard behaviour of underlying layer) and forget about Android libc bugs/incompatibilities/etc. CrystaX NDK is open source project, we offer it for free and we strongly aim to continue its development and support, so practically it's better choice than fighting with Google's NDK and fixing on your own all things we already fixed in CrystaX NDK. -- Dmitry Moskalchuk