Go to file
Jiyong Park 4b61a94f70 Don't reserve size for bad blocks when checking image size
When checking *.img size with the partition size, the build system
reserves additional bits for spare bits and spare bad blocks.

However, for emmc and ufs, the space bits and blocks are entirely
managed by the underlying controller and thus not visible from outside
of the controller. In fact the check routine was made for legacy MTD
storages where raw flash blocks are directly exposed.

This makes the size checking a little bit conservative in modern devices.
Builds were failed even though the *.img can actually fit into the
partition. To handle this problem, the additional size is no longer
reserved when checking *.img size with the partition size.

This change also removes following build flags that are meaningful
only for devices having MTD storages:
BOARD_NAND_PAGE_SIZE
BOARD_NAND_SPARE_SIZE
Further use of them breaks the build

Bug: 35790399
Bug: 66399382
Test: build

Merged-In: I954bf261441b53844e75d05788866f1692a2ad43
Change-Id: I954bf261441b53844e75d05788866f1692a2ad43
2017-10-05 09:32:01 +09:00
core Don't reserve size for bad blocks when checking image size 2017-10-05 09:32:01 +09:00
target Don't reserve size for bad blocks when checking image size 2017-10-05 09:32:01 +09:00
tests Only set TARGET_PLATFORM version in lunch when explicitly requested 2017-05-03 02:47:59 +00:00
tools Merge "Use -Werror in build/make" am: 2d1681c804 am: 7dba41687e 2017-10-03 23:00:15 +00:00
.gitignore Add build subprojects to .gitignore 2015-07-23 13:18:47 -07:00
Android.mk Fix the build when using findleaves.py 2017-08-08 09:45:12 -07:00
CleanSpec.mk Move generated aidl/logtags java classes to a subfolder 2017-09-29 20:36:50 -07:00
OWNERS Add OWNERS in build/make 2017-06-21 16:09:56 -07:00
README.txt Consolidate build system usage documentation into source control 2017-08-09 12:58:30 -07:00
buildspec.mk.default Add TARGET_PLATFORM_VERSION to lunch 2017-03-23 09:44:08 -07:00
envsetup.sh Merge "Add shortcut to atest after envsetup.sh is sourced." 2017-08-25 18:50:32 +00:00
help.sh Consolidate build system usage documentation into source control 2017-08-09 12:58:30 -07:00

README.txt

Android build system usage:

m [-j] [<targets>] [<variable>=<value>...]


Ways to specify what to build:
  The common way to specify what to build is to set that information in the
  environment via:

    # Set up the shell environment.
    source build/envsetup.sh # Run "hmm" after sourcing for more info
    # Select the device and variant to target. If no argument is given, it
    # will list choices and prompt.
    lunch [<product>-<variant>] # Selects the device and variant to target.
    # Invoke the configured build.
    m [<options>] [<targets>] [<variable>=<value>...]

      <product> is the device that the created image is intended to be run on.
        This is saved in the shell environment as $TARGET_PRODUCT by `lunch`.
      <variant> is one of "user", "userdebug", or "eng", and controls the
        amount of debugging to be added into the generated image.
        This gets saved in the shell environment as $TARGET_BUILD_VARIANT by
          `lunch`.

    Each of <options>, <targets>, and <variable>=<value> is optional.
      If no targets are specified, the build system will build the images
      for the configured product and variant.

  An alternative to setting $TARGET_PRODUCT and $TARGET_BUILD_VARIANT,
  which you may see in build servers, is to execute:

    make PRODUCT-<product>-<variant>


  A target may be a file path. For example, out/host/linux-x86/bin/adb .
    Note that when giving a relative file path as a target, that path is
    interpreted relative to the root of the source tree (rather than relative
    to the current working directory).

  A target may also be any other target defined within a Makefile. Run
    `m help` to view the names of some common targets.

  To view the modules and targets defined in a particular directory, look for:
    files named *.mk (most commonly Android.mk)
      these files are defined in Make syntax
    files named Android.bp
      these files are defined in Blueprint syntax

  For now, the full (extremely large) compiled list of targets can be found
    (after running the build once), split among these two files:

    ${OUT}/build-<product>*.ninja
    ${OUT}/soong/build.ninja

    If you find yourself interacting with these files, you are encouraged to
    provide a more convenient tool for browsing targets, and to mention the
    tool here.

Targets that adjust an existing build:
  showcommands              Display the individual commands run to implement
                            the build
  dist                      Copy into ${DIST_DIR} the portion of the build
                            that must be distributed

Flags
  -j <N>                    Run <N> processes at once
  -j                        Autodetect the number of processes to run at once,
                            and run that many

Variables
  Variables can either be set in the surrounding shell environment or can be
    passed as command-line arguments. For example:
      export I_AM_A_SHELL_VAR=1
      I_AM_ANOTHER_SHELL_VAR=2 make droid I_AM_A_MAKE_VAR=3
  Here are some common variables and their meanings:
    TARGET_PRODUCT          The <product> to build # as described above
    TARGET_BUILD_VARIANT    The <variant> to build # as described above
    DIST_DIR                The directory in which to place the distribution
                            artifacts.
    OUT_DIR                 The directory in which to place non-distribution
                            artifacts.

  There is not yet known a convenient method by which to discover the full
  list of supported variables. Please mention it here when there is.