Develop Reference

Android NDK compilation without sysroot

I am trying to compile the source code for multiple architectures and multiple API levels of Android NDK based on the compilation flags (by dynamically passing path of Application.mk to the ndk-build command). It was going fine till r12. Now I was trying to update my build system to latest NDK r15c and found that it's taking headers from "android-ndk/sysroot/..." path instead of depending on the APP_PLATFORM flag from Application.mk file
APP_PLATFORM := android-19
Logs for r12b NDK:
-I/data/android/android-ndk-r10d/platforms/android-19/arch-arm/usr/include
Above include path is present when I try verbose logs for ndk-build (V=1) .
Logs for r15c NDK:
--sysroot
/home/airwatch/Android/android-ndk/sysroot
-isystem
/home/airwatch/Android/android-ndk/sysroot/usr/include/arm-linux-androideabi
Above include path is present when I try verbose logs for r15c NDK.
It will not be possible to configure Standalone Toolchain due to my project requirements. Is there anyway to get rid of this sysroot?

As mentioned in comments above here is full explain: https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.md
Unified Headers
Before NDK r14, we had a set of libc headers for each API version. In
many cases these headers were incorrect. Many exposed APIs that didn‘t
exist, and others didn’t expose APIs that did.
In NDK r14 (as an opt in feature) we unified these into a single set
of headers, called unified headers. This single header path is used
for every platform level. API level guards are handled with #ifdef.
These headers can be found in prebuilts/ndk/headers.
Unified headers are built directly from the Android platform, so they
are up to date and correct (or at the very least, any bugs in the NDK
headers will also be a bug in the platform headers, which means we're
much more likely to find them).
In r15 unified headers are used by default. In r16, the old headers
have been removed.
Known Issues
Standalone toolchains using GCC are not supported out of the box. To
use GCC, pass -D__ANDROID_API__=$API when compiling. Note: this is not
something we will be fixing.
Supporting Unified Headers in Your Build
System
Unified headers require only a few changes compared to using the
deprecated NDK headers. For reference, this patch added support to
ndk-build: https://android-review.googlesource.com/c/239934/
The compile time sysroot is now $NDK/sysroot. Previously this was
$NDK/platforms/android-$API/arch-$ARCH.
Pass -isystem $NDK/sysroot/usr/include/$TRIPLE when compiling. The
triple has the following mapping:
Arch Triple
ARM arm-linux-androideabi
ARM64 aarch64-linux-android
MIPS mipsel-linux-android
MIPS64 mips64el-linux-android
x86 i686-linux-android
x86_64 x86_64-linux-android
This is needed for
architecture specific headers such as those in asm/ and machine/. We
plan to teach Clang's driver to automatically search the architecture
specific include directory, but that has yet to be done.
Pass -D__ANDROID_API__=$API when compiling. This define used to be
provided by <android/api-level.h>, but with only one set of headers
this is no longer possible. In the future we will look in to adding
-mandroid-version or similar to Clang so this is automatic.
At link time, change nothing. All link time build behavior should
match the deprecated headers behavior. --sysroot should still point to
$NDK/platforms/android-$API/arch-$ARCH/.

std::chrono with NDK r10e could not be resolved

Do not think I did not search, my Android project (on Eclipse) refuses to recognize std::chrono library. The include is OK in my header file :
#include <chrono>
But when I want use it :
using namespace std::chrono;
I have a : Symbol 'chrono' could not be resolved, and all the functions of chrono are unavailables.
So I use NDK r10e, I add some lines in my Application.mk, which now looks like this :
APP_PLATFORM := android-22
APP_STL := gnustl_static
APP_CPPFLAGS := -std=gnu++11
NDK_TOOLCHAIN_VERSION := 4.8
And in my Android.mk, I add :
LOCAL_CFLAGS += -std=gnu++11
It did not solve my problem. Any ideas ? Bad Eclipse configuration ?
After modifications in mk files, I have build and re-build my project.

