Develop Reference

Android: missing features in CMake vs ndk-build

I'm migrating from ndk-build to CMake (it better integrates with Android Studio, and would enable us to have a single CMakeLists.txt for all platforms).
Unfortunately, our projects use some features of Android.mk that I'm not being able to replicate with CMake. More specifically:
TARGET_ARCH: we use this to include different pre-compiled binaries. How can I find the target arch with CMake?
LOCAL_ARM_MODE: is this even available in CMake?

EDIT:
When using Gradle, CMAKE_ANDROID_ARCH_ABI is not set! Use CMAKE_ANDROID_ARCH or ANDROID_ABI.
ORIGINAL:
After a bit more of Google, I've found the answer here: https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-android-with-the-ndk
CMAKE_ANDROID_ARCH_ABI or CMAKE_ANDROID_ARCH are similar to the ndk-build TARGET_ARCH.
CMAKE_ANDROID_ARM_MODE allows setting the ARM mode (setting it to ON targets 32-bit ARM processors, while to OFF targets 16-bit Thumb processors).

Android NDK native libraries and documentation

I started working on the NDK - Native Development Kit using JNI.
From my understanding the NDK contains:
1. The source code containing a set of .so libraries (and c/c++ header files), each specifically compiled to different Android Architecture: such as arm, mips, x86. which supply us some c/c++ APIs to the Android device.
2. The tool chain which is responsible for the build for each Android architecture.
Example of working with the NDK:
I am using in my app, the logcat in c++ code, for this I added to my Android.mk (in Android studios - the gradle properties):
LOCAL_LDLIBS := -llog
And in my c++ code I include the header:
#include <android/log.h>
And I do see the header file in:
\platforms\android-21\arch-arm\usr\include\android\log.h
and the lib file in:
\platforms\android-21\arch-arm\usr\lib\liblog.so
My questions:
Not all APIs that exist in the Java SDK framework exist in the NDK Framework, right?
If I"m right about 1: While it seems very easy to work with the log, how do I know which APIs are supported and which are not?
For example, is there a lib for using the camera/flashlight/gps/Writing to storage or for these I have to use Java code?
I have not seen a clear API or documantation about it, not in the http://developer.android official, and not in the docs provided in the NDK installation (the stableAPIs.html contains minimal description for minimal API set), and not in the many StackOverFlow questions I read.
This is on a different subject, The NDK compiler for the android different architectures is based on GCC to compile our c++ code right? and how do I know which c++ version am I using?
Thanks

Right.
In your NDK directory, go to docs, open Start_Here.html, then click on Stable APIs for a list of APIs supported by the NDK. Note that you can call the Java APIs from C++ code through the Java Native Interface (JNI), but that's a separate topic (and slightly more advanced).
There are both GCC and Clang/LLVM toolchains included with the NDK.By C++ version, do you actually mean compiler version? If you mean compiler version, then you can specify which one you want to be used if you require a specific version:
# Specify that you want GCC 4.8 to be used. This goes in your Application.mk file
NDK_TOOLCHAIN_VERSION := 4.8
If you really meant C++ version, then unless you explictly specified a standard (e.g. with -std=c++11 or -std=c++1y) you're probably getting the C++98 standard (possibly with some extensions).

Using GNU STL and C++11 with V8 on Android NDK

I am building an application on Android using NDK and V8. I would prefer to use C++11 and GNU STL for features such as shared_ptr; however, the V8 build system seems to be hardcoded to use stlport_static as its STL variant.
Even when patching the build system to generate a fully self-contained library, V8's build does not statically link STLport into its .a files (which is to be expected), and thus I get hundreds of linker errors from unresolved symbols in libv8_base.a et al. I also do not see any way to indicate to ndk-build that it should link in stlport_static when I am using a different STL variant.
Is there a reasonable pattern to linking in stlport_static while using gnustl_static, or, better yet, is there a way of building Android V8 against gnustl_static instead?

You have a problem. Well, mixing different STLs in separate .so's is possible, with extra care; but using two STLs inside one .so is simply impossible.
You either need to implement your own shared_ptr (no big deal), but then you will face the same issue for every other feature that exists in gnustl and not in stlport.
Or you need to port V8 to gnustl (and I am afraid that the MIT license does not allow this).

Native Android, Interlocked/Atomic operations

Interlocked/Atomic operations are CPU specific.
Is there any common baseline requirement by all Android supporting hardware as far as for interlocked operations?
Are there any interlocked operations supported by all Android devices?
Is there any Android equivalent to Windows' InterlockedExchange?
Any help will be appreciated.

You can use __atomic_swap for InterlockedExchange functionality.
Read docs/ANDROID-ATOMICS.html file from NDK distribution for more info.

You can also use GCC atomic builtins.

There's stdatomic header in latest editions of ndk, so if you use GNU or LLVM cxx module, it is possible to use this standard C++11 header. You cannot use it with STLport however - it has no such header. Do not forget to add libatomic to LOCAL_LDLIBS (see https://developer.android.com/ndk/guides/cpp-support.html for details).

Which compiler does Android NDK use?

I'm writing ARM NEON-based code for an Android application and I was struggling with certain compiler flags not being recognized. I later realized that support for those flags was only added quite recently and that my GCC version is older. I'm doing the whole thing on Windows and am limited by what versions Cygwin has to offer. Here's my question: before I go and try to build GCC 4.6.0 on my Windows machine and make Cygwin like it, will it work for me or does the NDK use its own version of the GCC and my upgrade will not at all affect it? If it does, is it possible to tell it to use a different compiler?

Regarding NDK r8d it can be modified in 2 ways (see Andriod ndk):
For ndk-build, export the NDK_TOOLCHAIN_VERSION=4.7 variable or add it to Application.mk.
For standalone builds, add the --toolchain= option to make-standalone-toolchain.sh
--toolchain=arm-linux-androideabi-4.7
Default compiler is set in ndk/build/core/setup-toolchain.mk (see NDK_TOOLCHAIN and NDK_TOOLCHAIN_VERSION)

The NDK itself invokes a customized cross-compiler built on the arm-eabi-gcc compiler. There are examples out there of people creating custom toolchains using bog-standard GCC implementations with support for ARM instruction sets but that's way out of my league. Most of the stuff I've read in the past always discussed using the toolchain included with the NDK to compile native code.
Corollary: Most of the people who have complained and have had to make their own toolchain have been people that were upset with the (supposed) sub-par C++ support of the NDK toolchain's compiler. I can't speak to this because some of the articles were older and Android changes so rapidly. It also hasn't been an opinion that seems to pop up all too frequently.

GCC is deprecated in favor of clang as of NDK 11 (March 2016)
Mentioned on the official revision history: https://developer.android.com/ndk/downloads/revision_history.html
How to switch between compilers is asked at:
How to switch between gcc and clang in Android NDK Revision 11?
Latest C++11 features with Android NDK
And you can check it easily with:
enum CONSTEXPR {N = 256};
char s[N];
#ifdef __clang__
snprintf(s, N, "%s", "clang" __clang_version__);
#else
# ifdef __GNUC__
snprintf(s, N, "%s %d.%d.%d", "gcc", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
# endif
#endif
then just log s or return it to a TextView.