|tagger||The Android Open Source Project <email@example.com>||Fri Sep 06 17:45:09 2019 -0700|
Android 7.1.2 release 38 -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRDQNE1cO+UXoOBCWTorT+BmrEOeAUCXXL9lQAKCRDorT+BmrEO ePBZAJ4yt2DIfouarMrF/ufoFJB8iqGCjQCfe12IBxVpb38fEXeIjGOrVZNdouA= =hu6w -----END PGP SIGNATURE-----
|author||Dan Albert <firstname.lastname@example.org>||Thu Feb 04 22:13:29 2016 +0000|
|committer||android-build-merger <email@example.com>||Thu Feb 04 22:13:29 2016 +0000|
Merge "Mark mips-fp4 test as broken for clang." am: 4f3d3be70d * commit '4f3d3be70dfcbd3dcb7f9a38cb20f368cdee43bc': Mark mips-fp4 test as broken for clang.
The NDK allows Android application developers to include native code in their Android application packages, compiled as JNI shared libraries.
Discussions related to the Android NDK happen on the android-ndk Google Group.
Note: This document is for developers of the NDK, not developers that use the NDK.
Both Linux and Windows host binaries are built on Linux machines. Windows host binaries are built via MinGW cross compiler. Systems without a working MinGW compiler can use
build/tools/build-mingw64-toolchain.sh to generate their own and be added to the
PATH for build scripts to discover.
Building binaries for Mac OS X requires at least 10.8.
Target headers and binaries are built on Linux.
The NDK consists of three parts: host binaries, target prebuilts, and others (build system, docs, samples, tests).
toolchains/contains GCC and Clang toolchains.
$TOOLCHAIN/config.mkcontains ARCH and ABIS this toolchain can handle.
$TOOLCHAIN/setup.mkcontains toolchain-specific default CFLAGS/LDFLAGS when this toolchain is used.
binutils/contains the standalone binutils installation for use with Clang.
host-tools/contains build dependencies and additional tools.
ndk-gdbcan also be found here.
platforms/android-N/arch-$ARCH_NAME/contains headers and libraries for each API level.
--sysrootto one of these directories based on user-specified
sources/cxx-stl/$STLcontains the headers and libraries for the various C++ STLs.
build/contains the ndk-build system and scripts to rebuild NDK.
sources/contains modules useful in samples and apps via
$(call import-module, $MODULE)
Check out the branch
repo init -u https://android.googlesource.com/platform/manifest \ -b master-ndk # Googlers, use repo init -u \ persistent-https://android.git.corp.google.com/platform/manifest \ -b master-ndk
Additional Linux Dependencies (available from apt):
Mac OS X also requires Xcode.
$ python checkbuild.py --no-package
$ python checkbuild.py --system windows
checkbuild.py also accepts a variety of other options to speed up local builds, namely
The simplest way to package an NDK on Linux is to just omit the
--no-package flag when running
checkbuild.py. This will take a little longer though, so it may not be desired for day to day development.
If you need to re-run just the packaging step without going through a build, packaging is handled by
Running the NDK tests requires a complete NDK package (see previous steps). From the NDK source directory (not the extracted package):
$ NDK=/path/to/extracted/ndk python tests/run-all.py --abi $ABI_TO_TEST
To run the tests with Clang, use the option
The full test suite includes tests which run on a device or emulator, so you'll need to have adb in your path and
ANDROID_SERIAL set if more than one device/emulator is connected. If you do not have a device capable of running the tests, you can run just the
awk test suites with the
The libc++ tests are not currently integrated into the main NDK tests. To run the libc++ tests:
$ NDK=/path/to/extracted/ndk sources/cxx-stl/llvm-libc++/llvm/ndk-test.sh $ABI
Note that these tests are far from failure free (especially on 32-bit ARM). In general, most of these tests are locale related and fail because we don't support anything beyond the C locale. The ARM32 specific failures are because the libgcc unwinder does not get along with the LLVM unwinder. The test config file (
$NDK/sources/cxx-stl/llvm-libc++/libcxx/test/libcxx/ndk/test/config.py) can be modified to use
-lgcc and the tests will then work on ARM (but will take considerably longer to run).
Yes, this does mean that exception handling will often fail when using
c++_shared on ARM32. We should fix this ASAP, but this actually is not a regression from r10e.