Android NDK R7c - Changelog

What's new in Android NDK R7c:

April 10th, 2012

Important bug fixes:
· Fixed GNU STL armeabi-v7a binaries to not crash on non-NEON devices. The files provided with NDK r7b were not configured properly, resulting in crashes on Tegra2-based devices and others when trying to use certain floating-point functions (e.g., cosf, sinf, expf).

Important changes:
· Added support for custom output directories through the NDK_OUT environment variable. When defined, this variable is used to store all intermediate generated files, instead of $PROJECT_PATH/obj. The variable is also recognized by ndk-gdb.
· Added support for building modules with hundreds or even thousands of source files by defining LOCAL_SHORT_COMMANDS to true in your Android.mk.
· This change forces the NDK build system to put most linker or archiver options into list files, as a work-around for command-line length limitations. See docs/ANDROID-MK.html for details.

Other bug fixes:
· Fixed android_getCpuCount() implementation in the cpufeatures helper library. On certain devices, where cores are enabled dynamically by the system, the previous implementation would report the total number of active cores the first time the function was called, rather than the total number of physically available cores.

What's new in Android NDK R7b:

March 21st, 2012

Important bug fixes:
· Updated sys/atomics.h to avoid correctness issues on some multi-core ARM-based devices. Rebuild your unmodified sources with this version of the NDK and this problem should be completely eliminated. For more details, read docs/ANDROID-ATOMICS.html.
· Reverted to binutils 2.19 to fix debugging issues that appeared in NDK r7 (which switched to binutils 2.20.1).
· Fixed ndk-build on 32-bit Linux. A packaging error put a 64-bit version of the awk executable under prebuilt/linux-x86/bin in NDK r7.
· Fixed native Windows build (ndk-build.cmd). Other build modes were not affected.
· Fixed the standalone toolchain to generate proper binaries when using -lstdc++ (i.e., linking against the GNU libstdc++ C++ runtime). You should use -lgnustl_shared if you want to link against the shared library version or -lstdc++ for the static version.
· Fixed gnustl_shared on Cygwin. The linker complained that it couldn't find libsupc++.a even though the file was at the right location.
· Fixed Cygwin C++ link when not using any specific C++ runtime through APP_STL.

Other changes:
· When your application uses the GNU libstdc++ runtime, the compiler will no longer forcibly enable exceptions and RTTI. This change results in smaller code.
· ndk-gdb now works properly when your application has private services running in independent processes. It debugs the main application process, instead of the first process listed by ps, which is usually a service process.
· Fixed a rare bug where NDK r7 would fail to honor the LOCAL_ARM_MODE value and always compile certain source files (but not all) to 32-bit instructions.
· stlport: Refresh the sources to match the Android platform version. This update fixes a few minor bugs
· stlport: Removed 5 unnecessary static initializers from the library.
· The GNU libstdc++ libraries for armeabi-v7a were mistakenly compiled for armeabi instead. This change had no impact on correctness, but using the right ABI should provide slightly better performance.
· The cpu-features helper library was updated to report three optional x86 CPU features (SSSE3, MOVBE and POPCNT). See docs/CPU-FEATURES.html for more details.
· docs/NDK-BUILD.html was updated to mention NDK_APPLICATION_MK instead of NDK_APP_APPLICATION_MK to select a custom Application.mk file.
· Cygwin: ndk-build no longer creates an empty "NUL" file in the current directory when invoked.
· Cygwin: Added better automatic dependency detection.
· Cygwin: ndk-build does not try to use the native Windows tools under $NDK/prebuilt/windows/bin with certain versions of Cygwin and/or GNU Make.

What's new in Android NDK R7:

November 12th, 2011

Android NDK r7 includes a number of build system improvements and bug fixes, but most importantly it gives you access to two new sets of APIs:
· Low-level streaming multimedia: A new API based on Khronos OpenMAX AL 1.0.1 provides a direct, efficient path for low-level streaming multimedia. The new path is ideal for applications that need to maintain complete control over media data before passing it to the platform for presentation. For example, media applications can now retrieve data from any source, apply proprietary encryption/decryption, and then send the data to the platform for display.
· Audio decoding into PCM: Extensions to the existing native audio API based on Khronos OpenSL ES let native apps decode compressed audio assets to PCM format.

What's new in Android NDK R6b:

October 19th, 2011

· Fixed the build when APP_ABI="armeabi x86" is used for multi-architecture builds.
· Fixed the location of prebuilt STLport binaries in the NDK release package. A bug in the packaging script placed them in the wrong location.
· Fixed atexit() usage in shared libraries with the x86standalone toolchain.
· Fixed make-standalone-toolchain.sh --arch=x86. It used to fail to copy the proper GNU libstdc++ binaries to the right location.
· Fixed the standalone toolchain linker warnings about missing the definition and size for the __dso_handle symbol (ARM only).
· Fixed the inclusion order of $(SYSROOT)/usr/include for x86 builds. See the bug for more information.
· Fixed the definitions of ptrdiff_t and size_t in x86-specific systems when they are used with the x86 standalone toolchain.

What's new in Android NDK R6:

July 16th, 2011

