The issue has been addressed on releasetools script side, by specifying
UUID and AVB salt to get reproducible images [1].
[1] https://android-review.googlesource.com/c/platform/build/+/1135332
Fixes: 134525174
Test: `m dist` with a non-A/B target.
`validate_target_files out/dist/target_files.zip` passes.
Change-Id: Ida6750291706036c9b0c192d8abcde6d65155287
We used to support getting idempotent images when given the same inputs,
by specifying UUID and AVB salt to the image builders. The support was
broken by Q changes that moved away from build-time fingerprints [1].
This CL addresses the issue by updating the logic in computing UUID and
AVB salt to be based on BuildInfo.fingerprint, as opposed to the
deprecated static build fingerprint.
[1] https://android-review.googlesource.com/c/platform/build/+/892933
Bug: 134525174
Test: TreeHugger
Test: lunch a target; `atest --host releasetools_test releasetools_py3_test`
Test: `m dist`; `unzip out/dist/target_files.zip IMAGES/\*`;
`zip -d out/dist/target_files.zip IMAGES/\*`
Test: `add_img_to_target_files -a out/dist/target_files.zip`. Verify that
the rebuilt images are identical to the ones deleted.
Change-Id: I8844fc7f044e9abfcd96a00e8958fa0583c70eaf
There is no change to module functionalities. Testcases are moved around
accordingly.
Bug: 134525174
Test: TreeHugger
Test: lunch a target; atest --host releasetools_test releasetools_py3_test
Change-Id: I7bc8f49cc239e7c6655fe5e375508f01c1743b94
When LOCAL_UNINSTALLABLE_MODULE is true, the module is not installed.
But its unstripped output is installed to the path based on
my_module_path which is not set for it is not installable. Moreover,
my_module_path is not reset after use.
As a result, when LOCAL_UNINSTALLABLE_MODULE is true, the path for
unstripped output is unexpected.
The installation is guarded by LOCAL_UNINSTALLABLE_MODULE now,
which was LOCAL_VNDK_DEPEND_ON_CORE_VARIANT.
Test: m
Change-Id: If18cf76118e058a9e0701a8d66f7ff0f534e5881
Trying to do it on per-device basis is prone to errors and already
bitten us several times. For example, currently aosp_taimen doesn't
install shim apex on system partition, but specifies
ro.apex.updatable = "true", which means that it doesn't pass CTS tests.
Unconditionally installing shim APEX shouldn't introduce any problems
since apexd will skip its activation of devices that don't support
updatable APEX.
Test: m checkbuild
Bug: 140957666
Change-Id: I6b5e668b40b97752295c831684a7291842533c40
The previous change in commit 22632cc82c
changed the behavior in loading file map. It now always puts a copy of
the input text in `extra` field. Update the tests accordingly.
Bug: 79951650
Test: Use a lunch'd target; `atest --host releasetools_test`
Change-Id: Iccf06c817c1305bf9946d7759c6f6f6af21fe85e
healthd had been deprecated from Android P.
Does not need to support it now.
Bug: 142164625
Bug: 138284857
Test: lunch gsi_arm64-userdebug;make -j
Test: No healthd in out folder
Change-Id: I48db70f4bf39f6322bd2e80e536e2ec96b3a6408
First, remove the use of info_dict['fstab'] in add_img_to_target_files.
- info_dict['fstab'] corresponds to recovery fstab
(`/etc/recovery.fstab`), which may differ from the one used for
normal boot.
- When calling build_image.ImagePropFromGlobalDict, we already have the
desired info from global dict (`META/info_dict.txt`).
Second, common.LoadInfoDict now loads recovery fstab only for non-A/B
devices. Because the info is only meaningful for installing non-A/B OTAs
(under recovery mode).
Fixes: 132458722
Test: TreeHugger
Test: Build non-A/B incremental OTAs.
Change-Id: Id23e7b17264c123319fe00b1663d52bfd9b4a5e2
When `OVERRIDE_TARGET_FLATTEN_APEX` is defined (e.g. set in the
environment), `TARGET_FLATTEN_APEX` is forcibly assigned its value.
This is useful to enable/disable APEX flattening from the command
line (thus ignoring the product's default configuration), for testing
purposes.
Note: Previously it was possible to set `TARGET_FLATTEN_APEX` directly
and have the same effect, but recent changes in the build
configuration now prevent that option.
Test: Check that:
export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& . ./build/envsetup.sh \
&& lunch aosp_walleye-userdebug \
&& export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& build/soong/soong_ui.bash --dumpvar-mode TARGET_FLATTEN_APEX
returns:
true
Bug: 121117762
Change-Id: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
The build system default was changed to not support apex, but
we want the mainline device to enable it.
Test: make mainline_system
Merged-In: I9f29e8354acffb1856dfd8a173b80a3f9324630c
Change-Id: I9f29e8354acffb1856dfd8a173b80a3f9324630c
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the platform build system and release tools changes to
move the recovery resources from system to vendor (or /system/vendor). The
release tools need to know where to generate the recovery patch, and they
discover this from misc_info.txt variable board_uses_vendorimage, which the
platform build system generates.
We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required
module in target/product/base_vendor.mk.
Several release tools rely on the misc_info.txt board_uses_vendorimage variable
to know how to generate and detect the recovery patch.
This change partially removes the --rebuild_recovery flag from the
merge_target_files.py script. The flag will be fully removed in a follow-on
change.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
Host builds using libc++ used -nodefaultlibs to turn off the default
C++ runtime, and then added back all the other necessary libraries.
Clang supports -nostdlib++ since https://reviews.llvm.org/D47115
that removes the C++ runtime without affecting the other default
libraries. Use -nostdlib++, and remove the lists of default
libraries.
Test: m checkbuild
Change-Id: Ib8b761534f64fd7f881e14598e514783678e0b35
zsh doesn't split variables (by default), but it will split command
output. bash will split both. Apparently a portable way to do this in
both is to just turn it into another command: "$(echo $var)".
Test: source build/envsetup.sh; lunch (see list; repeat in bash and zsh)
Change-Id: I9716a8d77aefdf05da8923deb9e37e0b6132b549
Arrays are zero indexed in bash and one indexed in zsh by default. This
leads to an off-by-one issue in the `godir` and `choosevariant` commands: when
prompted to chose an option, in order to pick option "n" you have to input
"n+1".
In those two specific instances, by using "substring expansion" instead of
array indexing, one can get consistent behaviour between bash and zsh
(equivalent to zero indexing).
Test: manual -
# godir
$ zsh
$ source build/envsetup.sh
$ godir SurfaceFlinger # There should be many options
# Pick 1, check that you end up in the right location
$ godir SurfaceFlinger.cpp # There should be only one possibility
# make sure you end up in the right location
# repeat with bash (to ensure compatibility is not broken)
# choosevariant
$ zsh
$ source build/envsetup.h
$ choosevariant # pick whatever variant you want
$ printconfig # make sure the variant matches your choice
# repeat with bash (to ensure compatibility is not broken)
Change-Id: I998d8fb48b708066b6db28a2129a2b09785fb0b1
Tao Bao