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 An alternative to setting $TARGET_PRODUCT and $TARGET_BUILD_VARIANT, 30 which you may see in build servers, is to execute: 31 32 m PRODUCT-<product>-<variant> 33 34 35 A target may be a file path. For example, out/host/linux-x86/bin/adb . 36 Note that when giving a relative file path as a target, that path is 37 interpreted relative to the root of the source tree (rather than relative 38 to the current working directory). 39 40 A target may also be any other target defined within a Makefile. Run 41 `m help` to view the names of some common targets. 42 43 To view the modules and targets defined in a particular directory, look for: 44 files named *.mk (most commonly Android.mk) 45 these files are defined in Make syntax 46 files named Android.bp 47 these files are defined in Blueprint syntax 48 49 During a build, a few log files are generated in ${OUT} (or ${DIST_DIR}/logs 50 for dist builds): 51 52 verbose.log.gz 53 every command run, along with its outputs. This is similar to the 54 previous `m showcommands` option. 55 error.log 56 list of actions that failed during the build, and their outputs. 57 soong.log 58 verbose debug information from soong_ui 59 60 For now, the full (extremely large) compiled list of targets can be found 61 (after running the build once), split among these two files: 62 63 ${OUT}/build-<product>*.ninja 64 ${OUT}/soong/build.ninja 65 66 If you find yourself interacting with these files, you are encouraged to 67 provide a more convenient tool for browsing targets, and to mention the 68 tool here. 69 70Targets that adjust an existing build: 71 dist Copy into ${DIST_DIR} the portion of the build 72 that must be distributed 73 74Flags 75 -j <N> Run <N> processes at once 76 -j Autodetect the number of processes to run at once, 77 and run that many 78 79Variables 80 Variables can either be set in the surrounding shell environment or can be 81 passed as command-line arguments. For example: 82 export I_AM_A_SHELL_VAR=1 83 I_AM_ANOTHER_SHELL_VAR=2 m droid I_AM_A_MAKE_VAR=3 84 Here are some common variables and their meanings: 85 TARGET_PRODUCT The <product> to build # as described above 86 TARGET_BUILD_VARIANT The <variant> to build # as described above 87 DIST_DIR The directory in which to place the distribution 88 artifacts. 89 OUT_DIR The directory in which to place non-distribution 90 artifacts. 91 92 There is not yet known a convenient method by which to discover the full 93 list of supported variables. Please mention it here when there is. 94 95