Home | History | Annotate | Download | only in tools
      1 This directory contains a number of shell scripts, which we will
      2 call the "dev-scripts", that are only used to develop the NDK
      3 itself, i.e. they are un-needed when using ndk-build to build
      4 applicative native code.
      5 
      6 Their purpose is to handle various sophisticated issues:
      7 
      8   - rebuilding host cross-toolchains for our supported CPU ABIs
      9 
     10   - rebuilding other required host tools (e.g. ndk-stack) from sources
     11 
     12   - rebuilding all target-specific prebuilt binaries from sources
     13     (this requires working host cross-toolchains)
     14 
     15   - packaging final NDK release tarballs, including adding samples
     16     and documentation which normally live in $NDK/../development/ndk
     17 
     18 This document is here to explain how to use these dev-scripts and how
     19 everything is architected / designed, in case you want to maintain it.
     20 
     21 
     22 I. Organization:
     23 ----------------
     24 
     25 First, a small description of the NDK's overall directory structure:
     26 
     27   $NDK/build/core
     28     Contains the main NDK build system used when 'ndk-build'.
     29     Relies heavily on GNU Make 3.81+ but isn't used by any of the
     30     scripts described here.
     31 
     32   $NDK/build/tools
     33     Contains all the dev-scripts that are described in this document.
     34     More on this later.
     35 
     36   $NDK/sources/host-tools/
     37     Contains sources of various libraries or programs that will be
     38     compiled to generate useful host programs for the final NDK
     39     installation. For example, $NDK/sources/host-tools/ndk-stack/
     40     contains the sources of the 'ndk-stack' program.
     41 
     42   $NDK/sources/cxx-stl/
     43     Contains the sources of various C++ runtime and libraries that
     44     can be used with 'ndk-build'. See docs/CPLUSPLUS-SUPPORT.html for
     45     more details.
     46 
     47   $NDK/sources/cxx-stl/gabi++/
     48     Contains the sources of the GAbi++ C++ runtime library. Note that
     49     the dev-script 'build-gabi++.sh' can be used to generate prebuilt
     50     libraries from these sources, that will be copied under this
     51     directory.
     52 
     53   $NDK/sources/cxx-stl/stlport/
     54     Contains the sources of a port of STLport that can be used with ndk-build.
     55     The dev-script 'build-stlport.sh' can be used to generate prebuilt
     56     libraries from these sources, that will be copied under this directory.
     57 
     58   $NDK/sources/cxx-stl/gnu-libstdc++/
     59     This directory doesn't contain sources at all, only an Android.mk.
     60     The dev-script 'build-gnu-libstdc++.sh' is used to generate prebuilt
     61     libraries from the sources that are located in the toolchain source
     62     tree instead.
     63 
     64   $NDK/sources/cxx-stl/system/
     65     This directory contains a few headers used to use the native system
     66     Android C++ runtime (with _very_ limited capabilites), a.k.a.
     67     /system/lib/libstdc++.so. The prebuilt version of this library is
     68     generated by the 'gen-platform.sh' dev-script described later, but
     69     it never placed in this directory.
     70 
     71   $NDK/sources/android/libthread_db/
     72     This directory contains the sources of the libthread_db implementation
     73     that is linked into the prebuilt target gdbserver binary. Note that two
     74     versions are provided, corresponding to different versions of gdb.
     75 
     76     The sources are customized versions of the ones found under
     77     $ANDROID/bionic/libthread_db. They contain various changes used to
     78     deal with platform bugs.
     79 
     80   $NDK/sources/
     81     The rest of $NDK/sources/ is used to store the sources of helper
     82     libraries used with 'ndk-build'. For example, the 'cpu-features'
     83     helper library is under $NDK/sources/android/cpu-features/
     84 
     85   $DEVNDK a.k.a $NDK/../development/ndk
     86     This directory contains platform-specific files. The reason why it
     87     it is separate from $NDK is because it is not primarly developed in
     88     the open.
     89 
     90     More specifically:
     91 
     92     - all $NDK development happens in the public AOSP repository ndk.git
     93 
     94     - any $DEVNDK development that happens in the public AOSP development.git
     95       repository is auto-merged to the internal tree maintained by Google
     96 
     97     - $DEVNDK developments that are specific to an yet-unreleased version of
     98       the system happen only in the internal tree. They get back-ported to
     99       the public tree only when the corresponding system release is
    100       open-sourced.
    101 
    102     Having two distinct git repositories makes things easier. Also, you
    103     generally don't want to see the churn that goes in the internal tree
    104     during development. It's usually not very pretty :)
    105 
    106   $DEVNDK/platforms/android-$PLATFORM, where $PLATFORM is a decimal number
    107     Contains all files that are specific to a given API level $PLATFORM,
    108     that were not already defined for the previous API level.
    109 
    110     For example, android-3 corresponds to Android 1.5, and android-4
    111     corresponds to Android 1.6. The platforms/android-4 directory only
    112     contains files that are either new or modified, compared to android-3.
    113 
    114   $DEVNDK/platforms/android-$PLATFORM/include/
    115     Contains all system headers exposed by the NDK for a given platform.
    116     All these headers are independent from the CPU architecture of target devices.
    117 
    118   $DEVNDK/platforms/android-$PLATFORM/arch-$ARCH/
    119     Contains all files that are specific to a given $PLATFORM level and a
    120     specific CPU architecture. $ARCH is typically 'arm' or 'x86'
    121 
    122   $DEVNDK/platforms/android-$PLATFORM/arch-$ARCH/include/
    123     Contains all the architecture-specific headers for a given API level.
    124 
    125   $DEVNDK/platforms/android-$PLATFORM/arch-$ARCH/lib/
    126     Contains several CPU-specific object files and static libraries that
    127     are required to build the host cross-toolchains properly.
    128 
    129     Before NDK r7, this also contains prebuilt system shared libraries that
    130     had been hand-picked from various platform builds. These have been
    131     replaced by symbol list files instead (see below).
    132 
    133   $DEVNDK/platforms/android-$PLATFORM/arch-$ARCH/symbols/
    134     Contains, for each system shared library exposed by the NDK, two
    135     files describing the dynamic symbols it exports, for example, for
    136     the C library:
    137 
    138        libc.so.functions.txt -> list of exported function names
    139        libc.so.variables.txt -> list of exported variable names
    140 
    141     These files were introduced in NDK r7 and are used to generate "shell"
    142     shared libraries that can be used by ndk-build at link time. The shell
    143     libraries only provide dynamic symbols to 
    144 
    145     These files can be generated from a given platform build using the
    146     'dev-platform-import.sh' dev-script, described later in this document.
    147 
    148     This is handy to compare which symbols were added between platform
    149     releases (and check that nothing disappeared).
    150 
    151   $DEVNDK/platforms/android-$PLATFORM/samples/
    152     Contains samples that are specific to a given API level. These are
    153     usually copied into $INSTALLED_NDK/samples/ by the 'gen-platforms.sh'
    154     script.
    155 
    156 
    157   $NDK/platforms/
    158     Note to be confused with $DEVNDK/platforms/, this directory is not
    159     part of the NDK git directory (and is spefically listed in $NDK/.gitignore)
    160     but of its final installation.
    161 
    162     Its purpose is to hold the fully expanded platform-specific files.
    163     This means that, unlike $DEVNDK/platforms/android-$PLATFORM, the
    164     $NDK/platforms/android-$PLATFORM will contain _all_ the files that
    165     are specific to API level $PLATFORM.
    166 
    167     Moreover, the directory is organized slightly differently, i.e. as
    168     toolchain sysroot, i.e. for each supported $PLATFORM and $ARCH values,
    169     it provides two directories:
    170 
    171        $NDK/platforms/android-$PLATFORM/arch-$ARCH/usr/include
    172        $NDK/platforms/android-$PLATFORM/arch-$ARCH/usr/lib
    173 
    174     Notice the 'usr' subdirectory here. It is required by GCC to be able
    175     to use the directories with --with-sysroot. For example, to generate
    176     binaries that target API level 5 for the arm architecture, one would
    177     use:
    178 
    179        $TOOLCHAIN_PREFIX-gcc --with-sysroot=$NDK/platforms/android-5/arch-arm
    180 
    181     Where $TOOLCHAIN_PREFIX depends on the exact toolchain being used.
    182 
    183     The dev-script 'gen-platforms.sh' is used to populate $NDK/platforms.
    184     Note that by default, the script does more, see its detailed description
    185     below.
    186 
    187 Generally, everything dev-script supports the --help option to display a
    188 description of the program and the list of all supported options. Also,
    189 debug traces can be activated by using the --verbose option. Use it several
    190 times to increase the level of verbosity.
    191 
    192 Note that all Windows host programs can be built on Linux if you have the
    193 'mingw32' cross-toolchain installed ('apt-get install mingw32' on Debian or
    194 Ubuntu). You will need to add the '--mingw' option when invoking the script.
    195 
    196 All dev-scripts rebuilding host programs on Linux and Darwin will only
    197 generate 32-bit programs by default. You can experiment with 64-bit binary
    198 generation by adding the '--try-64' option. Note that as of now, 64-bit
    199 binaries are never distributed as part of official NDK releases.
    200 
    201 When building 32-bit Linux host programs, the dev-scripts will look for
    202 $NDK/../prebuilts/gcc/linux-x86/host/i686-linux-glibc2.7-4.6/, which is
    203 part of the Android platform source tree. It is a special toolchain that
    204 ensures that the generated programs can run on old systems like Ubuntu 8.04
    205 that only have GLibc 2.7. Otherwise, the corresponding binaries may not run
    206 due to ABI changes in mor recent versions of GLibc.
    207 
    208 This shall always be used to official NDK Linux releases.
    209 
    210 
    211 II. Host toolchains:
    212 --------------------
    213 
    214 The host toolchains are the compiler, linker, debugger and other crucial
    215 programs used to generate machine code for the target Android
    216 system supported by the NDK.
    217 
    218 
    219 II.1 Getting the toolchain sources:
    220 - - - - - - - - - - - - - - - - - -
    221 
    222 The NDK toolchain sources are located under the toolchain/ directly
    223 from the top of the public AOSP repositories. There are actually several
    224 git repositories of interest here:
    225 
    226     binutils/
    227     build/
    228     gcc/
    229     gdb/
    230     gold/
    231     gmp/
    232     mpfr/
    233 
    234 The AOSP toolchain/ repository contains sources corresponding to toolchains
    235 that are used to build the Android platform tree. For various reasons, they
    236 need to be slightly patched for use with the NDK.
    237 
    238 All patches are located under $NDK/build/tools/toolchain-patches/
    239 
    240 The script 'download-toolchain-sources.sh' can be used to download and patch
    241 the toolchain sources from the server. You simply need to give it the name of
    242 a destination directory, for example:
    243 
    244   $NDK/build/tools/download-toolchain-sources.sh /tmp/ndk-$USER/src
    245 
    246 Note that this process can take several minutes. If you happen to already
    247 have a clone of the repo toolchain/ tree, you can speed this up considerably
    248 using the --git-reference or --git-base option. See --help for more options
    249 and details.
    250 
    251 Note, to create a local toolchain repo:
    252 
    253    mkdir -p /tmp/ndk-$USER/toolchain
    254    cd /tmp/ndk-$USER/toolchain
    255    repo init https://android.googlesource.com/toolchain/manifest.git
    256    repo sync
    257 
    258 then use with:
    259 
    260   $NDK/build/tools/download-toolchain-sources.sh \
    261        --git-reference=/tmp/ndk-$USER/toolchain \
    262        /tmp/ndk-$USER/src
    263 
    264 
    265 The script doesn't simply copy the current HEAD of the toolchain
    266 repositories. Instead, it will checkout the sources as they were
    267 at a given known date, defined as TOOLCHAIN_GIT_DATE in 'prebuilt-common.sh'.
    268 
    269 If you adjust TOOLCHAIN_GIT_DATE, verify that all patches still apply
    270 correctly, you might need to remove patches if they have been integrated
    271 into the toolchain/ repositories.
    272 
    273 Note: you can avoid the patching with the --no-patches option to
    274 'download-toolchain-patches.sh', and later use 'patch-sources.sh' manually
    275 to verify that the patches apply cleanly.
    276 
    277 The toolchains binaries are typically placed under the directory
    278 $NDK/toolchains/$NAME/prebuilt/$SYSTEM, where $NAME is the toolchain name's
    279 full name (e.g. arm-linux-androideabi-4.4.3), and $SYSTEM is the name of the
    280 host system it is meant to run on (e.g. 'linux-x86', 'windows' or 'darwin-x86')
    281 
    282 
    283 I.2. Building the toolchains:
    284 - - - - - - - - - - - - - - -
    285 
    286 After downloading and patching the toolchain sources, you will need to build
    287 a proper "sysroot" directory before being able to configure/build them.
    288 
    289 A sysroot is a directory containing system headers and libraries that the
    290 compiler will use to build a few required target-specific binaries (e.g. libgcc.a)
    291 
    292 To do that, use:
    293 
    294    $NDK/build/tools/gen-platforms.sh --minimal
    295 
    296 This will populate $NDK/platforms/ with just the files necessary to rebuild the
    297 toolchains. Note that without the --minimal option, the script will fail without
    298 prebuilt toolchain binaries.
    299 
    300 Once the sysroots are in place, use 'build-gcc.sh' by providing the path
    301 to the toolchain sources root directory, a destination NDK installation
    302 directory to build, and the full toolchain name.
    303 
    304 For example, to rebuild the arm and x86 prebuilt toolchain binaries in the
    305 current NDK directory (which can be handy if you want to later use them to
    306 rebuild other target prebuilts or run tests), do:
    307 
    308    $NDK/build/tools/build-gcc.sh /tmp/ndk-$USER/src $NDK arm-linux-androideabi-4.4.3
    309    $NDK/build/tools/build-gcc.sh /tmp/ndk-$USER/src $NDK x86-4.4.3
    310 
    311 Here, we assume you downloaded the toolchain sources in /tmp/ndk-$USER/src
    312 as described in the previous section.
    313 
    314 This operation can take some time. The script automatically performs a parallel
    315 build to speed up the build on multi-core machine (use the -j<number> option to
    316 control this), but the GCC sources are very large, so expect to wait a few
    317 minutes.
    318 
    319 For the record, on a 2.4 GHz Xeon with 16 Hyper-threaded cores and 12GB of
    320 memory, rebuilding each toolchain takes between 2 and 4 minutes.
    321 
    322 You need to be on Linux to build the Windows binaries, using the "mingw32"
    323 cross-toolchain (install it with "apt-get install mingw32" on Ubuntu). To do so
    324 use the "--mingw" option, as in:
    325 
    326     $NDK/build/tools/build-gcc.sh --mingw \
    327         /tmp/ndk-$USER/src $NDK arm-linux-androideabi-4.4.3
    328 
    329     $NDK/build/tools/build-gcc.sh --mingw \
    330         /tmp/ndk-$USER/src $NDK x86-4.4.3
    331 
    332 The corresponding binaries are installed under $NDK/toolchains/$NAME/prebuilt/windows
    333 Note that these are native Windows programs, not Cygwin ones.
    334 
    335 Building the Windows toolchains under MSys and Cygwin is completely unsupported
    336 and highly un-recommended: even if it works, it will probably take several
    337 hours, even on a powerful machine :-(
    338 
    339 The Darwin binaries must be generated on a Darwin machine. Note that the script
    340 will try to use the 10.5 XCode SDK if it is installed on your system. This
    341 ensures that the generated binaries run on Leopard, even if you're building
    342 on a more recent version of the system.
    343 
    344 Once you've completed your builds, you should be able to generate the other
    345 target-specific prebuilts.
    346 
    347 
    348 III. Target-specific prebuilt binaries:
    349 ---------------------------------------
    350 
    351 A final NDK installation comes with a lot of various target-specific prebuilt
    352 binaries that must be generated from sources once you have working host toolchains.
    353 
    354 III.1.: Preparation of platform sysroots:
    355 - - - - - - - - - - - - - - - - - - - - -
    356 
    357 Each target prebuilt is handled by a specific dev-script. HOWEVER, all these script
    358 require that you generate a fully populated $NDK/platforms/ directory first. To do
    359 that, simply run:
    360 
    361   $NDK/gen-platforms.sh
    362 
    363 Note that we used this script with the --minimal option to generate the host
    364 toolchains. That's because without this flag, the script will also auto-generate
    365 tiny versions of the system shared libraries that will be used at link-time when
    366 building our target prebuilts.
    367 
    368 III.2.: Generation of gdbserver:
    369 - - - - - - - - - - - - - - - - -
    370 
    371 A target-specific 'gdbserver' binary is required. This is a small program
    372 that is run on the device through 'ndk-gdb' during debugging. For a variety
    373 of technical reasons, it must be copied into a debuggable project's output
    374 directory when 'ndk-build' is called.
    375 
    376 The prebuilt binary is placed under $NDK/toolchains/$NAME/prebuilt/gdbserver
    377 in the final NDK installation. You can generate with 'build-gdbserver.sh' and
    378 takes the same parameters than 'build-gcc.sh'. So one can do:
    379 
    380   $NDK/build/tools/build-gcc.sh  /tmp/ndk-$USER/src $NDK arm-linux-androideabi-4.4.3
    381   $NDK/build/tools/build-gcc.sh  /tmp/ndk-$USER/src $NDK x86-4.4.3
    382 
    383 
    384 III.3. Generating C++ runtime prebuilt binaries:
    385 - - - - - - - - - - - - - - - - - - - - - - - -
    386 
    387 Sources and support files for several C++ runtimes / standard libraries are
    388 provided under $NDK/sources/cxx-stl/. Several dev-scripts are provided to
    389 rebuild their binaries. The scripts place them to their respective location
    390 (e.g. the GAbi++ binaries will go to $NDK/sources/cxx-stl/gabi++/libs/)
    391 unless you use the --out-dir=<path> option.
    392 
    393 Note that:
    394 
    395   - each script will generate the binaries for all the CPU ABIs supported by
    396     the NDK, e.g. armeabi, armeabi-v7a and x86. You can restrict them using
    397     the --abis=<list> option though.
    398 
    399   - the GNU libstdc++ dev-script requires the path to the toolchain sources,
    400     since this is where the library's sources are located.
    401 
    402 An example usage would be:
    403 
    404   $NDK/build/tools/build-gabi++.sh
    405   $NDK/build/tools/build-stlport.sh
    406   $NDK/build/tools/build-gnu-libstdc++.sh /tmp/ndk-$USER/src
    407 
    408 Note that generating the STLport and GNU libstdc++ binaries can take a
    409 few minutes. You can follow the build by using the --verbose option to display
    410 what's going on.
    411 
    412 
    413 IV. Other host prebuilt binaries:
    414 ---------------------------------
    415 
    416 There are a few other host prebuilt binaries that are needed for a full
    417 NDK installation. Their sources are typically installed under
    418 $NDK/sources/host-tools/
    419 
    420 Note that the corresponding dev-script recognize the --mingw and --try-64
    421 options described at the end of section I above.
    422 
    423 
    424 IV.1.: Building 'ndk-stack':
    425 - - - - - - - - - - - - - -
    426 
    427 The 'build-ndk-stack.sh' script can be used to rebuild the 'ndk-stack'
    428 helper host program. See docs/NDK-STACK.html for a usage description.
    429 To build it, just do:
    430 
    431   $NDK/build/tools/build-ndk-stack.sh
    432 
    433 
    434 
    435 V. Packaging all prebuilts:
    436 ---------------------------
    437 
    438 Generating all the prebuilt binaries takes a lot of time and is no fun.
    439 To avoid doing it again and again, it is useful to place all the generated
    440 files aside in special tarballs.
    441 
    442 Most dev-scripts generating them typically support a --package-dir=<path>
    443 option to do this, where <path> points to a directory that will store
    444 compressed tarballs of the generated binaries.
    445 
    446 For example, to build and package the GAbi++ binaries, use:
    447 
    448   $NDK/build/tools/build-gabi++.sh --package-dir=/tmp/ndk-$USER/prebuilt/
    449 
    450 In NDK r7, this will actually create three tarballs (one per supported ABI),
    451 under the directory /tmp/ndk-$USER/prebuilt/, i.e.:
    452 
    453   gabi++-libs-armeabi.tar.bz2
    454   gabi++-libs-armeabi-v7a.tar.bz2
    455   gabi++-libs-x86.tar.bz2
    456 
    457 Note that these tarballs are built to be uncompressed from the top-level
    458 of an existing NDK install tree.
    459 
    460 Similarly, to rebuild the STLport binaries and package them:
    461 
    462   $NDK/build/tools/build-stlport.sh --package-dir=/tmp/ndk-$USER/prebuilt
    463 
    464 A dev-script is provided to rebuild _and_ package all prebuilts. It is called
    465 'rebuild-all-prebuilt.sh'. Note that by default, it will automatically
    466 invoke 'download-toolchain-sources.sh', and place the prebuilt tarballs
    467 under /tmp/ndk-$USER/prebuilt-$DATE, where $DATE is the current date in
    468 ISO format (e.g. 20110915 for the 15th of September of 2011).
    469 
    470 If you have already downloaded the toolchain sources, use the
    471 --toolchain-src-dir=<path> option to save a few minutes to your rebuild,
    472 as in:
    473 
    474   $NDK/build/tools/rebuild-all-prebuilt.sh \
    475         --toolchain-src-dir=/tmp/ndk-$USER/src
    476 
    477 By default, this only rebuilds the host prebuilds for the current host
    478 system. You can use --mingw to force the generation of Windows binaries on
    479 Linux.
    480 
    481 Additionally, you can use the --darwin-ssh=<hostname> option to launch the
    482 build of the Darwin binaries from a Linux machine, by using ssh to access a
    483 remote Darwin machine. The script will package all required sources into a
    484 temporary tarball, copy it to the remote machine, launch the build there,
    485 then copy back all binaries to your own machine.
    486 
    487 This means that it is possible to generate the host binaries for all supported
    488 host systems from Linux (provided you have ssh access to a Darwin machine).
    489 
    490 Alternatively, you can run 'rebuild-all-prebuilt.sh' on a Darwin machine.
    491 
    492 Once you have used the script three times (once per supported host systems),
    493 you should have plenty of files under /tmp/ndk-$USER/prebuilt-$DATE.
    494 For the record, with NDK r7, the list was:
    495 
    496 
    497 VI. Packaging NDK releases:
    498 ---------------------------
    499 
    500 Use the 'package-release.sh' dev-script to generate full NDK release packages.
    501 These contain everything needed by a typical NDK user, including:
    502 
    503   - all prebuilt binaries (host toolchains, host tools, target libs, etc...)
    504   - all samples (including those collected from $DEVNDK/platforms/)
    505   - all documentation
    506 
    507 You need to have a directory containing prebuilt tarballs, as described in
    508 the previous section. You can use it as:
    509 
    510   $NDK/build/tools/package-release.sh  \
    511       --release=<name>      \
    512       --systems=<list>      \
    513       --arch=<list>         \
    514       --prebuilt-dir=<path>
    515 
    516 The --release option is optional and allows you to provide a name for your
    517 generated NDK archive. More specifically, the archive file name will be
    518 something like android-ndk-$RELEASE-$SYSTEM.tar.bz2, where $RELEASE is
    519 the release name, and $SYSTEM the supported host system (e.g. linux-x86).
    520 
    521 By default, i.e. without the option, $RELEASE will be set to the current $DATE.
    522 
    523 The --systems=<list> is optional, but can be used to limit the number of host
    524 systems you want to generate for. <list> must be a comma-separated list of
    525 system names (from 'linux-x86', 'windows' and 'darwin-x86'). This is useful
    526 if you're working on a experimental feature and don't have the time to
    527 regenerate the host toolchains for all systems. It allows you to generate
    528 an experimental package that you can distribute to third-party for
    529 experimentation.
    530 
    531 By default, i.e. without the option, the scripts tries to build NDK archives
    532 for all supported host systems.
    533 
    534 The --arch=<list> is also optional, but can be used ot limit the number of
    535 target architectures you want to generate for. <list> must be a comma-separated
    536 list of CPU architectures (e.g. from 'arm' and 'x86'). Without the option,
    537 this will try to build packages that support all architectures.
    538 
    539 Finally, --prebuilt-dir=<path> must point to the directory that contains the
    540 prebuilt tarballs described in section V. Following our previous example, one
    541 could use --prebuilt-dir=/tmp/ndk-$USER/prebuilt here.
    542 
    543 
    544 VI. Testing:
    545 ------------
    546 
    547 The $NDK/tests directory contains a number of NDK unit-tests that can be
    548 used to verify that the generated NDK packages or the working NDK tree still
    549 behave correctly.
    550 
    551 If you have an NDK package archive, you can run the following to run the
    552 test suite against it:
    553 
    554   $NDK/tests/run-tests.sh --package=<ndk-archive>
    555 
    556 This will uncompress the NDK archive in a temporary directory, then run all
    557 the tests with it. When all tests have run, the temporary directory is removed
    558 automatically.
    559 
    560 You can also point to an existing NDK installation with --ndk=<path>, as in:
    561 
    562   $NDK/tests/run-tests.sh --ndk=<path>
    563 
    564 Where <path> points to another NDK installation. The script will run the
    565 test suite present under $NDK/tests/, not the one in the remote NDK directory.
    566 
    567 If you don't use any option, the test suite will be run with the current NDK
    568 directory. This can only work if you have generated or unpacked all prebuilt
    569 archives into it before that.
    570 
    571 You can get more traces from the tests by using --verbose. Use it twice to see
    572 even more traces.
    573 
    574 There are several kinds of tests:
    575 
    576   - 'build tests' are used to test the building capabilities of the NDK.
    577     I.e. the tests will only use them to check that the NDK build system
    578     didn't regress. The corresponding generated binaries are never used
    579     otherwise.
    580 
    581   - 'device tests' are used to test both the build and the behaviour of
    582     the generated code. If the 'adb' program is in your path, and have
    583     one device or emulator connected to your host machine, 'run-tests.sh'
    584     will automatically upload, run and cleanup these tests for you.
    585 
    586     If adb is not in your path, or no device is connected, run-tests.sh
    587     will simply print a warning and carry on.
    588 
    589 
    590 Whenever you add a feature to the NDK, or fix a bug, it is recommended to
    591 add a unit test to check the feature or the fix. Use $NDK/tests/build for
    592 build tests, and $NDK/tests/device for device tests.
    593 
    594