am 010c2ee: Merge change 1307 into donut

Merge commit '010c2ee6b8961cc5c95c7710ea5a3058ff6ca77d'

* commit '010c2ee6b8961cc5c95c7710ea5a3058ff6ca77d':
  Remove the ROADMAP NDK file as it shouldn't be packaged with the NDK

ndk/docs/ROADMAP.TXT

@@ -1,69 +0,0 @@
-Android NDK Roadmap
-
-
-This is the list of improvements planned for the NDK, in no
-specific order of preference or priority:
-
-Fix bugs and make things easier in general.
-    Business as usual...
-
-Support x86 target ABI
-    Requires building a corresponding toolchain tree for
-    various supported host platforms, and modify the build
-    system. Biggest challenge at the moment is finding a
-    stable x86 platform to run tests against.
-
-Support for ARMv5TE + FPU
-    Unfortunately, a real FPU mandates that specific floating-point
-    registers be used to passed floating-point values in function
-    call. This results in a new ABI that is not compatible with the
-    one we currently support.
-
-    This new ABI should have a different name (e.g. 'armfpu') and
-    be supported through a different sysroot + toolchain configuration
-    (though it is likely we could reuse the arm-eabi-4.2.1 prebuilt
-    binaries, but with different configuration options).
-
-Easier debugging support
-    Debugging native code is still very rough. We can make it a lot better
-    through a series of tricks, which involve modifying some parts of the
-    system.
-
-Stable native APIs for OpenGL ES.
-    Nuff said...
-
-Stable C-based native API for a simple way to access surface pixels
-    Probably based on a simple lock/unlock paradigm. Would ideally be
-    useful to access both Skia and GL surfaces at the same time, though
-    probably with very different performance characteristics.
-    It will probably be very limited in scope, intentionally.
-
-Stable native APIs for audio.
-    Only something simple that could be used to manage audio buffers in
-    native code in a real-time basis. For now, applications have to
-    pass the buffers from Java to perform signal processing in native code
-    for them.
-
-Stable native APIs from 'libcutils/libutils'
-    The system libraries 'libcutils' and 'libutils' provide a host of
-    useful Android-specific functions that we could certainly expose to
-    native application.
-
-    Not everything in these libraries can be considered stable, so we
-    should probably split their headers into 'stable' and 'unstable'
-    parts, and add them to the NDK's sysroot over time.
-
-C++ Standard Library support
-    Many people are interested in using the STL. The Android system images
-    simply do *not* provide any real libstdc++ due to space/performance
-    constraints. However, we should be able to provide one or more STL
-    implementations as static libraries that can be linked to developer's
-    binaries.
-
-    Note that locales and wchar_t are not supported by the Android C library
-    so these would probably not be supported anyway.
-
-Better C++ exceptions and RTTI support
-    Some of these can be used in limited ways with the NDK, but it's a
-    pretty hard road that is not recommended at the moment. We should be
-    able to make this easier in the future.