This will let us quickly check the system image build type,
and modify *.rc behavior based on that.
Bug: 142430632
Test: adb shell getprop ro.sanitize.hwaddress in hwasan build
Change-Id: If2eb99dee93f0652cada5cb2e02fda963d00a7eb
Iae26e4676c29c68fa3f76187512c82786bfa0522 removed the definition
of ZIPALIGN_PAGE_ALIGN_FLAGS in favor of always using the -p flag,
but left accidentaly left one usage. Replace it with -p.
Bug: 141212627
Test: m checkbuild
Change-Id: Ica69d9195426f8f30039da211ed1a0ad5dffe8e8
For following cases:
Case 1: A/B devices: no change
Case 2: non-A/B devices, with unsigned recovery image:
not allowed anymore by mandating BOARD_AVB_RECOVERY_KEY_PATH
Case 3: non-A/B devices, with signed recovery image:
vbmeta.img should not include ChainPartitionDescriptor of recovery.img,
otherwise device can not even boot into normal mode if recovery partition
is damaged
This CL will cause a build break if BOARD_AVB_RECOVERY_KEY_PATH
is not set for non-A/B targets with recovery.img
The following is an example to fix the build break by specifying
AVB signing configs for the recovery.img.
BOARD_AVB_RECOVERY_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_RECOVERY_ALGORITHM := SHA256_RSA2048
BOARD_AVB_RECOVERY_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_RECOVERY_ROLLBACK_INDEX_LOCATION := 2
Also note that libavb in bootloader needs an update to include this
commit Iaa886037edb18c2ff6c60fa2a7f883ab7303ba1a, to support verifying
recovery.img independently (not through vbmeta.img).
Bug: 130351427
Test (Case 3):
normal mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NONE)
recovery mode: avb_slot_verify(flags=AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION)
Test: PYTHONPATH=build/make/tools/releasetools \
python -m unittest test_validate_target_files
Test: Use a lunch'd target. `atest --host releasetools_test releasetools_py3_test`
Test: validate_target_files.py with Case-3 target files
Change-Id: I2a73252b385fa463b4abd444923a8acc473df0b4
This allows querying per-partition fingerprint via libavb (in
particular, avb_property_lookup).
Bug: 80097573
Test: `m dist`; `avbtool info_image --image /path/to/image` to check the
written prop.
Test: `atest --host releasetools_test releasetools_py3_test`
Test: Run sign_target_files_apks to sign a target_files.zip that's built
with the change. Check the AVB prop in the signed images.
Change-Id: Id4f06df82c29e77aca128439c8c11f0367fe587e
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
In commit I30137c3caef91805d9143d404e5e4d06c0fccc30, we added
a boot-debug.img to allow adb root when using an user build GSI image.
However, to run automated tests, it requires additional properties,
which are not needed for GSI compliance:
ro.audio.silent=1
ro.test_harness=1
This CL adds an additional boot-test-harness.img for automated tests,
and keeps the original boot-debug.img for GSI compliance.
Note: boot-test-harness.img won't be built by default, it needs
explicit `make bootimage_test_harness`.
Bug: 140036184
Test: `m bootimage_test_harness`, flashes boot-test-harness.img and checks
adb root works and test harness props are set.
Test: `m bootimage_test_harness dist -j32`, checks both
boot-test-harness.img and ramdisk-test-harness.img are under ./out/dist/.
Test: `system/tools/mkbootimg/unpack_bootimg.py --boot_img $OUT/boot-test-harness.img --out ramdisk-test-harness`,
checks the extracted out/ramdisk is as expected
Test: Run `gunzip -c ramdisk | cpio -idm` for the ramdisk extracted from
$OUT/boot-test-harness.img and $OUT/boot-debug.img, respectively.
Then compare the root dirs of both, e.g.,
`diff -rq --no-dereference ./ramdisk-test-harness ./ramdisk-debug`
Test: `m ramdisk_test_harness-nodeps` and `m bootimage_test_harness-nodeps`
Change-Id: Iadea0b5c933c3b7fa10dcf3d9e85596916b3333d
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
