BOARD_SUPER_PARTITION_ERROR_LIMIT can be set by OEMs to cause a
build failure when the sum of sizes of logical partitions exceeds the same.
It is set to BOARD_SUPER_PARTITION_SIZE by default.
Bug: 133329143
Test: mmm -j32
Change-Id: Ief85c9ab3e3b9d071cd22b70e13b5c64bb784b9c
Merged-In: Ief85c9ab3e3b9d071cd22b70e13b5c64bb784b9c
(cherry picked from commit 219b6294dc)
BOARD_SUPER_PARTITION_WARN_LIMIT can be set by OEMs to print
a warning when the sum of sizes of logical partitions exceed the same.
It is set to 95% of BOARD_SUPER_PARTITION_SIZE by default.
Bug: 133329143
Test: mmm -j32
Change-Id: I7d3bedd970a92be60991898e436f63d914359301
Merged-In: I7d3bedd970a92be60991898e436f63d914359301
(cherry picked from commit 6fab18a7eb)
When using Verified Boot 2.0, releasetools specifies a salt value based
on build fingerprint, so that to give idempotent images.
However, the change that removed static `ro.build.fingerprint` [1] broke
the behavior, as common.LoadInfoDict still relies on fingerprints.
Without a fixed salt, the first call to make_recovery_patch.py and the
second one (which writes IMAGES/{boot,recovery}.img) will see different
images, which leads to install-recovery.sh failure.
Note that currently there's a dependency that requires getting bootable
images through two separate calls. make_recovery_patch.py has to happen
first to get (placeholder) files in the system image. We then generate
canned fs_config files, and finally use add_img_to_target_files.py to
write the images.
This CL adds a quick workaround to force rebuilding the
recovery-from-boot patch while calling add_img_to_target_files.py.
[1] https://android-review.googlesource.com/c/platform/build/+/892933
Bug: 134123803
Bug: 134525174
Test: TreeHugger
Test: Build a non-A/B target that uses AVB. Run validate_target_files.py
on the generated target_files.zip.
Change-Id: I5859e30be63bfd54398cf41fd2d907f15285f560
Merged-In: I5859e30be63bfd54398cf41fd2d907f15285f560
(cherry picked from commit 4978fa99d1)
The current solution expects BOARD_PREBUILT_DTBIMAGE_DIR to
contain prebuilt DTB files that are concatenated by the build system
to create $OUT/dtb.img. In order to accommodate devices that build
the dtb image locally, when BOARD_PREBUILT_DTBIMAGE_DIR is undefined,
make boot.img creation depend only on $OUT/dtb.img.
Bug: 133161451
Test: Build with BOARD_PREBUILT_DTBIMAGE_DIR undefined and verify
using unpack_bootimg.py that $OUT/dtb.img was included in boot.img.
Change-Id: Iae2c634ccdc1d83589b26d382882f75fb8565a31
Merged-In: Iae2c634ccdc1d83589b26d382882f75fb8565a31
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
