1Android build system usage:
2
3m [-j] [<targets>] [<variable>=<value>...]
4
5
6Ways to specify what to build:
7  The common way to specify what to build is to set that information in the
8  environment via:
9
10    # Set up the shell environment.
11    source build/envsetup.sh # Run "hmm" after sourcing for more info
12    # Select the device and variant to target. If no argument is given, it
13    # will list choices and prompt.
14    lunch [<product>-<variant>] # Selects the device and variant to target.
15    # Invoke the configured build.
16    m [<options>] [<targets>] [<variable>=<value>...]
17
18      <product> is the device that the created image is intended to be run on.
19        This is saved in the shell environment as $TARGET_PRODUCT by `lunch`.
20      <variant> is one of "user", "userdebug", or "eng", and controls the
21        amount of debugging to be added into the generated image.
22        This gets saved in the shell environment as $TARGET_BUILD_VARIANT by
23          `lunch`.
24
25    Each of <options>, <targets>, and <variable>=<value> is optional.
26      If no targets are specified, the build system will build the images
27      for the configured product and variant.
28
29  A target may be a file path. For example, out/host/linux-x86/bin/adb .
30    Note that when giving a relative file path as a target, that path is
31    interpreted relative to the root of the source tree (rather than relative
32    to the current working directory).
33
34  A target may also be any other target defined within a Makefile. Run
35    `m help` to view the names of some common targets.
36
37  To view the modules and targets defined in a particular directory, look for:
38    files named *.mk (most commonly Android.mk)
39      these files are defined in Make syntax
40    files named Android.bp
41      these files are defined in Blueprint syntax
42
43  During a build, a few log files are generated in ${OUT} (or ${DIST_DIR}/logs
44    for dist builds):
45
46    verbose.log.gz
47      every command run, along with its outputs. This is similar to the
48      previous `m showcommands` option.
49    error.log
50      list of actions that failed during the build, and their outputs.
51    soong.log
52      verbose debug information from soong_ui
53
54  For now, the full (extremely large) compiled list of targets can be found
55    (after running the build once), split among these two files:
56
57    ${OUT}/build-<product>*.ninja
58    ${OUT}/soong/build.ninja
59
60    If you find yourself interacting with these files, you are encouraged to
61    provide a more convenient tool for browsing targets, and to mention the
62    tool here.
63
64Targets that adjust an existing build:
65  dist                      Copy into ${DIST_DIR} the portion of the build
66                            that must be distributed
67
68Flags
69  -j <N>                    Run <N> processes at once
70  -j                        Autodetect the number of processes to run at once,
71                            and run that many
72
73Variables
74  Variables can either be set in the surrounding shell environment or can be
75    passed as command-line arguments. For example:
76      export I_AM_A_SHELL_VAR=1
77      I_AM_ANOTHER_SHELL_VAR=2 m droid I_AM_A_MAKE_VAR=3
78  Here are some common variables and their meanings:
79    TARGET_PRODUCT          The <product> to build # as described above
80    TARGET_BUILD_VARIANT    The <variant> to build # as described above
81    DIST_DIR                The directory in which to place the distribution
82                            artifacts.
83    OUT_DIR                 The directory in which to place non-distribution
84                            artifacts.
85
86  There is not yet known a convenient method by which to discover the full
87  list of supported variables. Please mention it here when there is.
88
89