This is known problem of GNU libstdc++ in Android NDK. It's built on top of very limited libc (Google's Bionic) and thus can't provide full C++ Standard Library functionality. In particular, std::chrono is almost completely disabled at build time, but not only std::chrono. There are many other classes and functions being disabled, so Google's NDK just don't support C++ fully.
You can switch to LLVM libc++ (APP_STL := c++_static), but it has experimental status in Google's Android NDK and is actually unstable (i.e. it cause crashes in the application even for completely standard C++ code). This instability is caused by the same reason as for GNU libstdc++ - i.e. because it's built on top of very limited libc.
I'd recommend switch to CrystaX NDK - alternative fork of Google's Android NDK, which I've started mainly to solve Google's NDK problems such as non-standard implementations of libc, libc++, etc. CrystaX NDK is developed to work as a drop-in replacement for Google's NDK (except for the fact that it provides fully standard-conforming low-level libraries). In CrystaX NDK, both GNU libstdc++ and LLVM libc++ are much more stable and fully conforming to C++ standard, at least at the same level as they conform to it on GNU/Linux. In particular, std::chrono is fully implemented there and works just fine. Also, in CrystaX NDK, you can use more recent compilers such as gcc-5.3 and clang-3.7, with better support of C++11 and C++14. I'd be happy if it helps you.

Android NDK and .so.X extensions

I'm trying to use the Grantlee library in an Android NDK app.
I can compile Grantlee just fine, and I get libGrantlee_Templates.so, libGrantlee_Templates.so.5, and libGrantlee_Templates.so.5.0.0.
Of these three, I can only install the first one in my Android.mk:
include $(CLEAR_VARS)
LOCAL_MODULE := libgrantlee
LOCAL_SRC_FILES := $(GRANTLEE_PATH)/lib/libGrantlee_Templates.so
include $(PREBUILT_SHARED_LIBRARY)
Because if I try to install either of the other two, then I get:
Android NDK: ERROR:Android.mk:grantlee: LOCAL_SRC_FILES should point to a file ending with ".so"
Android NDK: The following file is unsupported: libGrantlee_Templates.so.5
But then, like a cruel joke, the .so.5 that I can't install is exactly the file that it looks for at runtime:
E/AndroidRuntime(14439): java.lang.UnsatisfiedLinkError: dlopen failed: could not load library "libGrantlee_Templates.so.5"; caused by library "libGrantlee_Templates.so.5" not found
How do I solve this?

When you build a native shared library with NDK standalone toolchain, you must change its make files to get rid of .version suffixes. See for example how this is done for ffmpeg.

I had the same problem when using an external library in my project.
You can also add -avoid-version to the libtool command. This trick saved my day...

If the library is built with an autotools/libtool based build system, update the bundled libtool to libtool 2.4.3 or newer. Those versions know how to deal with these details about android shared libraries, so if you build it with --host=arm-linux-androideabi or similar, it won't add any version numbers to the libraries.
To upgrade the libtool version within a source package, run e.g. autogen.sh or a similar script within the source package, or autoreconf -fi, assuming that you've got a new enough version of libtool installed in the surrounding system.

Android NDK code analysis not using defined variables

I think this problem started when upgrading to the Juno Eclipse. I believe the C/C++ build environment was probably upgraded as well at the same time. The NDK was not upgraded.
We have a large mass of C code that compiles under several platforms. We are using the crystax-ndk (r6) to compile our C++ code. To know when we are compiling for Android, we have defined the following in the Android.mk
LOCAL_CFLAGS := -DANDROID_NDK \
-DDISABLE_IMPORTGL \
...
Then in some files we will include different headers depending upon the platform
#ifdef ANDROID_NDK
...
Our code compiles just fine and seems to run fine. However, when opening certain files the C/C++ code analyzer will find many errors. This appears to be because the analyzer doesn't know about the ANDROID_NDK defined variable.
Any idea why the code analyzer is not using the same #defines as the compiler? The code is almost uneditable with all the bogus errors the analyzer is reporting.

