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
This matches what is done for mainline_system_arm64
(in this particular branch).
Test: lunch mainline_system_x86 && m nothing
Change-Id: I4eb236d086bd36b4821ed11411fa404f2d45f2b9
Merged-In: I607781ce7c6299cbc98c54c683d04db3b65c2e21
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
