Previously it was following a wrong order by doing `zipalign` after
calling SignApk, which effectively compromised the signature. This CL
corrects the logic, and follows the same flow as in build system:
- Pack APEX file;
- `zipalign -f 4096`;
- Call SignApk to sign the container with `-a 4096` flag.
Bug: 129148142
Test: Run sign_target_files_apks.py on taimen target_files.zip. Boot the
image after signing.
Change-Id: I91bd3dce4f45c1891c5e122212a699f4808618fa
(cherry picked from commit 0e06cb0a8b)
Previously it was following a wrong order by doing `zipalign` after
calling SignApk, which effectively compromised the signature. This CL
corrects the logic, and follows the same flow as in build system:
- Pack APEX file;
- `zipalign -f 4096`;
- Call SignApk to sign the container with `-a 4096` flag.
Bug: 129148142
Test: Run sign_target_files_apks.py on taimen target_files.zip. Boot the
image after signing.
Change-Id: I91bd3dce4f45c1891c5e122212a699f4808618fa
To build a complete list of the dynamic partitions and partitions
groups, we need to merge the contribution from the system and other
target files.
Bug: 127687287
Test: Running merge_target_files.py and observing partition lists are
merged as expected.
Change-Id: I5bb9bd0e3179d48c9bfacdb3aca8253158f61cf6
For PRESIGNED APEXes, we should keep carrying the matching public keys
at /system/etc/security/apex.
Bug: 129148142
Test: Run sign_target_files_apks.py on a target_files.zip with presigned
APEXes. Check the output zip.
Change-Id: I2e941fd9b10e99d2db9df1e5308cbbe8c760177b
(cherry picked from commit bf3fb024cd)
For PRESIGNED APEXes, we should keep carrying the matching public keys
at /system/etc/security/apex.
Bug: 129148142
Test: Run sign_target_files_apks.py on a target_files.zip with presigned
APEXes. Check the output zip.
Change-Id: I2e941fd9b10e99d2db9df1e5308cbbe8c760177b
This config was in a weird state where it sets the OUT
directory for these partitions but not the file system
type. Within the build system, both of these variables
are used interchangeably to check whether these partitions
are expected to be present.
A typical mainline device is expected to /vendor and
/product, so just add these.
Bug: 120974093
Test: make
Change-Id: I803d7afdcadc37e4384ae80f08bc1c8db535d2f4
Configure this product not to build any of the other partitions.
Note that the only partition that currently has artifacts produced
is system_other, and this change doesn't appear to prevent odex/vdex
files from being created there anyway. However, it does allow
configuring the target device (mainline_arm64) to have more partitions
in a followup change.
Bug: 111533333
Test: make
Change-Id: Ib115cb03bc99b9b61e0d6f1b622784e7ad5fcea0
This change changes auto-generated RROs from DEVICE_PACKAGE_OVERLAYS
to be generated in the vendor partition, as opposed to /product where
they were generated in the past.
Note that PRODUCT_PACKAGE_OVERLAYS continue generating RRO packages
to /product, which means that a single app can be overlayed from
different partitions. These RROs have been given module and package
names based on their location.
Bug: 127758779
Test: verify noop on presubmit targets
Change-Id: I5cee70e28e3969e67b2d83eaf25d9c6e3a11102d
The adb_debug.prop will be loaded by init when the file
/force_debuggable is present in the first-stage ramdisk, and the device
is unlocked. This file has the highest priority to override other system
properties, thus can override ro.debuggable to 1 to allow adb root.
Bug: 126493225
Test: boot a device with /force_debuggable in ramdisk, checks
adb_debug.prop is loaded
Change-Id: I75d661bb04178f584d8b6f5eba26ae35ccb01239
This is a stop-gap measure for a proper fix enforcing library "ownership" in
Soong: b/128708192
Test: m systemimage (with and without libs that exist in /system/lib)
Test: Check that this fails:
m systemimage
m out/target/product/taimen/system/lib/libjdwp.so
m systemimage-nodeps
Bug: 124293228
Change-Id: Iac0d0cec7d9e216028a0caccfbb76838514d4a7b
The file $(TARGET_OUT_ETC)/update_engine/update-payload-key.pub.pem
is installed conditionally based on this variable, and was found
to differ between mainline_system and the intended device targets.
Also move the variable from gsi_common.mk as GSI inherits the mainline
boardconfig. The variable is not a PRODUCT flag (and not inherited as
such), so fits better in the BoardConfig I think.
Bug: 80410283
Test: presubmit
Change-Id: Ida6fa923fd01b062ff3b93e7737e1e6edf7e4fa1