General notes:
· Adds support for the x86 ABI, which allows you to generate machine code that runs on compatible x86-based Android devices. Major features for x86 include x86-specific toolchains, system headers, libraries and debugging support. For all of the details regarding x86 support, see docs/CPU-X86.html in the NDK package.
· By default, code is generated for ARM-based devices, but you can add x86 to your APP_ABI definition in your Application.mk file to build for x86 platforms. For example, the following line instructs ndk-build to build your code for three distinct ABIs: APP_ABI := armeabi armeabi-v7a x86
· Unless you rely on ARM-based assembly sources, you shouldn't need to touch your Android.mk files to build x86 machine code.
· You can build a standalone x86 toolchain using the --toolchain=x86-4.4.3 option when calling make-standalone-toolchain.sh. See docs/STANDALONE-TOOLCHAIN.html for more details.
· The new ndk-stack tool lets you translate stack traces in logcat that are generated by native code. The tool translates instruction addresses into a readable format that contains things such as the function, source file, and line number corresponding to each stack frame. For more information and a usage example, see docs/NDK-STACK.html.

Other changes:
· arm-eabi-4.4.0, which had been deprecated since NDK r5, has been removed from the NDK distribution.

What's new in Android NDK R4b:

September 2nd, 2010

· Includes fixes for several issues in the NDK build and debugging scripts — if you are using NDK r4, we recommend downloading the NDK r4b build. For detailed information the changes in this release, read the CHANGES.TXT document included in the downloaded NDK package.
· Provides a simplified build system through the new ndk-build build command.
· Adds support for easy native debugging of generated machine code on production devices through the new ndk-gdb command.

Adds a new Android-specific ABI for ARM-based CPU architectures, armeabi-v7a. The new ABI extends the existing armeabi ABI to include these CPU instruction set extensions:
· Thumb-2 instructions
· VFP hardware FPU instructions (VFPv3-D16)
· Optional support for ARM Advanced SIMD (NEON) GCC intrinsics and VFPv3-D32. Supported by devices such as Verizon Droid by Motorola, Google Nexus One, and others.

· Adds a new cpufeatures static library (with sources) that lets your app detect the host device's CPU features at runtime. Specifically, applications can check for ARMv7-A support, as well as VFPv3-D32 and NEON support, then provide separate code paths as needed.
· Adds a sample application, hello-neon, that illustrates how to use the cpufeatures library to check CPU features and then provide an optimized code path using NEON instrinsics, if supported by the CPU.
· Lets you generate machine code for either or both of the instruction sets supported by the NDK. For example, you can build for both ARMv5 and ARMv7-A architectures at the same time and have everything stored to your application's final .apk.
· To ensure that your applications are available to users only if their devices are capable of running them, Android Market now filters applications based on the instruction set information included in your application — no action is needed on your part to enable the filtering. Additionally, the Android system itself also checks your application at install time and allows the installation to continue only if the application provides a library that is compiled for the device's CPU architecture.
· Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.

What's new in Android NDK R4:

May 21st, 2010

· Provides a simplified build system through the new ndk-build build command.
· Adds support for easy native debugging of generated machine code on production devices through the new ndk-gdb command.
· Adds a new cpufeatures static library (with sources) that lets your app detect the host device's CPU features at runtime. Specifically, applications can check for ARMv7-A support, as well as VFPv3-D32 and NEON support, then provide separate code paths as needed.
· Adds a sample application, hello-neon, that illustrates how to use the cpufeatures library to check CPU features and then provide an optimized code path using NEON instrinsics, if supported by the CPU.
· Lets you generate machine code for either or both of the instruction sets supported by the NDK. For example, you can build for both ARMv5 and ARMv7-A architectures at the same time and have everything stored to your application's final .apk.
· To ensure that your applications are available to users only if their devices are capable of running them, Android Market now filters applications based on the instruction set information included in your application — no action is needed on your part to enable the filtering. Additionally, the Android system itself also checks your application at install time and allows the installation to continue only if the application provides a library that is compiled for the device's CPU architecture.
· Adds support for Android 2.2, including a new stable API for accessing the pixel buffers of Bitmap objects from native code.

Adds a new Android-specific ABI for ARM-based CPU architectures, armeabi-v7a. The new ABI extends the existing armeabi ABI to include these CPU instruction set extensions:
· Thumb-2 instructions
· VFP hardware FPU instructions (VFPv3-D16)
· Optional support for ARM Advanced SIMD (NEON) GCC intrinsics and VFPv3-D32. Supported by devices such as Verizon Droid by Motorola, Google Nexus One, and others.

What's new in Android NDK R3:

May 21st, 2010

Toolchain improvement:
· The toolchain binaries have been refreshed for this release with GCC 4.4.0, which should generate slightly more compact and efficient machine code than the previous one (4.2.1).
· Note that the GCC 4.4.0 C++ frontend is more pedantic, and may refuse to compile certain rare and invalid template declarations that were accepted by 4.2.1. To alleviate the problem, this NDK still provides the 4.2.1 binaries, which can optionally be used to build your machine code.

OpenGL ES 2.0 support:
· Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.
· A new trivial sample, named "hello-gl2", demonstrates how to render a simple triangle using both shader types.

Name simplification:
· This NDK release is just called "r3", for "Revision 3", to indicate that it is not limited to a specific Android platform/API level. Some developers thought that the previous release's name (1.6_r1) was confusing and indicated that it could only be used to target Android 1.6, which was not true.