I saw you're comment about the analyzer you were refering to.
Eclipse CDT (C/C++ Development Toolkit) does not support parsing Android.mk yet neither does the NDK plugin add that functionality at the time of writing this.
Possible (ugly/annoying) workaround: Set up a header file setting the defines you are missing and include that header file to all files.

Use LOCAL_CPPFLAGS for C++ files and LOCAL_CFLAGS for C files in your Android.mk

How to tell Android NDK to use a different toolchain

I've downloaded a custom toolchain (linaro) to build ARM based Android apps. How do I tell the NDK to use it? Can I define or set something in Android.mk and Application.mk that would allow me to do that? Is there another way?

The NDK makefile system is quite extensible and you can indeed define a different toolchain. You'll need some understanding of how Make works.
Toolchains are discovered and initialized in build/core/init.mk line 261 (in NDKr6, the line # may change in future versions). The initialization code looks for files named config.mk under $(NDK_ROOT)/toolchains/*. So you'll need to add your toolchain in a subdirectory under the NDK toolchains directory, and add a config.mk and setup.mk to that subdirectory. Look at toolchains/x86-4.4.3 and toolchains/arm-linux-androideabi-4.4.3 for examples. You should be able to cut and paste the ARM toolchain config.mk and setup.mk if your toolchain has a standard layout.
Once you've defined a toolchain in the toolchain directory, you can switch to it by setting the NDK_TOOLCHAIN variable inside your Application.mk file.

As the other answer mentions, toolchains are discovered by ndk-build makefile system in $(NDK_ROOT)/toolchains/ and you can mirror ideas you see there. But there are a few extra concepts for supporting non-Android target platforms that are interesting although they may be soon outdated as ndk-build starts to explicitly support other platforms, such as mingw targeting win32 (or other gcc compilers targeting plain 'ol linux).
In config.mk:
TOOLCHAIN_ABIS := (list of ABIs that the toolchain supports)
This is an important definition, because you can use this name in your Application.mk to build using the toolchain for a particular ABI. One of the benefits of corrupting the usage of this definition, is that ndk-build can simultaneously build for multiple ABIs. It always assumes that the platform is Android, but if you want to target win32 using a mingw based toolchain, you can define an "ABI" as x86-win32, and then use this ABI in your Application.mk to select it as an additional target via APP_ABI:= x86-win32 Then in your Android.mk files you can use the TARGET_ARCH_ABI definition to select win32 specific sources and include paths, for example:
ifeq ($(TARGET_ARCH_ABI),x86-win32)
LOCAL_SRC_FILES += my_win32_file.c
LOCAL_CFLAGS += -DSOME_WIN32_SPECIFIC
endif
The final piece is that in setup.mk for your toolchain, it may be insufficient to look at other toolchains as examples, because what setup.mk for a particular toolchain really does is override build settings in default-build-commands.mk, so what you want to do is inspect that file, and redefine things in it that you don't like.
Following the previous example, mingw does not support the noexec flag in the binaries, and you can get rid of this feature by adding the following lines in your setup.mk:
# These flags are used to enforce the NX (no execute) security feature in the
# generated machine code. This adds a special section to the generated shared
# libraries that instruct the Linux kernel to disable code execution from
# the stack and the heap.
TARGET_NO_EXECUTE_CFLAGS := # our platform doesn't support this flag!
TARGET_NO_EXECUTE_LDFLAGS := # our platform doesn't support this flag!
# These flags disable the above security feature
TARGET_DISABLE_NO_EXECUTE_CFLAGS := # our platform doesn't support this flag!
TARGET_DISABLE_NO_EXECUTE_LDFLAGS := # our platform doesn't support this flag!
This is just one example of the many features in default-build-commands.mk that may need to be overridden, and of course it's important to provide TOOLCHAIN_NAME so that the toolchain can be selected via NDK_TOOLCHAIN variable inside your Application.mk file in addition to the ABI methodology I mention above.

well，you can simply add "NDK_TOOLCHAIN_VERSION = 4.9" in your Application.mk