inode-size will jump around based on filesystem size, however
readonly Android system partitions have a specific pattern of
xattr associated with sepolicy and 256 is the most efficient at
absorbing the content.
Test: manual
Bug: 122328872
Change-Id: I06dd6a503067ab6477293b386d56a89dd86b0e83
We used to build retrofit full OTA package as long as
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS is true. This doesn't work with AOSP
targets that have the flag set but without any available vendor image.
This CL detects such a condition and uses a separate flag to guard the
retrofit OTA building as well as the split super images generation.
Bug: 120852744
Test: `m -j dist` on blueline (w/ vendor images) and aosp_blueline (w/o
vendor images).
Change-Id: I65726f24f8fc546be6802941a6a06590a3804c16
Package size will be unintended large if we stash more blocks than the
stash limit specified by the cache size. To reduce the maximum size of
simultaneous stashed blocks, we will inevitably convert some 'diff'
commands to 'new' commands.
To mitigate the impact, we add a new function to smartly select the
transfers to convert based on their patch size and compressed size.
This cl converts the transfers that have a larger patch size than the
compressed target sizes. And there's a slightly improvement in the
final package size: from 194M -> 185M.
Bug: 120561199
Test: build a non-A/B incremental package, run simulator
Change-Id: Id73ff736ba4e6901d245ad5549d42310d0740284
The current increase of 4 % is insufficient for some
targets.
Test: mmm
Bug: 119115481
Change-Id: Idcba8025b913da9b70794bfc7464d15b4d99ad34
(cherry picked from commit 3e02e34090)
We will call it at an earlier time to compute the patch size; and
choose the transfers to convert to 'new'.
Bug: 120561199
Test: Generate an incremental update on shiner
Change-Id: I29a0c8e75c9e5b66a266c1387186692a86fcbe43
For some internal branches, vendor.img isn't built, so there
is no need to build super image / super split images there.
Test: remove vendor.img and VENDOR/ from target_files_intermediates, then
run add_img_to_target_files
Fixes: 120634805
Change-Id: I2834a27ce232538f203733c204dd257279c789fc
Setting 'uses_shared_blocks' indicates that the block list for a given
file is incomplete, as some of the blocks are "owned" by others. As a
result, such a file will be skipped from imgdiff'ing.
This CL makes a copy of the original block list before removing the
shared blocks. It uses the original RangeSet as the value of
extra['uses_shared_blocks']. validate_target_files.py will try to read
the file as in the original RangeSet, unless the original list is also
incomplete or has non-monotonic ranges.
Test: Run validate_target_files on a target that uses
`BOARD_EXT4_SHARE_DUP_BLOCKS := true`.
Change-Id: I259e871ecc249ba0c14b5796bef413185a1b8242
Use the new script to build super_empty and super split images. No more
transformation to lpmake_args.
Test: build target_files_package for retrofit device
Change-Id: Id5f6bd607654ca869bcdf58d86b7ae300e3927eb
For non-retrofit (launch) devices, super.img is used for factory, so
source images should be from target_files.
In this change, build-superimage-target procedure is converted to a
more flexible script so that it can be built.
Bug: 119322123
Test: build target files for device launch with dynamic partitions
Change-Id: I6ee0cc3e145357dfc74be248f81f5f8f4e51fc5c
On aosp_blueline, system_other gets right-sized to 61,440 bytes. This
messes up the AVB footer calculation, and is too small to store an ext4
image.
Bug: 116608795
Test: build aosp_blueline w/ dynamic partitions
Change-Id: If0138a9d858765ff82cb957532504a066fd113ff
The map files contain the filename-block mapping for the original
images.
Bug: 120109184
Test: Generate an incremental OTA that was previously failing.
Change-Id: I1285d0b24a435477b958e6c2e4f474acf8f7578b
NB: second attempt, issue with scope for mkfs_output.
Separate out BuildImageMkfs from BuildImage, which just makes the
filesystem without any verity, avb, or other decisions. BuildImage
does all the wrapping for such. This will hopefully ease maintenance
and drop the issues surrounding BuildImage reentrancy.
Change right-size estimation path to use BuildImageMkfs, and thus do
so without verity or avb wrappings. Add partition_headroom to space
consideration. This makes the results of the estimation more
accurate and predictable.
Test: build
Bug: 111302946
Change-Id: I2549bd4e403c21290470b2fa1835492ae883f0fd
This reverts commit 2b72b7f01e.
out/target/product/generic_x86/installed-files.txt \${DIST_DIR}/installed-files-rescued.txt; exit 1 ) )"
2018-11-08 19:12:28 - build_image.py - ERROR : Failed to build out/target/product/generic_x86/obj/PACKAGING/systemimage_intermediates/system.img from out/target/product/generic_x86/system
Traceback (most recent call last):
File "build/make/tools/releasetools/build_image.py", line 767, in <module>
main(sys.argv[1:])
File "build/make/tools/releasetools/build_image.py", line 755, in main
BuildImage(in_dir, image_properties, out_file, target_out)
File "build/make/tools/releasetools/build_image.py", line 449, in BuildImage
CheckHeadroom(mkfs_output, prop_dict)
NameError: global name 'mkfs_output' is not defined
Bug: 111302946
Reason for revert: Build problem
Change-Id: I786f232e07af653a7207509055df5a07a6d8bb9e
Separate out BuildImageMkfs from BuildImage, which just makes the
filesystem without any verity, avb, or other decisions. BuildImage
does all the wrapping for such. This will hopefully ease maintenance
and drop the issues surrounding BuildImage reentrancy. Change
right-size estimation path to use BuildImageMkfs, and do so without
verity or avb wrappings.
Test: build
Bug: 111302946
Change-Id: I30e2e2b727f40ecca5164142f34139f5244f6424
Neglected to correct for filesystem size in estimate for verity.
To keep build space optimized and make sure that the existing image
does not confuse the tools, remove the out_file after the test build
image phase.
Test: build
Bug: 111302946
Change-Id: I360775d862d02a721d061bbc43e8b4e2f03bd01e
This is a rollback of Id5ae6645b9aa2d036e6fefe2fb17672e8f8ef6f0
and the followup I6a0f3919e8d45d0b3e7cd558a6ad4d3799012f2c
The magic constant introduced appears to be too aggressive.
Note that the new constant in I0f32c75e80b5da4d47671055ac274ccc2b485992
doesn't appear to fix the broken builds.
Bug: 111302946
Test: make
Change-Id: I29207265172d293c6fee98212e3266bde85895df
Regression introduced by c3d408e3c1
Found a case where 1 + 1/60 reduction in size based on free space
failed when right sizing an ext4 image. Reduced the math to 1 + 1/61.
Test: compile
Bug: 111302946
Change-Id: I0f32c75e80b5da4d47671055ac274ccc2b485992
In Append2Simg and Append in verity_utils.py, we catch and rethrow
exceptions as BuildVerityImageError. However, this suppresses the
traceback from the original exception which usually indicates the actual
cause. We can better handle this with the raise statement in Python 3,
which is however unavailable in Python 2.
This CL logs the exception before rethrowing to retain the useful bits.
Test: Inject an error to append2simg. `m -j systemimage` with
aosp_marlin-userdebug. Check the output.
Change-Id: I0c2f57d6023fa1038256b85fa98d57ad0244a70d
Regression introduced by c3d408e3c1
Found a case where 1 + 1/59 reduction in size based on free space
failed when right sizing an ext4 image. Reduced the math to 1 + 1/60.
Test: compile
Bug: 111302946
Change-Id: I6a0f3919e8d45d0b3e7cd558a6ad4d3799012f2c
Add ext4 dedupe to system_other, product, product_services, odm and
oem images. Experimental savings without any other configuration
changes was 0%, .75%, 3.4% respectively for the raw image file size
for the first three.
Test: manual
Bug: 111302946
Change-Id: Ia8fb5696151acad59bb144ea93f2c2ddac962bbd
To more quickly settle on a no free space result, recognize that
there is roughly 1/58.5 overhead managing the free space pool as
determined experimentally. This algorithm carries with it some
risk of being sensitive to any alterations in ext4.
This also addresses the issue of a much larger apparent free space
available calculated on the sample pass when deploying ext4 dedupe,
and resolves the poorer estimation that happens without accounting
for the overhead.
The alternative of adding a second pass works to a similar, and
likely more comforting algorithm and result. But doing so adds
a minute to the typical incremental build time, or +50% to the
time it takes to determine ext4 right sized images.
Test: manual
Bug: 111302946
Change-Id: Id5ae6645b9aa2d036e6fefe2fb17672e8f8ef6f0
This avoids showing a message as below:
raise BuildImageError("Failed to get tune2fs usage:\n{}".format(output))
UnboundLocalError: local variable 'output' referenced before assignment
The `output` won't be set under such a case, which unfortunately hides
the real cause. This CL addresses the issue by letting it throw
implicitly, which contains the command and outputs.
Test: `m dist`
Test: `python -m unittest test_build_image`
Change-Id: Icf015bab8869d150516246ed73552f6502127cdf
If partition_reserved_size is 0 or undefined, and
use_dynamic_partition_size is true, we should approach no space
and no free inodes automatically.
Estimate the space and number of inodes required, then do a first
pass build to see how much space actually used, and use those values
to refine the estimate.
Depends on tune2fs to report the characteristics of the filesystem,
so only support for ext filesystems. In the future if there has to
be a more generic ability, either a tool per a filesystem has to be
found, or we will need root capabilities to mount the filesystem to
acquire the characteristics live from the host system.
Test: manual + python -m unittest test_build_image
Bug: 111302946
Change-Id: I933a388be43516b6de7b5007b296765bd5556fde
Chained vbmeta images should be included into the top-level vbmeta.img
as chained partitions. It's done in the path of `m`, but not `m dist`.
Bug: 118115607
Test: `m dist` a target that uses chained vbmeta.
a) Check that the `vbmeta.img` in target-img.zip contains the image
descriptor of `vbmeta_system.img` (`avbtool info_image`).
b) `avbtool verify_image --image vbmeta.img \
--expected_chain_partition \
vbmeta_system:1:/path/to/vbmeta_system/pubkey`
c) `avbtool verify_image --image vbmeta_system.img`
Change-Id: I064e583b247c44b9b2f19355838550bb5dbb8f26
Recovery can now parse the pem encoded x509 keys from a zipfile. So
instead of dumping the keys into a text file with some intermediate format,
we can simply create a zipfile with the keys.
Bug: 116655889
Test: make bootimage and check the generated zipfile, run sign_target_files_apks
Change-Id: Ib76feecfb26d6be713a07644e80ec96133759004
This sets up the root logger while running tests. It also logs to
stdout, as our Python test result parser doesn't like outputs from
stderr.
Test: `python -m unittest discover build/make/tools/releasetools \
> /dev/null` doesn't print log lines.
Change-Id: Ic99711bd458bc4b67b38226786fed604c2168476
Converts the following files to Python logging.
add_img_to_target_files.py
blockimgdiff.py
build_image.py
check_ota_package_signature.py
common.py
img_from_target_files.py
make_recovery_patch.py
ota_from_target_files.py
sparse_img.py
verity_utils.py
This separates logging outputs from normal outputs, and allows easier
switching between different verbosity levels. It also supports adjusting
logging config via environment variable (LOGGING_CONFIG).
Test: `m dist`
Test: `python -m unittest discover build/make/tools/releasetools`
Change-Id: Idfc3f7aff83e03f41f3c9b5067d64fd595d5192d
Mark Salyzyn