Skip to content

GitLab

Commit adc1d27e authored by Scott Main's avatar Scott Main
Browse files

docs: move NDK docs to HTML and add documentation.html, 

which opens a frameset to navigate all the documentation
TODO: cleanup the sidenav in the frameset for better organization
It'd also be nice to make all the "see foo.html" messages into links

Change-Id: I6f530f7cb7d47c4ef3b75bff192bd6149b42d285
parent 508afa10
Hide whitespace changes
Inline Side-by-side
Showing with 394 additions and 333 deletions
docs/ANDROID-MK.TXT → docs/ANDROID-MK.html
View file @ adc1d27e
Android.mk file syntax specification
<html><body><pre>Android.mk file syntax specification
Introduction:
-------------
......@@ -6,7 +6,7 @@ Introduction:
This document describes the syntax of Android.mk build file
written to describe your C and C++ source files to the Android
NDK. To understand what follows, it is assumed that you have
read the docs/OVERVIEW.TXT file that explains their role and
read the docs/OVERVIEW.html file that explains their role and
usage.
Overview:
......@@ -209,12 +209,12 @@ PREBUILT_SHARED_LIBRARY
library (e.g. foo/libfoo.so), instead of a source file.
You can reference the prebuilt library in another module using
the LOCAL_PREBUILTS variable (see docs/PREBUILTS.TXT for more
the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more
information).
PREBUILT_STATIC_LIBRARY
This is the same as PREBUILT_SHARED_LIBRARY, but for a static library
file instead. See docs/PREBUILTS.TXT for more.
file instead. See docs/PREBUILTS.html for more.
TARGET_ARCH
Name of the target CPU architecture as it is specified by the
......@@ -225,7 +225,7 @@ TARGET_PLATFORM
Name of the target Android platform when this Android.mk is parsed.
For example, 'android-3' correspond to Android 1.5 system images. For
a complete list of platform names and corresponding Android system
images, read docs/STABLE-APIS.TXT.
images, read docs/STABLE-APIS.html.
TARGET_ARCH_ABI
Name of the target CPU+ABI when this Android.mk is parsed.
......@@ -241,7 +241,7 @@ TARGET_ARCH_ABI
match what is used internally by the Android platform.
For more details about architecture ABIs and corresponding
compatibility issues, please read docs/CPU-ARCH-ABIS.TXT
compatibility issues, please read docs/CPU-ARCH-ABIS.html
Other target ABIs will be introduced in future releases of the NDK
and will have a different name. Note that all ARM-based ABIs will
......@@ -261,7 +261,7 @@ NDK-provided function macros:
- - - - - - - - - - - - - - -
The following are GNU Make 'function' macros, and must be evaluated
by using '$(call <function>)'. They return textual information.
by using '$(call &lt;function&gt;)'. They return textual information.
my-dir
Returns the path of the last included Makefile, which typically is
......@@ -356,13 +356,13 @@ import-module
A function that allows you to find and include the Android.mk
of another module by name. A typical example is:
$(call import-module,<name>)
$(call import-module,&lt;name&gt;)
And this will look for the module tagged <name> in the list of
And this will look for the module tagged &lt;name&gt; in the list of
directories referenced by your NDK_MODULE_PATH environment
variable, and include its Android.mk automatically for you.
Read docs/IMPORT-MODULE.TXT for more details.
Read docs/IMPORT-MODULE.html for more details.
Module-description variables:
- - - - - - - - - - - - - - -
......@@ -390,17 +390,17 @@ LOCAL_MODULE
it before including any $(BUILD_XXXX) script.
By default, the module name determines the name of generated files,
e.g. lib<foo>.so for a shared library module named <foo>. However
e.g. lib&lt;foo&gt;.so for a shared library module named &lt;foo&gt;. However
you should only refer to other modules with their 'normal'
name (e.g. <foo>) in your NDK build files (either Android.mk
name (e.g. &lt;foo&gt;) in your NDK build files (either Android.mk
or Application.mk)
You can override this default with LOCAL_MODULE_FILENAME (see below)
LOCAL_MODULE_FILENAME
This variable is optional, and allows you to redefine the name of
generated files. By default, module <foo> will always generate a
static library named lib<foo>.a or a shared library named lib<foo>.so,
generated files. By default, module &lt;foo&gt; will always generate a
static library named lib&lt;foo&gt;.a or a shared library named lib&lt;foo&gt;.so,
which are standard Unix conventions.
You can override this by defining LOCAL_MODULE_FILENAME, For example:
......@@ -470,7 +470,7 @@ LOCAL_CFLAGS
LOCAL_CPPFLAGS to specify flags for C++ sources only now).
It is possible to specify additional include paths with
LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES
LOCAL_CFLAGS += -I&lt;path&gt;, however, it is better to use LOCAL_C_INCLUDES
for this, since the paths will then also be used during native
debugging with ndk-gdb.
......@@ -507,7 +507,7 @@ LOCAL_LDLIBS
LOCAL_LDLIBS := -lz
See docs/STABLE-APIS.TXT for the list of exposed system libraries you
See docs/STABLE-APIS.html for the list of exposed system libraries you
can linked against with this NDK release.
LOCAL_ALLOW_UNDEFINED_SYMBOLS
......@@ -550,7 +550,7 @@ LOCAL_ARM_NEON
based CPUs support the NEON instruction set extensions and that you
should perform runtime detection to be able to use this code at runtime
safely. To lean more about this, please read the documentation at
docs/CPU-ARM-NEON.TXT and docs/CPU-FEATURES.TXT.
docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html.
Alternatively, you can also specify that only specific source files
may be compiled with NEON support by using the '.neon' suffix, as
......@@ -667,8 +667,8 @@ LOCAL_FILTER_ASM
LOCAL_SRC_FILES := foo.c bar.S
LOCAL_FILTER_ASM := myasmfilter
foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o
foo.c --1--&gt; $OBJS_DIR/foo.S.original --2--&gt; $OBJS_DIR/foo.S --3--&gt; $OBJS_DIR/foo.o
bar.S --2--&gt; $OBJS_DIR/bar.S --3--&gt; $OBJS_DIR/bar.o
Were "1" corresponds to the compiler, "2" to the filter, and "3" to the
assembler. The filter must be a standalone shell command that takes the
......@@ -677,3 +677,4 @@ LOCAL_FILTER_ASM
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
</pre></body></html>
\ No newline at end of file
docs/APPLICATION-MK.TXT → docs/APPLICATION-MK.html
View file @ adc1d27e
Application.mk file syntax specification
<html><body><pre>Application.mk file syntax specification
Introduction:
-------------
......@@ -6,11 +6,11 @@ Introduction:
This document describes the syntax of Application.mk build files
written to describe the native modules required by your Android
application. To understand what follows, it is assumed that you have
read the docs/OVERVIEW.TXT file that explains their role and
read the docs/OVERVIEW.html file that explains their role and
usage.
Readers of this document should have read docs/OVERVIEW.TXT and
docs/ANDROID-MK.TXT
Readers of this document should have read docs/OVERVIEW.html and
docs/ANDROID-MK.html
Overview:
......@@ -26,9 +26,9 @@ where $PROJECT points to your application's project directory.
Another alternative is to place it under a sub-directory of the top-level
$NDK/apps directory, e.g.:
$NDK/apps/<myapp>/Application.mk
$NDK/apps/&lt;myapp&gt;/Application.mk
Where <myapp> is a short name used to describe your 'application'
Where &lt;myapp&gt; is a short name used to describe your 'application'
to the NDK build system (this name doesn't go into your generated
shared libraries or your final packages).
......@@ -42,7 +42,7 @@ APP_PROJECT_PATH
specific location known to the APK-generating tools.
Note that it is optional for $PROJECT/jni/Application.mk, but
*mandatory* for $NDK/apps/<myapp>/Application.mk
*mandatory* for $NDK/apps/&lt;myapp&gt;/Application.mk
APP_MODULES
This variable is optional. If not defined, the NDK will build by
......@@ -68,7 +68,7 @@ APP_OPTIM
binaries which are much easier to debug.
Note that if your application is debuggable (i.e. if your manifest
sets the android:debuggable attribute to "true" in its <application>
sets the android:debuggable attribute to "true" in its &lt;application&gt;
tag), the default will be 'debug' instead of 'release'. This can
be overridden by setting APP_OPTIM to 'release'.
......@@ -147,11 +147,12 @@ APP_ABI
APP_ABI := armeabi armeabi-v7a
For the list of all supported ABIs and details about their usage and
limitations, please read docs/CPU-ARCH-ABIS.TXT
limitations, please read docs/CPU-ARCH-ABIS.html
A trivial Application.mk file would be:
-------------- cut here -------------------------
APP_PROJECT_PATH := <path to project>
APP_PROJECT_PATH := &lt;path to project&gt;
-------------- cut here -------------------------
</pre></body></html>
\ No newline at end of file
docs/CHANGES.TXT → docs/CHANGES.html
View file @ adc1d27e
Android NDK ChangeLog:
<html><body><pre>Android NDK ChangeLog:
-------------------------------------------------------------------------------
android-ndk-r5
......@@ -26,7 +26,7 @@ IMPORTANT CHANGES:
platform:
- Native audio API through the OpenSL ES Standard.
New headers <SLES/OpenSLES.h> and <SLES/OpenSLES_Android.h> are
New headers &lt;SLES/OpenSLES.h&gt; and &lt;SLES/OpenSLES_Android.h&gt; are
provided to allow applications targetting this API level to perform
low-latency audio input, output and processing directly from native
code.
......@@ -48,7 +48,7 @@ IMPORTANT CHANGES:
that allows one to provide Opaque Binary Objects containing
large amounts of data outside of the APK.
See the documentation in docs/STABLE-APIS.TXT for more details.
See the documentation in docs/STABLE-APIS.html for more details.
Note that most of these new features are targetted at game developers.
......@@ -58,8 +58,8 @@ IMPORTANT CHANGES:
$NDK/ndk-build NDK_DEBUG=1
This will have the same result that setting the android:debuggable="true"
in the <application> element of your AndroidManifest.xml file. See the
file docs/NDK-BUILD.TXT for more details.
in the &lt;application&gt; element of your AndroidManifest.xml file. See the
file docs/NDK-BUILD.html for more details.
Note that you will need to use the SDKr8 build tools to use this feature
properly!
......@@ -82,7 +82,7 @@ IMPORTANT CHANGES:
- Add support for prebuilt libraries with the PREBUILT_SHARED_LIBRARY and
PREBUILT_STATIC_LIBRARIES build scripts. See the new documentation
file named docs/PREBUILTS.TXT for explanations and usage examples.
file named docs/PREBUILTS.html for explanations and usage examples.
- Support for module exports: A module can now define a set of compiler or
linker flags that will be automatically 'imported' by any other module that
......@@ -90,30 +90,30 @@ IMPORTANT CHANGES:
This is achieved with the help of new Android.mk variables named
LOCAL_EXPORT_CFLAGS, LOCAL_EXPORT_CPPFLAGS, LOCAL_EXPORT_C_INCLUDES and
LOCAL_EXPORT_LDLIBS. See docs/ANDROID-MK.TXT for mode documentation, and
LOCAL_EXPORT_LDLIBS. See docs/ANDROID-MK.html for mode documentation, and
a 'samples/module-exports' for a sample project that uses this.
- Add support to specify a different file name for generated files, through
the new LOCAL_MODULE_FILENAME variable. See docs/ANDROID-MK.TXT for an
the new LOCAL_MODULE_FILENAME variable. See docs/ANDROID-MK.html for an
example.
- Add support for module imports, through the NDK_MODULE_PATH environment
variable and the new 'import-module' function. This allows you to avoid
hard-coding the path of third-party modules into your project files.
See docs/IMPORT-MODULE.TXT for details.
See docs/IMPORT-MODULE.html for details.
- Add the content of LOCAL_C_INCLUDES to gdb.setup to make native debugging
easier. Also fixes an issue that prevented clean parallel builds of
debuggable applications to work correctly. This fixes an error message that
said:
/bin/sh: <project>/libs/armeabi/gdb.setup: No such file or directory
/bin/sh: &lt;project&gt;/libs/armeabi/gdb.setup: No such file or directory
When doing a "ndk-build -j<number>", with <number> bigger than 1.
When doing a "ndk-build -j&lt;number&gt;", with &lt;number&gt; bigger than 1.
- Add support for assembly-level source filtering. See the description of
LOCAL_FILTER_ASM in docs/ANDROID-MK.TXT for more details. This can be useful
LOCAL_FILTER_ASM in docs/ANDROID-MK.html for more details. This can be useful
for certain kinds of obfuscation tasks.
- This NDK comes with a new toolchain (named arm-linux-androideabi-4.4.3)
......@@ -122,7 +122,7 @@ IMPORTANT CHANGES:
- Better code generation than the previous one (gcc-4.4.0)
- On Windows, the binaries do not depend on Cygwin anymore.
- The ability to use it as a stand-alone cross-compiler
(see docs/STANDALONE-TOOLCHAIN.TXT for all details).
(see docs/STANDALONE-TOOLCHAIN.html for all details).
The binaries for gcc-4.4.0 are still provided for backwards compatibility.
Use NDK_TOOLCHAIN=arm-eabi-4.4.0 in your environment to force its usage.
......@@ -140,7 +140,7 @@ IMPORTANT CHANGES:
which report an architecture version of 7).
The library is now also available as an import module, to simplify its
usage in your build scripts. See the updated docs/CPU-FEATURES.TXT file
usage in your build scripts. See the updated docs/CPU-FEATURES.html file
for details.
NOTE: Please update your Android.mk to use module imports as soon as
......@@ -148,7 +148,7 @@ IMPORTANT CHANGES:
and will be removed in a future NDK release. Avoid referencing
it directly in your build scritps!
OTHER FIXES & CHANGES:
OTHER FIXES AND CHANGES:
- Reduced the size of generated binaries by using --strip-unneeded
instead of --strip-debug. This gets rid of mor symbol table entries
......@@ -161,14 +161,14 @@ OTHER FIXES & CHANGES:
- The path to system headers is now included last in the compilation command
line. This prevents conflicts with source code that define their own headers
with similar names (e.g. a custom "err.h" was ignored, because the system
<err.h> was used instead).
&lt;err.h&gt; was used instead).
- Update documentation for 'my-dir' function to explain that, due to the
way GNU Make works, it really returns the path of the last included
Makefile (instead of the current one). Also provide examples on how
to deal with it.
- make-release.sh: Now has an --out-dir=<path> option to specify the
- make-release.sh: Now has an --out-dir=&lt;path&gt; option to specify the
output directory where the packages are going to be copied. Also
ensure that generated packages have go+r permissions.
......@@ -185,7 +185,7 @@ OTHER FIXES & CHANGES:
- ndk-gdb: properly launch activities for which name does not contain any dot.
- ndk-gdb: add --delay=<timeout> option to specify a delay in seconds between
- ndk-gdb: add --delay=&lt;timeout&gt; option to specify a delay in seconds between
activity launch and gdbserver attach. This is needed because certain
activities can take a long time to properly launch. The default delay is
also increased to 2 seconds (instead of 1).
......@@ -199,7 +199,7 @@ OTHER FIXES & CHANGES:
$NDK/build/toolchains and $NDK/build/prebuilt.
- Release and debug objects are stored under two different directories now
(i.e. obj/local/<abi>/objs and obj/local/<abi>/objs-debug). This prevents
(i.e. obj/local/&lt;abi&gt;/objs and obj/local/&lt;abi&gt;/objs-debug). This prevents
rebuilding *everything* when you switch between these two modes, which can
be a real time-saver for complex projects.
......@@ -211,7 +211,7 @@ android-ndk-r4b
This release fixes a few bugs in r4 scripts. There are no new features.
OTHER FIXES & CHANGES:
OTHER FIXES &amp; CHANGES:
- build/tools/rebuild-all-prebuilt.sh: mktemp expects 'XXXXXX' instead of 'XXX'.
Fix the script (and others in the same directory) to do that properly.
......@@ -243,7 +243,7 @@ OTHER FIXES & CHANGES:
your LOCAL_CFLAGS.
Note that even in release mode, the NDK build scripts will produce
binaries with symbols under obj/local/<abi>/ that will be used for
binaries with symbols under obj/local/&lt;abi&gt;/ that will be used for
debugging with gdb. However, the debugger will have a harder time to
print proper local variable values that have been optimized out or
even set breakpoints properly.
......@@ -253,7 +253,7 @@ android-ndk-r4
IMPORTANT BUG FIXES:
- The <fenv.h> header was not placed in the correct location and could not
- The &lt;fenv.h&gt; header was not placed in the correct location and could not
be found by normal builds.
IMPORTANT CHANGES:
......@@ -267,19 +267,19 @@ IMPORTANT CHANGES:
new 'ndk-build' script from your application's project directory, or
one of its sub-directories.
See docs/OVERVIEW.TXT and docs/NDK-BUILD.TXT for more details.
See docs/OVERVIEW.html and docs/NDK-BUILD.html for more details.
NOTE: For compatibility purpose, you can still define projects
through $NDK_ROOT/apps/<name> though.
through $NDK_ROOT/apps/&lt;name&gt; though.
However, not that sample applications have moved from
'apps/<name>/project' to 'samples/<name>' and now must
'apps/&lt;name&gt;/project' to 'samples/&lt;name&gt;' and now must
be built with 'ndk-build'. The source code of pre-existing
samples didn't change though.
- Easy native debugging support when running debuggable applications
on Android 2.2 or higher, through the new 'ndk-gdb' helper script.
See docs/NDK-GDB.TXT for details.
See docs/NDK-GDB.html for details.
- Support for hardware FPU. This is through the new 'armeabi-v7a' ABI
corresponding to ARMv7-a class devices.
......@@ -289,15 +289,15 @@ IMPORTANT CHANGES:
system images to date.
You will need to define APP_ABI in your Application.mk file to change this.
See docs/APPLICATION-MK.TXT
See docs/APPLICATION-MK.html
More details about ABIs is now available in docs/CPU-ARCH-ABIS.TXT
More details about ABIs is now available in docs/CPU-ARCH-ABIS.html
- A small static library named 'cpufeatures' is provided with source code
and can be used at runtime to determine the CPU features supported by the
target device. It should run on all Android platforms, starting from 1.5.
For more information, see docs/CPU-FEATURES.TXT
For more information, see docs/CPU-FEATURES.html
- Support for the optional ARM Advanced SIMD (a.k.a. NEON) instruction set
extension through the use the LOCAL_ARM_NEON variable in Android.mk, or
......@@ -309,14 +309,14 @@ IMPORTANT CHANGES:
paths if this is not the case. This is similar to MMX/SSE/3DNow on x86
platforms.
For more information, see docs/CPU-ARM-NEON.TXT
For more information, see docs/CPU-ARM-NEON.html
- Added a new sample (hello-neon) to demonstrate usage of 'cpufeatures'
and NEON intrinsics & build support.
and NEON intrinsics and build support.
- Added <android/bitmap.h>, a new stable API available from android-8
- Added &lt;android/bitmap.h&gt;, a new stable API available from android-8
(a.k.a. Android 2.2) to reliably access the pixel buffer of an
android.graphics.Bitmap object from native code. See docs/STABLE-API.TXT
android.graphics.Bitmap object from native code. See docs/STABLE-API.html
and the new sample program under 'samples/bitmap-plasma' for details
and usage example.
......@@ -324,10 +324,10 @@ IMPORTANT CHANGES:
are added to the generated shared libraries to instruct the kernel
that code shall not be executed from the heap and stack by default.
See docs/ANDROID-MK.TXT to see how to disable this, plus reference
See docs/ANDROID-MK.html to see how to disable this, plus reference
links for more information.
OTHER FIXES & CHANGES:
OTHER FIXES AND CHANGES:
- support the .s extension for raw assembly sources (.S is already supported
but the input files are parsed by the C-preprocessor before being sent to
......@@ -342,9 +342,9 @@ OTHER FIXES & CHANGES:
You can still use APP_MODULES to restrict the set of modules you want to
build. Note that the NDK now computes the transitive dependencies of these
modules for you now. See docs/APPLICATION-MK.TXT for details.
modules for you now. See docs/APPLICATION-MK.html for details.
- docs/STABLE-APIS.TXT: Add missing section for Dynamic Linker Library
- docs/STABLE-APIS.html: Add missing section for Dynamic Linker Library
(libdl.so). It is actually supported by all API levels.
- build/tools/download-toolchain-sources.sh: Use 'master' branch by default
......@@ -352,11 +352,11 @@ OTHER FIXES & CHANGES:
- build-toolchain.sh: Allow ad-hoc patching of toolchain sources when rebuilding
them. This is primarily to ease development. All you need to do is put a patch
under build/tools/toolchain-patches/<foo>/<name>.patch, and it will be applied
with 'patch -p1' into the <foo> directory of the unpacked toolchain sources
under build/tools/toolchain-patches/&lt;foo&gt;/&lt;name&gt;.patch, and it will be applied
with 'patch -p1' into the &lt;foo&gt; directory of the unpacked toolchain sources
before the configure step.
- docs/CPU-ARCH-ABIS.TXT: Mention the experimental 'x86' ABI.
- docs/CPU-ARCH-ABIS.html: Mention the experimental 'x86' ABI.
- build/core/mkdeps.sh: Removed obsolete script.
......@@ -371,38 +371,38 @@ OTHER FIXES & CHANGES:
For all platforms:
- <arpa/inet.h>: no longer includes <netinet/in6.h>.
- <ctype.h>: better inlining with -ansi option.
- <mntent.h>: add missing include for <stdio.h>.
- <netinet/in.h>: include <netinet/in6.h> and define in6addr_any +
- &lt;arpa/inet.h&gt;: no longer includes &lt;netinet/in6.h&gt;.
- &lt;ctype.h&gt;: better inlining with -ansi option.
- &lt;mntent.h&gt;: add missing include for &lt;stdio.h&gt;.
- &lt;netinet/in.h&gt;: include &lt;netinet/in6.h&gt; and define in6addr_any +
in6addr_loopback.
- <netinet/in6.h>: add IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP,
- &lt;netinet/in6.h&gt;: add IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP,
IN6ADDR_ANY_INIT, ipv6mr_interface.
- <sys/epoll.h>: add missing C++ inclusion guards.
- <sys/resource.h>: add missing rlim_t declaration.
- <sys/system_properties.h>: add missing C++ inclusion guards.
- <time64.h>: add missing C++ inclusion guards.
- <netdb.h>: move h_errno declaration inside C++ inclusion guards.
- &lt;sys/epoll.h&gt;: add missing C++ inclusion guards.
- &lt;sys/resource.h&gt;: add missing rlim_t declaration.
- &lt;sys/system_properties.h&gt;: add missing C++ inclusion guards.
- &lt;time64.h&gt;: add missing C++ inclusion guards.
- &lt;netdb.h&gt;: move h_errno declaration inside C++ inclusion guards.
- C Library changes:
For android-8 (a.k.a. Android 2.2):
- <dlfcn.h>: add DL_info and dladdr().
- <err.h>: add err(), warn() and other variants.
- <regex.h>, <fts.h>, <sys/queue.h>: added
- <pthread.h>: add pthread_condattr_t
- <sched.h>: added proper clone() declaration (and implementation).
- <signal.h>: added killpg().
- <stdio.h>: add fdprintf() and vfdprintf().
- <stdlib.h>: fix ptsname_r() signature in declaration. previous
- &lt;dlfcn.h&gt;: add DL_info and dladdr().
- &lt;err.h&gt;: add err(), warn() and other variants.
- &lt;regex.h&gt;, &lt;fts.h&gt;, &lt;sys/queue.h&gt;: added
- &lt;pthread.h&gt;: add pthread_condattr_t
- &lt;sched.h&gt;: added proper clone() declaration (and implementation).
- &lt;signal.h&gt;: added killpg().
- &lt;stdio.h&gt;: add fdprintf() and vfdprintf().
- &lt;stdlib.h&gt;: fix ptsname_r() signature in declaration. previous
implementation was broken anyway.
- <unistd.h>: add getusershell(), setusershell(), endusershell(),
- &lt;unistd.h&gt;: add getusershell(), setusershell(), endusershell(),
ttyname(), ttyname_r(), TEMP_FAILURE_RETRY. Fix usleep() signature
(now returns int).
- <wchar.h>: add fake mbstowcs() and wcstombs().
- &lt;wchar.h&gt;: add fake mbstowcs() and wcstombs().
More details available under docs/system/libc/CHANGES.TXT
More details available under docs/system/libc/CHANGES.html
-------------------------------------------------------------------------------
android-ndk-r3
......@@ -462,12 +462,12 @@ IMPORTANT CHANGES:
folder corresponding to the old ABI.
- Updated the STABLE-APIS.TXT document to clarify the OpenGL ES 1.0/1.1/2.0
- Updated the STABLE-APIS.html document to clarify the OpenGL ES 1.0/1.1/2.0
issues regarding specific devices (i.e. 1.0 supported everywhere, 1.1 and
2.0 on specific devices only, need for <uses-feature> tag in manifest).
2.0 on specific devices only, need for &lt;uses-feature&gt; tag in manifest).
OTHER FIXES & CHANGES:
OTHER FIXES AND CHANGES:
- Actually use the awk version detected by host-setup.sh during the build.
......@@ -505,12 +505,12 @@ OTHER FIXES & CHANGES:
- Refresh C library headers for all platforms:
- make <endian.h> simply include <sys/endian.h>
- make <stdint.h> properly declare 64-bit integer types with a C99 compiler
- add missing <sys/types.h> to <strings.h>
- make &lt;endian.h&gt; simply include &lt;sys/endian.h&gt;
- make &lt;stdint.h&gt; properly declare 64-bit integer types with a C99 compiler
- add missing &lt;sys/types.h&gt; to &lt;strings.h&gt;
- add GLibc-compatible macro aliases (st_atimensec, st_mtimensec and
st_ctimensec) to <stat.h>
- add missing declaration for tzset() in <time.h>
st_ctimensec) to &lt;stat.h&gt;
- add missing declaration for tzset() in &lt;time.h&gt;
- Added build/tools/download-toolchain-sources.sh, a script that allows you
to download the toolchain sources from the official open-source repository
......@@ -519,7 +519,7 @@ OTHER FIXES & CHANGES:
binaries for your system.
- Updated build/tools/build-toolchain.sh to support the tarballs generated
by download-toolchain-sources.sh with the --package=<file> option. This
by download-toolchain-sources.sh with the --package=&lt;file&gt; option. This
also builds both gcc 4.2.1 and 4.4.0, adding support for armeabi-v7a to
gcc 4.4.0.
......@@ -558,7 +558,7 @@ IMPORTANT CHANGES:
apps/hello-jni/project/jni/Android.mk
apps/hello-jni/project/jni/hello-jni.c
The 'apps/<name>' directory is still needed in this release though.
The 'apps/&lt;name&gt;' directory is still needed in this release though.
- Change LOCAL_CFLAGS / LOCAL_CPPFLAGS to work as in the full Android build
system. This means that:
......@@ -584,7 +584,7 @@ IMPORTANT CHANGES:
how to make a simple Android application that uses them.
OTHER FIXES & CHANGES
OTHER FIXES AND CHANGES
- Ensure that the __ANDROID__ macro is always defined when building code
with the NDK. Normally, the macro must be defined by the toolchain
......@@ -612,3 +612,4 @@ OTHER FIXES & CHANGES
-------------------------------------------------------------------------------
android-ndk-1.5_r1 released.
</pre></body></html>
\ No newline at end of file
docs/CPU-ARCH-ABIS.TXT → docs/CPU-ARCH-ABIS.html
View file @ adc1d27e
Android Native CPU ABI Management
<html><body><pre>Android Native CPU ABI Management
Introduction:
......@@ -76,7 +76,7 @@ Each supported ABI is identified by a unique name.
Thumb (a.k.a. Thumb-1) instructions are supported. Note that the NDK
will generate thumb code by default, unless you define LOCAL_ARM_MODE
in your Android.mk (see docs/ANDROID-MK.TXT for all details).
in your Android.mk (see docs/ANDROID-MK.html for all details).
I.2. 'armeabi-v7a'
......@@ -104,8 +104,8 @@ Each supported ABI is identified by a unique name.
(Just like one typically does on x86 systems to check/use MMX/SSE2/etc...
specialized instructions).
You can check docs/CPU-FEATURES.TXT to see how to perform these runtime
checks, and docs/CPU-ARM-NEON.TXT to learn about the NDK's support for
You can check docs/CPU-FEATURES.html to see how to perform these runtime
checks, and docs/CPU-ARM-NEON.html to learn about the NDK's support for
building NEON-capable machine code too.
IMPORTANT NOTE: This ABI enforces that all double values are passed during
......@@ -181,18 +181,18 @@ native code in application packages.
It is expected that shared libraries generated with the NDK are stored in
the final application package (.apk) at locations of the form:
lib/<abi>/lib<name>.so
lib/&lt;abi&gt;/lib&lt;name&gt;.so
Where <abi> is one of the ABI names listed in section II above, and <name>
Where &lt;abi&gt; is one of the ABI names listed in section II above, and &lt;name&gt;
is a name that can be used when loading the shared library from the VM
as in:
System.loadLibrary("<name>");
System.loadLibrary("&lt;name&gt;");
Since .apk files are just zip files, you can trivially list their content
with a command like:
unzip -l <apk>
unzip -l &lt;apk&gt;
to verify that the native shared libraries you want are indeed at the
proper location. You can also place native shared libraries at other
......@@ -235,18 +235,19 @@ native code in application packages.
When installing an application, the package manager service will scan
the .apk and look for any shared library of the form:
lib/<primary-abi>/lib<name>.so
lib/&lt;primary-abi&gt;/lib&lt;name&gt;.so
If one is found, then it is copied under $APPDIR/lib/lib<name>.so,
If one is found, then it is copied under $APPDIR/lib/lib&lt;name&gt;.so,
where $APPDIR corresponds to the application's specific data directory.
If none is found, and a secondary ABI is defined, the service will
then scan for shared libraries of the form:
lib/<secondary-abi>/lib<name>.so
lib/&lt;secondary-abi&gt;/lib&lt;name&gt;.so
If anything is found, then it is copied under $APPDIR/lib/lib<name>.so
If anything is found, then it is copied under $APPDIR/lib/lib&lt;name&gt;.so
This mechanism ensures that the best machine code for the target
device is automatically extracted from the package at installation
time.
</pre></body></html>
\ No newline at end of file
docs/CPU-ARM-NEON.TXT → docs/CPU-ARM-NEON.html
View file @ adc1d27e
Android NDK & ARM NEON instruction set extension support
<html><body><pre>Android NDK &amp; ARM NEON instruction set extension support
--------------------------------------------------------
Introduction:
......@@ -16,7 +16,7 @@ that allows native code to use two useful instruction set extensions:
More specifically, by default 'armeabi-v7a' only supports
VFPv3-D16 which only uses/requires 16 hardware FPU 64-bit registers.
More information about this can be read in docs/CPU-ARCH-ABIS.TXT
More information about this can be read in docs/CPU-ARCH-ABIS.html
The ARMv7 Architecture Reference Manual also defines another optional
instruction set extension known as "ARM Advanced SIMD", nick-named
......@@ -92,19 +92,19 @@ It is thus crucial to perform runtime detection to know if the NEON-capable
machine code can be run on the target device.
To do that, use the 'cpufeatures' library that comes with this NDK. To lean
more about it, see docs/CPU-FEATURES.TXT.
more about it, see docs/CPU-FEATURES.html.
You should explicitly check that android_getCpuFamily() returns
ANDROID_CPU_FAMILY_ARM, and that android_getCpuFeatures() returns a value
that has the ANDROID_CPU_ARM_FEATURE_NEON flag set, as in:
#include <cpu-features.h>
#include &lt;cpu-features.h&gt;
...
...
if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM &&
(android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON) != 0)
if (android_getCpuFamily() == ANDROID_CPU_FAMILY_ARM &amp;&amp;
(android_getCpuFeatures() &amp; ANDROID_CPU_ARM_FEATURE_NEON) != 0)
{
// use NEON-optimized routines
...
......@@ -125,3 +125,4 @@ on how to use the 'cpufeatures' library and Neon intrinsics at the same time.
This implements a tiny benchmark for a FIR filter loop using a C version, and
a NEON-optimized one for devices that support it.
</pre></body></html>
\ No newline at end of file
docs/CPU-FEATURES.TXT → docs/CPU-FEATURES.html
View file @ adc1d27e
Android NDK CPU Features detection library:
<html><body><pre>Android NDK CPU Features detection library:
-------------------------------------------
This NDK provides a small library named "cpufeatures" that can be used at
......@@ -21,17 +21,17 @@ To use it, you must:
$(call import-module,android/cpufeatures)
* In your source code, include the header named <cpu-features.h>
* In your source code, include the header named &lt;cpu-features.h&gt;
Here is a simple example:
<project-path>/jni/Android.mk:
&lt;project-path&gt;/jni/Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := <your-module-name>
LOCAL_SRC_FILES := <your-source-files>
LOCAL_MODULE := &lt;your-module-name&gt;
LOCAL_SRC_FILES := &lt;your-source-files&gt;
LOCAL_STATIC_LIBRARIES := cpufeatures
include $(BUILD_SHARED_LIBRARY)
......@@ -59,7 +59,7 @@ Currently, only the following flags are defined, for the ARM CPU Family:
ANDROID_CPU_ARM_FEATURE_ARMv7
Indicates that the device's CPU supports the ARMv7-A instruction
set as supported by the "armeabi-v7a" abi (see CPU-ARCH-ABIS.TXT).
set as supported by the "armeabi-v7a" abi (see CPU-ARCH-ABIS.html).
This corresponds to Thumb-2 and VFPv3-D16 instructions.
ANDROID_CPU_ARM_FEATURE_VFPv3
......@@ -91,3 +91,4 @@ Change History:
Please see the comments in $NDK/sources/android/cpufeatures/cpu-features.c
for the complete change history for this library.
</pre></body></html>
\ No newline at end of file
docs/DEVELOPMENT.TXT → docs/DEVELOPMENT.html
View file @ adc1d27e
NDK Development:
<html><body><pre>NDK Development:
----------------
This document describes how one can modify the NDK and generate
......@@ -141,13 +141,13 @@ several ways to get them:
the script when it completes its operation and should be something
like:
/tmp/android-ndk-toolchain-<date>.tar.bz2
/tmp/android-ndk-toolchain-&lt;date&gt;.tar.bz2
Note that if you don't use the --package option, you will need to
provide the name of a directory where the patched sources will be
copied instead, as in:
$NDK/build/tools/download-toolchain-sources.sh <target-src-dir>
$NDK/build/tools/download-toolchain-sources.sh &lt;target-src-dir&gt;
3.b/ Build the binaries:
......@@ -156,20 +156,20 @@ several ways to get them:
tarball that was created in the previous section with the --package
option:
$NDK/build/tools/rebuild-all-prebuilt.sh --toolchain-pkg=<file>
$NDK/build/tools/rebuild-all-prebuilt.sh --toolchain-pkg=&lt;file&gt;
Where <file> points to the package generated by the
Where &lt;file&gt; points to the package generated by the
download-toolchain-sources.sh script.
In the case where you downloaded the sources to a directory instead,
use the --toolchain-src-dir option instead, as with:
$NDK/build/tools/rebuild-all-prebuilt.sh --toolchain-src-dir=<path>
$NDK/build/tools/rebuild-all-prebuilt.sh --toolchain-src-dir=&lt;path&gt;
This will rebuild all the prebuilt binaries for your host platforms
and place them in a directory named:
/tmp/ndk-prebuilt/prebuilt-<date>/
/tmp/ndk-prebuilt/prebuilt-&lt;date&gt;/
These binary packages include the following:
......@@ -183,7 +183,7 @@ several ways to get them:
To generate Windows binaries on Windows, install the "mingw32"
package on your system, then use the --mingw option, as in:
$NDK/build/tools/rebuild-all-prebuilt.sh --mingw --toolchain-pkg=<file>
$NDK/build/tools/rebuild-all-prebuilt.sh --mingw --toolchain-pkg=&lt;file&gt;
Note that device-specific binaries (e.g. gdbserver) cannot be
rebuilt with this option.
......@@ -194,10 +194,10 @@ several ways to get them:
for example:
cd $NDK
tar xjf <path>/*.tar.bz2
tar xjf &lt;path&gt;/*.tar.bz2
Where <path> is a directory containing all the tarballs (e.g. it
could be simply /tmp/ndk-prebuilt/prebuilt-<date>)
Where &lt;path&gt; is a directory containing all the tarballs (e.g. it
could be simply /tmp/ndk-prebuilt/prebuilt-&lt;date&gt;)
This will put the corresponding files at the correct location.
......@@ -211,13 +211,13 @@ several ways to get them:
This will generate a package file containing all the prebuilts, that
can be unpacked directly into your $NDK directory. The package name is
printed at the end, e.g."android-ndk-prebuild-<date>-<system>.tar.bz2".
printed at the end, e.g."android-ndk-prebuild-&lt;date&gt;-&lt;system&gt;.tar.bz2".
Where <date> is the current date, and <system> is your system name.
Where &lt;date&gt; is the current date, and &lt;system&gt; is your system name.
Then, to unpack:
cd $NDK k
tar xjf /tmp/android-ndk-prebuilt-<date>-<system>.tar.bz2
tar xjf /tmp/android-ndk-prebuilt-&lt;date&gt;-&lt;system&gt;.tar.bz2
The generated package can easily be shared with other people.
......@@ -254,9 +254,9 @@ ways to do that:
Do the following:
cd $NDK
build/tools/package-release.sh --prebuilt-ndk=<file>
build/tools/package-release.sh --prebuilt-ndk=&lt;file&gt;
Where <file> points to a previous NDK package (i.e. archive file).
Where &lt;file&gt; points to a previous NDK package (i.e. archive file).
NOTE: This method can only be used to generate a single release package
for the current host system.
......@@ -272,26 +272,27 @@ ways to do that:
do the following:
cd $NDK
build/tools/package-release.sh --prebuilt-dir=<path>
build/tools/package-release.sh --prebuilt-dir=&lt;path&gt;
The generated NDK package release will have a name that looks like:
/tmp/ndk-release/android-ndk-<release>-<system>.zip
/tmp/ndk-release/android-ndk-&lt;release&gt;-&lt;system&gt;.zip
Where <release> is by default the current date in ISO format
(e.g. 20100915), and <system> corresponds to the host system where the
Where &lt;release&gt; is by default the current date in ISO format
(e.g. 20100915), and &lt;system&gt; corresponds to the host system where the
NDK release is supposed to run.
The script 'package-release.sh' provides a few additional options:
--release=<name> Change the name of the release
--release=&lt;name&gt; Change the name of the release
--systems=<list> Change the list of host systems to package for
--systems=&lt;list&gt; Change the list of host systems to package for
--platforms=<list> List of API levels to package in the NDK
--platforms=&lt;list&gt; List of API levels to package in the NDK
--out-dir=<path> Specify a different output directory for the
--out-dir=&lt;path&gt; Specify a different output directory for the
final packages (instead of /tmp/ndk-release)
Use --help to list them all.
</pre></body></html>
\ No newline at end of file
docs/HOWTO.TXT → docs/HOWTO.html
View file @ adc1d27e
Android NDK How-To:
<html><body><pre>Android NDK How-To:
===================
A collection of tips and tricks for NDK users
......@@ -37,9 +37,9 @@ How to build a project's native files without cd-ing to it:
Sometimes, you may need to rebuild a project's native file without
being able to cd to its top-level path from the command-line. This
is do-able by using the GNU-Make '-C <path>' option, as in:
is do-able by using the GNU-Make '-C &lt;path&gt;' option, as in:
ndk-build -C <project-path>
ndk-build -C &lt;project-path&gt;
How to store your Application.mk in a location other than $PROJECT/jni:
......@@ -53,7 +53,7 @@ use a GNU Make variable override as:
ndk-build NDK_APPLICATION_MK=/path/to/your/Application.mk
If you're using the legacy $NDK/apps/<name> build method, you can create
If you're using the legacy $NDK/apps/&lt;name&gt; build method, you can create
a symbolic link to your final Application.mk there. For example, imagine
that you wrote:
......@@ -61,17 +61,17 @@ that you wrote:
You can create a symlink like with a command like:
ln -s $PROJECT/foo $NDK/apps/<name>
ln -s $PROJECT/foo $NDK/apps/&lt;name&gt;
This will make $NDK/apps/<name>/Application.mk point directly to
This will make $NDK/apps/&lt;name&gt;/Application.mk point directly to
$PROJECT/jni/Application.mk
Note that generated files will still go under $NDK/out/apps/<name> though.
Note that generated files will still go under $NDK/out/apps/&lt;name&gt; though.
Windows users: The NDK is only supported on Cygwin, which implements
symbolic links through the "ln -s" command, as in:
ln -s <target> <link>
ln -s &lt;target&gt; &lt;link&gt;
How to properly add include directories to your module declaration:
......@@ -90,7 +90,7 @@ the following example:
Android.mk
bar.c
Where the 'bar.c' uses '#include <foo.h>'. You will need to add the
Where the 'bar.c' uses '#include &lt;foo.h&gt;'. You will need to add the
path to the 'foo' module in jni/bar/Android.mk to build it properly.
One is tempted to use the following:
......@@ -116,3 +116,4 @@ point to your project directory:
However, we don't recommend using this, paths relative to $(LOCAL_PATH)
being better.
</pre></body></html>
\ No newline at end of file
docs/IMPORT-MODULE.TXT → docs/IMPORT-MODULE.html
View file @ adc1d27e
Android module paths (sharing code made easy):
<html><body><pre>Android module paths (sharing code made easy):
==============================================
Starting from r5, the Android NDK comes with a cool feature that allows
......@@ -24,28 +24,28 @@ In practice, here's how this works:
2. To import a module, place a line like the following to, preferably at
the *end* of, your Android.mk:
$(call import-module,<tag>)
$(call import-module,&lt;tag&gt;)
This will look for <tag>/Android.mk under any of the directories
This will look for &lt;tag&gt;/Android.mk under any of the directories
listed in your NDK_MODULE_PATH.
(The reason why it must be at the end is to avoid messing with
the results of the 'my-dir' function. See its description in
docs/ANDROID-MK.TXT for details).
docs/ANDROID-MK.html for details).
3. Declare that your project's modules depend on the imported one by
listing them in either your LOCAL_STATIC_LIBRARIES or
LOCAL_SHARED_LIBRARIES. For example:
LOCAL_STATIC_LIBRARIES += <tag>
LOCAL_STATIC_LIBRARIES += &lt;tag&gt;
4. Rebuild!
Remember that NDK r5 also added the ability for a module to "export"
declarations to other modules that depend on it (for example, see the
definition of LOCAL_EXPORT_CFLAGS in docs/ANDROID-MK.TXT).
definition of LOCAL_EXPORT_CFLAGS in docs/ANDROID-MK.html).
A well-written module will correctly export all the things its
dependees need, et voila.
......@@ -66,13 +66,13 @@ The NDK_MODULE_PATH variable must contain a list of directories.
* On Windows, use '/' as the directory separator.
The directories of NDK_MODULE_PATH will be searched in order. The first
<path>/<tag>/Android.mk file that is found during the lookup will be
&lt;path&gt;/&lt;tag&gt;/Android.mk file that is found during the lookup will be
included automatically.
As a convenience, $NDK/sources is appended to your NDK_MODULE_PATH
definition by the NDK build system. This allows you to easily import
the helper libraries that come with it (see docs/CPU-FEATURES.TXT for
the helper libraries that come with it (see docs/CPU-FEATURES.html for
a practical example).
......@@ -113,7 +113,7 @@ build directory, e.g. $PROJECT_PATH/obj/).
You can however distribute prebuilt binaries in your import module with
the new PREBUILT_STATIC_LIBRARIES or PREBUILT_SHARED_LIBRARIES feature
(see docs/ANDROID-MK.TXT).
(see docs/ANDROID-MK.html).
This makes it easy to package and redistribute your import module directory
to third-parties.
......@@ -131,11 +131,11 @@ your import module:
Your imported Android.mk can define any number of modules, with
any name. As a consequence, there is no direct relationship between
<name> in the following line:
&lt;name&gt; in the following line:
$(call import-module,<tag>/<name>)
$(call import-module,&lt;tag&gt;/&lt;name&gt;)
And the names of the modules defined under <tag>/<name>/Android.mk.
And the names of the modules defined under &lt;tag&gt;/&lt;name&gt;/Android.mk.
IN CASE OF DOUBT, KEEP IT SIMPLE!
......@@ -154,7 +154,7 @@ your import module:
include $(CLEAR_VARS)
LOCAL_MODULE := bar_static
LOCAL_SRC_FILES := bar.c
# Ensure our dependees can include <bar.h> too
# Ensure our dependees can include &lt;bar.h&gt; too
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
include $(BUILD_STATIC_LIBRARY)
......@@ -184,7 +184,7 @@ your import module:
- The module namespace is flat, so try to give your modules names that
are likely to not collide with other. Note that your can use
LOCAL_MODULE_FILENAME to give the name of your module's binary
file, independently from its LOCAL_MODULE (see docs/ANDROID-MK.TXT
file, independently from its LOCAL_MODULE (see docs/ANDROID-MK.html
for definition and usage). For example:
include $(CLEAR_VARS)
......@@ -213,14 +213,14 @@ your import module:
}
IV. Tips & Recommendations:
IV. Tips &amp; Recommendations:
---------------------------
* You don't need to import a module before you can reference it!
* Use import-module at the *end* of your Android.mk to avoid messing with
the result of 'my-dir'. See the description of this function in
docs/ANDROID-MK.TXT to understand why.
docs/ANDROID-MK.html to understand why.
* It is *strongly* suggested to use a subdirectory for your import tags,
that describes its origin, as in:
......@@ -234,3 +234,4 @@ IV. Tips & Recommendations:
IMPORTANT: THE 'android' IMPORT DIRECTORY, AND ANY OF ITS SUB-DIRECTORIES
IS *RESERVED* FOR NDK USAGE. FEEL FREE TO ORGANIZE YOUR OTHER
IMPORT MODULES AS YOU WANT OTHERWISE.
</pre></body></html>
\ No newline at end of file
docs/INSTALL.TXT → docs/INSTALL.html
View file @ adc1d27e
Android NDK Installation
<html><body><pre>Android NDK Installation
Introduction:
-------------
Please read docs/OVERVIEW.TXT to understand what the Android NDK is and is not.
Please read docs/OVERVIEW.html to understand what the Android NDK is and is not.
This file gives instructions on how to properly setup your NDK.
......@@ -56,3 +56,4 @@ configure the NDK. However, this step has been removed in release 4 (a.k.a. r4).
The auto-detection and sanity checks that were performed by the script have
been moved into the NDK makefiles (and are now performed each time you invoke
GNU Make).
</pre></body></html>
\ No newline at end of file
docs/LICENSES.TXT → docs/LICENSES.html
View file @ adc1d27e
The content of the Android NDK is covered by various open-source licenses.
<html><body><pre>The content of the Android NDK is covered by various open-source licenses.
See the copyright disclaimers in each respective file for details.
Note that the public Android NDK release packages also contain prebuilt binaries
......@@ -7,4 +7,5 @@ available at http://android.git.kernel.org/pub
The prebuilt binaries are covered by either the GNU General Public License (GPL),
or the GNU Lesser General Public License (LGPL). For details, see the files
COPYING and COPYING.LIB under 'build/prebuilt/<system>/<toolchain>'
COPYING and COPYING.LIB under 'build/prebuilt/&lt;system&gt;/&lt;toolchain&gt;'
</pre></body></html>
\ No newline at end of file
docs/NDK-BUILD.TXT → docs/NDK-BUILD.html
View file @ adc1d27e
'ndk-build' Overview
<html><body><pre>'ndk-build' Overview
I. Usage:
---------
......@@ -23,30 +23,30 @@ II. Options:
All parameters to 'ndk-build' are passed directly to the underlying GNU Make
command that runs the NDK build scripts. Notable uses include:
ndk-build --> rebuild required machine code.
ndk-build clean --> clean all generated binaries.
ndk-build --&gt; rebuild required machine code.
ndk-build clean --&gt; clean all generated binaries.
ndk-build NDK_DEBUG=1 --> generate debuggable native code.
ndk-build NDK_DEBUG=1 --&gt; generate debuggable native code.
ndk-build V=1 --> launch build, displaying build commands.
ndk-build V=1 --&gt; launch build, displaying build commands.
ndk-build -B --> force a complete rebuild.
ndk-build -B --&gt; force a complete rebuild.
ndk-build -B V=1 --> force a complete rebuild and display build
ndk-build -B V=1 --&gt; force a complete rebuild and display build
commands.
ndk-build NDK_LOG=1 --> display internal NDK log messages
ndk-build NDK_LOG=1 --&gt; display internal NDK log messages
(used for debugging the NDK itself).
ndk-build NDK_DEBUG=1 --> force a debuggable build (see below)
ndk-build NDK_DEBUG=0 --> force a release build (see below)
ndk-build NDK_DEBUG=1 --&gt; force a debuggable build (see below)
ndk-build NDK_DEBUG=0 --&gt; force a release build (see below)
ndk-build NDK_APP_APPLICATION_MK=<file>
--> rebuild, using a specific Application.mk pointed to by
ndk-build NDK_APP_APPLICATION_MK=&lt;file&gt;
--&gt; rebuild, using a specific Application.mk pointed to by
the NDK_APP_APPLICATION_MK command-line variable.
ndk-build -C <project> --> build the native code for the project
path located at <project>. Useful if you
ndk-build -C &lt;project&gt; --&gt; build the native code for the project
path located at &lt;project&gt;. Useful if you
don't want to 'cd' to it in your terminal.
......@@ -57,12 +57,12 @@ In NDK r5, ndk-build has been modified to make it easier to switch between
release and debug builds. This is done by using the NDK_DEBUG variable.
For example:
$NDK/ndk-build NDK_DEBUG=1 => forces the generation of debug binaries
$NDK/ndk-build NDK_DEBUG=0 => forces the generation of release binaries
$NDK/ndk-build NDK_DEBUG=1 =&gt; forces the generation of debug binaries
$NDK/ndk-build NDK_DEBUG=0 =&gt; forces the generation of release binaries
If you don't specify NDK_DEBUG, ndk-build will keep its default behaviour,
which is to inspect the AndroidManifest.xml, if any, and see if its
<application> element has android:debuggable="true".
&lt;application&gt; element has android:debuggable="true".
IMPORTANT: If you use the build tools of SDK r8 (or higher), you
won't need to touch your AndroidManifest.xml file at all!
......@@ -73,8 +73,8 @@ IMPORTANT: If you use the build tools of SDK r8 (or higher), you
generated with NDK_DEBUG=1.
Also, as a convenience, the release and debug object files generated by the
NDK are now stored in different directories (e.g. obj/local/<abi>/objs and
obj/local/<abi>/objs-debug). This avoids having to recompile all your sources
NDK are now stored in different directories (e.g. obj/local/&lt;abi&gt;/objs and
obj/local/&lt;abi&gt;/objs-debug). This avoids having to recompile all your sources
when you switch between these two modes (even when you only modified one or
two source files).
......@@ -113,3 +113,4 @@ NDK installation directory.
Use this knowledge if you want to invoke the NDK build script from other
shell scripts (or even your own Makefiles).
</pre></body></html>
\ No newline at end of file
docs/NDK-GDB.TXT → docs/NDK-GDB.html
View file @ adc1d27e
'ndk-gdb' Overview
<html><body><pre>'ndk-gdb' Overview
I. Usage:
---------
......@@ -20,12 +20,12 @@ IMPORTANT: Native debugging can only work if *all* these conditions are met:
1. Your application is built with the 'ndk-build' script:
Building with the legacy "make APP=<name>" method is not
Building with the legacy "make APP=&lt;name&gt;" method is not
supported by ndk-gdb.
2. Your application is debuggable:
In other words, your AndroidManifest.xml has an <application>
In other words, your AndroidManifest.xml has an &lt;application&gt;
element that sets the android:debuggable attribute to "true"
3. You are running your application on Android 2.2 (or higher):
......@@ -70,7 +70,7 @@ message if it finds a problem. For example, it:
By default, ndk-gdb will search for an already-running application process,
and will dump an error if it doesn't find one. You can however use the --start
or --launch=<name> option to automatically start your activity before the
or --launch=&lt;name&gt; option to automatically start your activity before the
debugging session.
When it successfully attaches to your application process, ndk-gdb will give
......@@ -78,7 +78,7 @@ you a normal GDB prompt, after setting up the session to properly look for
your source files and symbol/debug versions of your generated native
libraries.
You can set breakpoints with 'b <location>' and resume execution with 'c'
You can set breakpoints with 'b &lt;location&gt;' and resume execution with 'c'
(for 'continue'). See the GDB manual for a list of commands.
IMPORTANT: When quitting the GDB prompt, your debugged application process
......@@ -114,10 +114,10 @@ To see a list of options, type 'ndk-gdb --help'. Notable ones are:
explicitly launch your application before the debugging session.
NOTE: This launches the first launchable activity listed from your
application manifest. Use --launch=<name> to start another one.
application manifest. Use --launch=&lt;name&gt; to start another one.
See --launch-list to dump the list of such activities.
--launch=<name>:
--launch=&lt;name&gt;:
This is similar to --start, except that it allows you to start a specific
activity from your application. This is only useful if your manifest
defines several launchable activities.
......@@ -126,37 +126,37 @@ To see a list of options, type 'ndk-gdb --help'. Notable ones are:
Convenience option that prints the list of all launchable activity names
found in your application manifest. The first one will be used by --start
--project=<path>:
--project=&lt;path&gt;:
Specify application project directory. Useful if you want to launch
the script without cd-ing to the directory before that.
--port=<port>:
--port=&lt;port&gt;:
By default, ndk-gdb will use local TCP port 5039 to communicate with
the debugged application. By using a different port, it is possible
to natively debug programs running on different devices/emulators
connected to the same development machine.
--adb=<file>:
--adb=&lt;file&gt;:
Specify the adb tool executable, in case it is not in your path.
-d, -e, -s <serial>:
-d, -e, -s &lt;serial&gt;:
These flags are similar to the ADB ones and allow you to handle the
case where you have several devices/emulators connected to your
development machine.
-d: Connect to a single physical device
-e: Connect to a single emulator device
-s <serial>: Connect to a specific device or emulator
where <serial> is the device's name as listed
-s &lt;serial&gt;: Connect to a specific device or emulator
where &lt;serial&gt; is the device's name as listed
by the "adb devices" command.
Alternatively, you can define the ADB_SERIAL environment variable
to list a specific device, without the need for a specific option.
--exec=<file>:
-x <file>:
--exec=&lt;file&gt;:
-x &lt;file&gt;:
After connecting to the debugged process, run the GDB initialization
commands found in <file>. This is useful if you want to do something
commands found in &lt;file&gt;. This is useful if you want to do something
repeatedly, e.g. setting up a list of breakpoints then resuming
execution automatically.
......@@ -169,3 +169,4 @@ Cygwin is required to run it on Windows. We hope to get rid of this
limitation in a future NDK release.
The other NDK requirements apply: e.g. GNU Make 3.81 or higher.
</pre></body></html>
\ No newline at end of file
docs/OVERVIEW.TXT → docs/OVERVIEW.html
View file @ adc1d27e
Android NDK Overview
<html><body><pre>Android NDK Overview
Introduction:
......@@ -29,7 +29,7 @@ implemented in native code through the JNI. In a nutshell, this means that:
- You must provide a native shared library that contains the
implementation of these methods, which will be packaged into your
application's .apk. This library must be named according to standard
Unix conventions as lib<something>.so, and shall contain a standard JNI
Unix conventions as lib&lt;something&gt;.so, and shall contain a standard JNI
entry point (more on this later). For example:
libFileLoader.so
......@@ -66,7 +66,7 @@ Moreover, the Android NDK provides:
supported by the Android platform. This corresponds to definitions that
are guaranteed to be supported in all later releases of the platform.
They are documented in the file docs/STABLE-APIS.TXT
They are documented in the file docs/STABLE-APIS.html
IMPORTANT:
Keep in mind that most of the native system libraries in Android system
......@@ -136,7 +136,7 @@ Android NDK:
project in more details to the build system. You don't need
one to get started though, but this allows you to target
more than one CPU or override compiler/linker flags
(see docs/APPLICATION-MK.TXT for all details).
(see docs/APPLICATION-MK.html for all details).
4/ Build your native code by running "$NDK/ndk-build" from your
project directory, or any of its sub-directories.
......@@ -169,12 +169,12 @@ project.
You are pretty free to organize the content of 'jni' as you want,
the directory names and structure here will not influence the final
generated application packages, so you don't have to use pseudo-unique
names like com.<mycompany>.<myproject> as is the case for application
names like com.&lt;mycompany&gt;.&lt;myproject&gt; as is the case for application
package names.
Note that C and C++ sources are supported. The default C++ file extensions
supported by the NDK is '.cpp', but other extensions can be handled as well
(see docs/ANDROID-MK.TXT for details).
(see docs/ANDROID-MK.html for details).
It is possible to store your sources in a different location by adjusting
your Android.mk file (see below).
......@@ -185,7 +185,7 @@ III.3/ Writing an Android.mk build script:
An Android.mk file is a small build script that you write to describe your
sources to the NDK build system. Its syntax is described in details in
the file docs/ANDROID-MK.TXT.
the file docs/ANDROID-MK.html.
In a nutshell, the NDK groups your sources into "modules", where each module
can be one of the following:
......@@ -217,7 +217,7 @@ III.4/ Writing an Application.mk build file (optional):
While an Android.mk file describes your modules to the build system, the
Application.mk file describes your application itself. See the
docs/APPLICATION-MK.TXT document to understand what this file allows you
docs/APPLICATION-MK.html document to understand what this file allows you
to do. This includes, among others:
- The exact list of modules required by your application.
......@@ -237,9 +237,9 @@ There are two ways to use an Application.mk:
- Place it under $PROJECT/jni/Application.mk, and it will be picked
up automatically by the 'ndk-build' script (more on this later)
- Place it under $NDK/apps/<name>/Application.mk, where $NDK
- Place it under $NDK/apps/&lt;name&gt;/Application.mk, where $NDK
points to your NDK installation path. After that, launch
"make APP=<name>" from the NDK directory.
"make APP=&lt;name&gt;" from the NDK directory.
This was the way this file was used before Android NDK r4.
It is still supported for compatibility reasons, but we strongly
......@@ -247,7 +247,7 @@ There are two ways to use an Application.mk:
simpler and doesn't need modifying / changing directories of the
NDK installation tree.
Again, see docs/APPLICATION-MK.TXT for a complete description of its
Again, see docs/APPLICATION-MK.html for a complete description of its
content.
......@@ -281,8 +281,8 @@ purposes, there is no need to copy unstripped binaries to a device).
For example:
ndk-build
ndk-build clean --> clean generated binaries
ndk-build -B V=1 --> force complete rebuild, showing commands
ndk-build clean --&gt; clean generated binaries
ndk-build -B V=1 --&gt; force complete rebuild, showing commands
By default, it expects an optional file under $PROJECT/jni/Application.mk,
and a required $PROJECT/jni/Android.mk.
......@@ -292,11 +292,11 @@ purposes, there is no need to copy unstripped binaries to a device).
rebuild the full Android application package either through the usual
'ant' command, or the ADT Eclipse plug-in.
See docs/NDK-BUILD.TXT for a more complete description of what this script
See docs/NDK-BUILD.html for a more complete description of what this script
does and which options it can take.
2: Using the $NDK/apps/<name>/Application.mk:
2: Using the $NDK/apps/&lt;name&gt;/Application.mk:
---------------------------------------------
This build method was the only one before Android NDK r4 and is only
......@@ -306,13 +306,13 @@ purposes, there is no need to copy unstripped binaries to a device).
It requires the following:
1. Creating a sub-directory named $NDK/apps/<name>/ under
1. Creating a sub-directory named $NDK/apps/&lt;name&gt;/ under
your NDK installation directory (not your project path).
Where <name> is an arbitrary name to describe your application
Where &lt;name&gt; is an arbitrary name to describe your application
to the NDK build system (no spaces allowed).
2. Write $NDK/apps/<name>/Application.mk, which then requires
2. Write $NDK/apps/&lt;name&gt;/Application.mk, which then requires
a definition for APP_PROJECT_PATH that points to your
application project directory.
......@@ -320,10 +320,10 @@ purposes, there is no need to copy unstripped binaries to a device).
invoke the top-level GNUMakefile, as in:
cd $NDK
make APP=<name>
make APP=&lt;name&gt;
The result will be equivalent to the first method, except for the fact
that intermediate generated files will be placed under $NDK/out/apps/<name>/
that intermediate generated files will be placed under $NDK/out/apps/&lt;name&gt;/
IV. Rebuild your application package:
......@@ -349,7 +349,7 @@ Native debugging can *ONLY* be performed on production devices running
Android 2.2 or higher, and does not require root or privileged access, as
long as your application is debuggable.
For more information, read docs/NDK-GDB.TXT. In a nutshell, native debugging
For more information, read docs/NDK-GDB.html. In a nutshell, native debugging
follows this simple scheme:
1. Ensure your application is debuggable (e.g. set android:debuggable
......@@ -364,3 +364,4 @@ follows this simple scheme:
You will get a gdb prompt. See the GDB User Manual for a list of useful
commands.
</pre></body></html>
\ No newline at end of file
docs/PREBUILTS.TXT → docs/PREBUILTS.html
View file @ adc1d27e
NDK Prebuilt library support:
<html><body><pre>NDK Prebuilt library support:
-----------------------------
Android NDK r5 introduced support for prebuilt libraries (shared and
......@@ -47,7 +47,7 @@ Notice that, to declare such a module, you really only need the following:
A prebuilt module does not build anything. However, a copy of your prebuilt
shared library will be copied into $PROJECT/obj/local, and another will be
copied and stripped into $PROJECT/libs/<abi>.
copied and stripped into $PROJECT/libs/&lt;abi&gt;.
II. Referencing the prebuilt library in other modules:
------------------------------------------------------
......@@ -74,7 +74,7 @@ found in a header file distributed with the prebuilt library (e.g. "foo.h").
In other words, foo-user.c is going to have a line like:
#include <foo.h>
#include &lt;foo.h&gt;
And you need to provide the header and its include path to the compiler
when building the foo-user module.
......@@ -99,7 +99,7 @@ IV. Debugging prebuilt binaries:
--------------------------------
We recommend you to provide prebuilt shared libraries that contain debug
symbols. The version that is installed into $PROJECT/libs/<abi>/ is always
symbols. The version that is installed into $PROJECT/libs/&lt;abi&gt;/ is always
stripped by the NDK build system, but the debug version will be used for
debugging purposes with ndk-gdb.
......@@ -111,9 +111,9 @@ As said previously, it is crucial to provide a prebuilt shared library
that is compatible with the targetted ABI during the build. To do that,
check for the value of TARGET_ARCH_ABI, its value will be:
armeabi => when targetting ARMv5TE or higher CPUs
armeabi-v7a => when targetting ARMv7 or higher CPUs
x86 => when targetting x86 CPUs
armeabi =&gt; when targetting ARMv5TE or higher CPUs
armeabi-v7a =&gt; when targetting ARMv7 or higher CPUs
x86 =&gt; when targetting x86 CPUs
Note that armeabi-v7a systems can run armeabi binaries just fine.
......@@ -129,11 +129,12 @@ and select which one to copy based on the target ABI:
Here. we assume that the prebuilt libraries to copy are under the
following directory hierarchy:
Android.mk --> the file above
armeabi/libfoo.so --> the armeabi prebuilt shared library
armeabi-v7a/libfoo.so --> the armeabi-v7a prebuilt shared library
include/foo.h --> the exported header file
Android.mk --&gt; the file above
armeabi/libfoo.so --&gt; the armeabi prebuilt shared library
armeabi-v7a/libfoo.so --&gt; the armeabi-v7a prebuilt shared library
include/foo.h --&gt; the exported header file
NOTE: Remember that you don't need to provide an armeabi-v7a prebuilt
library, since an armeabi one can easily run on the corresponding
devices.
</pre></body></html>
\ No newline at end of file
docs/STABLE-APIS.TXT → docs/STABLE-APIS.html
View file @ adc1d27e
Android NDK Stable APIs:
<html><body><pre>Android NDK Stable APIs:
========================
This is the list of stable APIs/ABIs exposed by the Android NDK.
......@@ -11,7 +11,7 @@ that contains the corresponding implementation, and which must be linked
against by your native code.
For example, to use system library "Foo", you would include a header
like <foo.h> in your code, then tell the build system that your native
like &lt;foo.h&gt; in your code, then tell the build system that your native
module needs to link to /system/lib/libfoo.so at load-time by adding
the following line to your Android.mk file:
......@@ -25,20 +25,20 @@ There are several "API Levels" defined. Each API level corresponds to
a given Android system platform release. The following levels are
currently supported:
android-3 -> Official Android 1.5 system images
android-4 -> Official Android 1.6 system images
android-5 -> Official Android 2.0 system images
android-6 -> Official Android 2.0.1 system images
android-7 -> Official Android 2.1 system images
android-8 -> Official Android 2.2 system images
android-9 -> Official Android 2.3 system images
android-3 -&gt; Official Android 1.5 system images
android-4 -&gt; Official Android 1.6 system images
android-5 -&gt; Official Android 2.0 system images
android-6 -&gt; Official Android 2.0.1 system images
android-7 -&gt; Official Android 2.1 system images
android-8 -&gt; Official Android 2.2 system images
android-9 -&gt; Official Android 2.3 system images
Note that android-6 and android-7 are the same as android-5 for the NDK,
i.e. they provide exactly the same native ABIs!
IMPORTANT:
The headers corresponding to a given API level are now located
under $NDK/platforms/android-<level>/arch-arm/usr/include
under $NDK/platforms/android-&lt;level&gt;/arch-arm/usr/include
II. Android-3 Stable Native APIs:
......@@ -51,21 +51,21 @@ The C Library:
--------------
The C library headers, as they are defined on Android 1.5 are available
through their standard names (<stdlib.h>, <stdio.h>, etc...). If one header
through their standard names (&lt;stdlib.h&gt;, &lt;stdio.h&gt;, etc...). If one header
is not there at build time, it's because its implementation is not available
on a 1.5 system image.
The build system automatically links your native modules to the C library,
you don't need to add it to LOCAL_LDLIBS.
Note that the Android C library includes support for pthread (<pthread.h>),
Note that the Android C library includes support for pthread (&lt;pthread.h&gt;),
so "LOCAL_LIBS := -lpthread" is not needed. The same is true for real-time
extensions (-lrt on typical Linux distributions).
** VERY IMPORTANT NOTE: ******************************************************
*
* The kernel-specific headers in <linux/...> and <asm/...> are not considered
* The kernel-specific headers in &lt;linux/...&gt; and &lt;asm/...&gt; are not considered
* stable at this point. Avoid including them directly because some of them
* are likely to change in future releases of the platform. This is especially
* true for anything related to specific hardware definitions.
......@@ -76,7 +76,7 @@ extensions (-lrt on typical Linux distributions).
The Math Library:
-----------------
<math.h> is available, and the math library is automatically linked to your
&lt;math.h&gt; is available, and the math library is automatically linked to your
native modules at build time, so there is no need to list "-lm" through
LOCAL_LDLIBS.
......@@ -88,10 +88,10 @@ C++ Library:
An *extremely* minimal C++ support API is available. For Android 1.5, this is
currently limited to the following headers:
<cstddef>
<new>
<utility>
<stl_pair.h>
&lt;cstddef&gt;
&lt;new&gt;
&lt;utility&gt;
&lt;stl_pair.h&gt;
They may not contain all definitions required by the standard. Notably,
support for C++ exceptions and RTTI is not available with Android 1.5 system
......@@ -105,7 +105,7 @@ modules too, so there is no need to list it through LOCAL_LDLIBS
Android-specific Log Support:
-----------------------------
<android/log.h> contains various definitions that can be used to send log
&lt;android/log.h&gt; contains various definitions that can be used to send log
messages to the kernel from your native code. Please have a look at its
content in (build/platforms/android-3/common/include/android/log.h), which
contain many informative comments on how to use it.
......@@ -121,7 +121,7 @@ If you use it, your native module should link to /system/lib/liblog.so with:
ZLib Compression Library:
-------------------------
<zlib.h> and <zconf.h> are available and can be used to use the ZLib
&lt;zlib.h&gt; and &lt;zconf.h&gt; are available and can be used to use the ZLib
compression library. Documentation for it is at the ZLib page:
http://www.zlib.net/manual.html
......@@ -134,7 +134,7 @@ If you use it, your native module should link to /system/lib/libz.so with:
Dynamic Linker Library:
-----------------------
<dlfcn.h> is available and can be used to use the dlopen()/dlsym()/dlclose()
&lt;dlfcn.h&gt; is available and can be used to use the dlopen()/dlsym()/dlclose()
functions provided by the Android dynamic linker. You will need to link
against /system/lib/libdl.so with:
......@@ -151,7 +151,7 @@ on Android 1.6 system images and above,
The OpenGL ES 1.x Library:
--------------------------
The standard OpenGL ES headers <GLES/gl.h> and <GLES/glext.h> contain the
The standard OpenGL ES headers &lt;GLES/gl.h&gt; and &lt;GLES/glext.h&gt; contain the
declarations needed to perform OpenGL ES 1.x rendering calls from native
code.
......@@ -177,7 +177,7 @@ description of glGetString() in the specification to see how to do that:
http://www.khronos.org/opengles/sdk/1.1/docs/man/glGetString.xml
Additionally, developers must put a <uses-feature> tag in their manifest
Additionally, developers must put a &lt;uses-feature&gt; tag in their manifest
file to indicate which version of OpenGL ES their application requires. See
the documentation linked below for details:
......@@ -208,7 +208,7 @@ on Android 2.0 system images and above.
The OpenGL ES 2.0 Library:
--------------------------
The standard OpenGL ES 2.0 headers <GLES2/gl2.h> and <GLES2/gl2ext.h> contain the
The standard OpenGL ES 2.0 headers &lt;GLES2/gl2.h&gt; and &lt;GLES2/gl2ext.h&gt; contain the
declarations needed to perform OpenGL ES 2.0 rendering calls from native code.
This includes the ability to define and use vertex and fragment shaders using the
GLSL language.
......@@ -219,7 +219,7 @@ as in:
LOCAL_LDLIBS := -lGLESv2.so
Not all devices support OpenGL ES 2.0, developers should thus query the
implementation's version and extension strings, and put a <uses-feature>
implementation's version and extension strings, and put a &lt;uses-feature&gt;
tag in their Android manifest. See Section III above for details.
Please note that, at the moment, native headers and libraries for the EGL APIs
......@@ -251,7 +251,7 @@ The 'jnigraphics' Library:
This is a tiny library that exposes a stable, C-based, interface that allows
native code to reliably access the pixel buffers of Java bitmap objects.
To use it, include the <android/bitmap.h> header in your source code, and
To use it, include the &lt;android/bitmap.h&gt; header in your source code, and
and link to the jnigraphics library as in:
LOCAL_LDLIBS += -ljnigraphics
......@@ -279,22 +279,22 @@ V. Android-9 Stable Native APIs:
--------------------------------
All the APIs listed below are available for developing native code that runs
on Android > 2.2 system images and above.
on Android &gt; 2.2 system images and above.
The OpenSL ES native audio Library:
-----------------------------------
The standard OpenSL ES headers <SLES/OpenSLES.h> and <SLES/OpenSLES_Platform.h>
The standard OpenSL ES headers &lt;SLES/OpenSLES.h&gt; and &lt;SLES/OpenSLES_Platform.h&gt;
contain the declarations needed to perform audio input and output from the
native side of Android.
NOTE: Despite the fact that the current OpenSL ES specification uses
<OpenSLES.h> to include these headers, Khronos is currently modifying
the document to recommend <SLES/OpenSLES.h> instead, hence the later
&lt;OpenSLES.h&gt; to include these headers, Khronos is currently modifying
the document to recommend &lt;SLES/OpenSLES.h&gt; instead, hence the later
approach was adopted for Android.
This API level also provides Android-specific extensions, see the content
of <SLES/OpenSLES_Android.h> and <SLES/OpenSLES_AndroidConfiguration.h> for
of &lt;SLES/OpenSLES_Android.h&gt; and &lt;SLES/OpenSLES_AndroidConfiguration.h&gt; for
details.
The system library named "libOpenSLES.so" implements the public native audio
......@@ -312,34 +312,34 @@ that your code does not run inside a VM though, and most of the features
of the platform will still need to be accessed through JNI.
For more information about this topic, please read the dedicated
document named docs/XXXXXXXXX.TXT (TODO: WRITE DOC).
document named docs/NATIVE-ACTIVITY.html (TODO: WRITE DOC).
The following headers correspond to these new native APIs (see comments
inside them for more details):
<android/native_activity.h>
&lt;android/native_activity.h&gt;
Activity lifecycle management (and general entry point)
<android/looper.h>
<android/input.h>
<android/keycodes.h>
<android/sensor.h>
&lt;android/looper.h&gt;
&lt;android/input.h&gt;
&lt;android/keycodes.h&gt;
&lt;android/sensor.h&gt;
To Listen to input events and sensors directly from native code.
<android/rect.h>
<android/window.h>
<android/native_window.h>
<android/native_window_jni.h>
&lt;android/rect.h&gt;
&lt;android/window.h&gt;
&lt;android/native_window.h&gt;
&lt;android/native_window_jni.h&gt;
Window management, including the ability to lock/unlock the pixel
buffer to draw directly into it.
<android/configuration.h>
<android/asset_manager.h>
<android/storage_manager.h>
<android/obb.h>
&lt;android/configuration.h&gt;
&lt;android/asset_manager.h&gt;
&lt;android/storage_manager.h&gt;
&lt;android/obb.h&gt;
Direct (read-only) access to assets embedded in your .apk. or
the Opaque Binary Blob (OBB) files, a new feature of Android X.X
that allows one to distribute large amount of application data
......@@ -349,3 +349,4 @@ All the corresponding functions are provided by the "libandroid.so" library
version that comes with API level 9. To use it, use the following:
LOCAL_LDLIBS += -landroid
</pre></body></html>
\ No newline at end of file
docs/STANDALONE-TOOLCHAIN.TXT → docs/STANDALONE-TOOLCHAIN.html
View file @ adc1d27e
USING THE ANDROID TOOLCHAIN AS A STANDALONE COMPILER
<pre> USING THE ANDROID TOOLCHAIN AS A STANDALONE COMPILER
======================================================
WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
......@@ -32,16 +32,16 @@ This document explains how to do that:
The first thing you need to know is which Android native API level you want
to target. Each one of them provides a different various APIs, which are
documented under doc/STABLE-APIS.TXT, and correspond to the sub-directories
documented under doc/STABLE-APIS.html, and correspond to the sub-directories
of $NDK/platforms.
This allows you to define the path to your 'sysroot', a GCC term for a
directory containing the system headers and libraries of your target.
Usually, this will be something like:
SYSROOT=$NDK/platforms/android-<level>/arch-<arch>/
SYSROOT=$NDK/platforms/android-&lt;level&gt;/arch-&lt;arch&gt;/
Where <level> is the API level number, and <arch> is the architecture ("arm"
Where &lt;level&gt; is the API level number, and &lt;arch&gt; is the architecture ("arm"
being currently supported). For example, if you're targetting Android 2.1
(a.k.a. Froyo), you would use:
......@@ -54,11 +54,12 @@ being currently supported). For example, if you're targetting Android 2.1
Invoke the compiler using the -sysroot option to indicate where the system
files for the platform you're targetting are located. For example, do:
export CC="$NDK/toolchains/<name>/prebuilt/<system>/bin/<prefix>gcc -sysroot $SYSROOT"
export CC="$NDK/toolchains/&lt;name&gt;/prebuilt/&lt;system&gt;/bin/&lt;prefix&gt;gcc -sysroot
$SYSROOT"
$CC -o foo.o -c foo.c
Where <name> is the toolchain's name, <system> is the host tag for your system,
and <prefix> is a toolchain-specific prefix. For example, if you are on Linux
Where &lt;name&gt; is the toolchain's name, &lt;system&gt; is the host tag for your system,
and &lt;prefix&gt; is a toolchain-specific prefix. For example, if you are on Linux
using the NDK r5 toolchain, you would use:
export CC="$NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -sysroot $SYSROOT"
......@@ -83,7 +84,7 @@ You can later use it directly with something like:
export CC=arm-linux-androideabi-gcc
Note that without the --install-dir option, make-standalone-toolchain.sh will
create a tarball in /tmp/ndk/<toolchain-name>.tar.bz2. This allows you to
create a tarball in /tmp/ndk/&lt;toolchain-name&gt;.tar.bz2. This allows you to
archive and redistribute the binaries easily.
Use --help for more options and details.
......@@ -100,7 +101,7 @@ NOTE: You can still use the -sysroot option with the new toolchain, but it
---------------------
The machine code generated by the toolchain should be compatible with
the official Android 'armeabi' ABI (see docs/CPU-ARCH-ABIS.TXT) by default.
the official Android 'armeabi' ABI (see docs/CPU-ARCH-ABIS.html) by default.
It is recommended to use the -mthumb compiler flag to force the generation
of 16-bit Thumb-1 instructions (the default being 32-bit ARM ones).
......@@ -131,7 +132,7 @@ the standalone toolchain, and stick to the NDK build system instead, which
will handle all the details for you.
5/ Warnings & Limitations:
5/ Warnings and Limitations:
--------------------------
5.1/ Windows support:
......@@ -173,3 +174,4 @@ there to help you migrate existing code.
The toolchain binaries currently do *not* support C++ exceptions and RTTI.
Support for these features is planned for a future NDK release.
</pre>
\ No newline at end of file
docs/SYSTEM-ISSUES.TXT → docs/SYSTEM-ISSUES.html
View file @ adc1d27e
Android System Image Issues
<html><body><pre>Android System Image Issues
===========================
This document contains a list of known issues in existing Android
......@@ -16,7 +16,7 @@ No standard C++ library support:
The Android 1.5 system does not use any C++ standard library, and does
not provide one to applicative native code. Instead, a very limited set
of headers are provided (see docs/STABLE-APIS.TXT) which correspond to
of headers are provided (see docs/STABLE-APIS.html) which correspond to
the C++ support code used to build the Android platform.
It is possible to hack existing C++ STL implementations to work on top
......@@ -37,7 +37,7 @@ C Library limitations:
The C library doesn't try to implement every feature under the sun.
Most notably, pthread cancellation is not supported. A detailed overview
of the C library and its design is available in docs/system/libc/OVERVIEW.TXT
of the C library and its design is available in docs/system/libc/OVERVIEW.html
No SysV IPCs in C library:
......@@ -45,7 +45,7 @@ No SysV IPCs in C library:
Unix System V Inter-Process Communication APIs (e.g. semget()) are
intentionally not available from the C library, to avoid denial-of-service
issues. See docs/system/libc/SYSV-IPC.TXT for details.
issues. See docs/system/libc/SYSV-IPC.html for details.
C Library bug: getservbyname() returns port number in incorrect order:
......@@ -71,14 +71,14 @@ my_getservbyname(const char* name, const char* proto)
static int has_bug = -1;
struct servent* ret;
if (has_bug < 0) {
if (has_bug &lt; 0) {
ret = getservbyname("http",NULL);
has_bug = (ret == NULL || ret->s_port == 80);
has_bug = (ret == NULL || ret-&gt;s_port == 80);
}
ret = getservbyname(name, proto);
if (has_bug)
ret->s_port = htons(ret->s_port);
ret-&gt;s_port = htons(ret-&gt;s_port);
}
(the returned struct servent is thread-local and can be modified by the
......@@ -111,3 +111,4 @@ The Android dynamic linker in 1.5 has many important limitations:
libbar.so will always fail, even if you have already loaded libfoo.so
in your process.
</pre></body></html>
\ No newline at end of file
docs/sidenav.html 0 → 100644
View file @ adc1d27e
<html>
<body>
<code>
<h3>Android NDK Dev Guide</h3>
<ul>
<li><a href="OVERVIEW.html" target="content">Android NDK Overview</a></li>
<li><a href="INSTALL.html" target="content">Installation Guide</a></li>
</ul>
<ul>
<li><a href="DEVELOPMENT.html" target="content">Development</a></li>
<li><a href="HOWTO.html" target="content">How To</a></li>
<li><a href="ANDROID-MK.html" target="content">Android.mk File</a></li>
<li><a href="APPLICATION-MK.html" target="content">Application.mk File</a></li>
<li><a href="CPU-ARCH-ABIS.html" target="content">CPU Arch ABIs</a></li>
<li><a href="CPU-ARM-NEON.html" target="content">CPU ARM Neon</a></li>
<li><a href="CPU-FEATURES.html" target="content">CPU Features</a></li>
<li><a href="IMPORT-MODULE.html" target="content">Import Module</a></li>
<li><a href="NDK-BUILD.html" target="content">NDK Build</a></li>
<li><a href="NDK-GDB.html" target="content">NDK GDB</a></li>
<li><a href="PREBUILTS.html" target="content">Prebuilts</a></li>
<li><a href="STABLE-APIS.html" target="content">Stable APIs</a></li>
<li><a href="STANDALONE-TOOLCHAIN.html" target="content">Standalone Toolchain</a></li>
</ul>
<ul>
<li><a href="system/libc/OVERVIEW.html" target="content">Bionic Overview</a></li>
<li><a href="system/libc/SYSV-IPC.html" target="content">SYSV IPC</a></li>
</ul>
<ul>
<li><a href="CHANGES.html" target="content">NDK Changes</a></li>
<li><a href="system/libc/CHANGES.html" target="content">Bionic Changes</a></li>
<li><a href="SYSTEM-ISSUES.html" target="content">System Issues</a></li>
<li><a href="LICENSES.html" target="content">Licenses</a></li>
</ul>
</code>
</body>
</html>
\ No newline at end of file
docs/system/libc/CHANGES.TXT → docs/system/libc/CHANGES.html
View file @ adc1d27e
Bionic ChangeLog:
<html><body><pre>Bionic ChangeLog:
-----------------
Differences between current and Android 2.1:
......@@ -7,48 +7,48 @@ Differences between current and Android 2.1:
- __atomic_swap(): use LDREX/STREX CPU instructions on ARMv6 and higher.
- <arpa/telnet.h>: New header (declarations only, no implementation).
- &lt;arpa/telnet.h&gt;: New header (declarations only, no implementation).
- <err.h>: New header + implementation. GLibc compatibility.
- &lt;err.h&gt;: New header + implementation. GLibc compatibility.
- <warn.h>: New header + implementation. GLibc compatibility.
- &lt;warn.h&gt;: New header + implementation. GLibc compatibility.
- <fts.h>: New header + implementation.
- &lt;fts.h&gt;: New header + implementation.
- <mntent.h>: Add missing <stdio.h> include.
- &lt;mntent.h&gt;: Add missing &lt;stdio.h&gt; include.
- <regex.h>: New header + implementation.
- &lt;regex.h&gt;: New header + implementation.
- <signal.h>: Added killpg()
- &lt;signal.h&gt;: Added killpg()
- <stdint.h>: Allow 64-bit type declarations on C99 builds.
- &lt;stdint.h&gt;: Allow 64-bit type declarations on C99 builds.
- <stdio.h>: Add fdprintf() and vfdprintf(). Note that GLibc provides
- &lt;stdio.h&gt;: Add fdprintf() and vfdprintf(). Note that GLibc provides
the confusing 'dprintf' and 'vdprintf()' functions instead.
- <stdlib.h>: Fix ptsname_r(): the return type is int instead of char*.
- &lt;stdlib.h&gt;: Fix ptsname_r(): the return type is int instead of char*.
The mistake comes from a GLibc man page bug (the man page listed a return
type of char*, while the implementation used int. Fixed in late 2009 only).
The Bionic implementation was incorrect. Technically, this is an ABI
breakage, but code that used this function probably never worked or
compiled properly anyway.
- <strings.h>: Add missing <sys/types.h> include.
- &lt;strings.h&gt;: Add missing &lt;sys/types.h&gt; include.
- <sys/queue.h>: Added new header (no implementation - macro templates).
- &lt;sys/queue.h&gt;: Added new header (no implementation - macro templates).
- <sys/resource.h>: Add rlim_t proper definition.
- &lt;sys/resource.h&gt;: Add rlim_t proper definition.
- <time64.h>: Add missing C++ header inclusion guards.
- &lt;time64.h&gt;: Add missing C++ header inclusion guards.
- <unistd.h>: Add getusershell(), setusershell() and endusershell(), though
- &lt;unistd.h&gt;: Add getusershell(), setusershell() and endusershell(), though
implementation are bogus. GLibc compatibility.
- <wchar.h>: Add mbstowcs() and wcstombs()
- &lt;wchar.h&gt;: Add mbstowcs() and wcstombs()
- add clone() implementation for ARM (x86 and SH-4 not working yet).
- <sys/epoll.h>: <sys/system_properties.h>: Add missing C++ inclusion guards
- &lt;sys/epoll.h&gt;: &lt;sys/system_properties.h&gt;: Add missing C++ inclusion guards
- fix getpwnam() and getpwgrp() to accept "app_0" as a valid user name.
......@@ -70,17 +70,17 @@ Differences between current and Android 2.1:
- add sigaltstack() implementation for ARM.
- <time.h>: Properly implement the 'timezone' and 'daylight' global variables
- &lt;time.h&gt;: Properly implement the 'timezone' and 'daylight' global variables
(they were not defined previously, though declared in the header).
- <time.h>: Fix timezone management implementation to properly update
- &lt;time.h&gt;: Fix timezone management implementation to properly update
'tm_gmtoff' field in 'struct tm' structure.
- DNS: get rid of spurious random DNS queries when trying to resolve
an unknown domain name. Due to an initialization bug, a random DNS search
list was generated for each thread if net.dns.search is not defined.
- <pthread.h>: Add pthread_condattr_init/destroy/setpshared/getpshared functions
- &lt;pthread.h&gt;: Add pthread_condattr_init/destroy/setpshared/getpshared functions
to enable proper shared conditional variable initialization.
Modify the pthread_mutex_t and pthread_cond_t implementation to use private
......@@ -125,12 +125,12 @@ Differences between Android 2.0 and 1.6:
- pthread_cond_timedwait_relative_np(): Same as pthread_cond_timedwait()
but uses a relative timeout instead. Android-specific.
- <netinet/in.h>: Now includes <netinet/in6.h>.
- &lt;netinet/in.h&gt;: Now includes &lt;netinet/in6.h&gt;.
- <netinet/in6.h>: Added IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP, IN6ADDR_ANY_INIT
- &lt;netinet/in6.h&gt;: Added IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP, IN6ADDR_ANY_INIT
and ipv6mr_interface definitions.
- <time.h>:
- &lt;time.h&gt;:
* Add missing tzset() declaration.
* Add Android-specific strftime_tz().
......@@ -141,7 +141,7 @@ Differences between Android 2.0 and 1.6:
- mktime(): Fix an infinite loop problem that appeared when switching to
GCC 4.4.0.
- strftime(): fix incorrect handling of dates > 2038 due to 64-bit issue
- strftime(): fix incorrect handling of dates &gt; 2038 due to 64-bit issue
in original code.
-------------------------------------------------------------------------------
......@@ -153,7 +153,7 @@ Differences between Android 1.6 and 1.5:
- __aeabi_atexit(): Fix implementation to properly call C++ static destructors
when the program exits (or when a shared library is unloaded).
- <sys/stat.h>: added GLibc compatibility macros definitions:
- &lt;sys/stat.h&gt;: added GLibc compatibility macros definitions:
#define st_atimensec st_atime_nsec
#define st_mtimensec st_mtime_nsec
......@@ -172,3 +172,4 @@ Differences between Android 1.6 and 1.5:
- DNS: Support for DNS domain search lists through the new net.dns.search
system property. The corresponding value must be a space-separated list of
domain suffixes.
</pre></body></html>
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment