vendor-ramdisk-debug.cpio.lz4 will be packed into a
vendor_boot-debug.img and usually won't be flashed directly.
Moving it to the intermediate build directory.
Bug: None
Test: make vendorbootimage_debug
Change-Id: I86ea72c7a3484a90286139624408d07ce4bf994c
Test: mm -j && mm -j dist, make sure virtual_ab_compression is set to
true in dynamic_partition_info.txt of target_File.zip
Change-Id: Id0d46bd8ed738b2b69a0c01481b7db0c7127f773
When building vendor_boot v4 with multiple vendor ramdisks, pass the
name of each ramdisk to mkbootimg.
Bug: 177882072
Test: Modify a device BoardConfig and verify the built vendor_boot.img
with unpack_bootimg
Change-Id: I679d277aa88f1e10678d2f74b579e4140536e267
Commit I56dda56bab7def1540f4fb506323e3e605620cd4 adds
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT and includes
$(TARGET_RECOVERY_ROOT_OUT) directory when building vendor
ramdisk if BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is set.
We should do the same thing when building the vendor debug
ramdisk as well. Otherwise, lacking some recovery files
makes the device unable to boot into fastbootd/recovery mode.
Bug: 177712689
Test: `make vendorbootimage_debug`, then unpack
./obj/PACKAGING/vendor-boot-debug_intermediates/vendor-ramdisk-debug.cpio.lz4
to check it includes recovery resources via:
`lz4 -d -c ../vendor-ramdisk-debug.cpio.lz4 | cpio -idm`
Test: device can boot into fastbootd after flashing vendor_boot-debug.img
Change-Id: I4744c6600866436ed7d5a321e67e20b8f3da8a81
As we add more partitions, INTERNAL_*IMAGE_FILES variables has grown
and the places where the variables are referenced had to be touched
everytime. This change introduces a new variable
INTERNAL_ALLIMAGES_FILES which concatnates INTERNAL_*IMAGE_FILES, and
replaces the uses of the variables with the new one.
Bug: N/A
Test: m
Change-Id: I62a0f725a0f6999421d04a6261370be9124e62d7
Add support for partitioning the vendor_boot kernel modules into
multiple vendor ramdisk fragments. The partition granularity is kernel
module directory. This mechanism builds upon the existing
BOARD_KERNEL_MODULE_DIRS mechanism. For example, say we have three
kernel module directories:
BOARD_KERNEL_MODULE_DIRS := foo bar baz
We can then define a vendor ramdisk fragment:
BOARD_MKBOOTIMG_ARGS += --header_version 4
BOARD_VENDOR_RAMDISK_FRAGMENTS := dlkm_foobar
And let said ramdisk to contain the DLKM directories "foo" and "bar":
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.KERNEL_MODULE_DIRS := foo bar
BOARD_VENDOR_RAMDISK_FRAGMENT.dlkm_foobar.MKBOOTIMG_ARGS := <mkbootimg args>
The built vendor_boot image would contain two ramdisks.
The first one being the "default" ramdisk, which contains DLKM directory
"baz" and the rest of the files that get's installed to
$(TARGET_VENDOR_RAMDISK_OUT).
The second one is the "dlkm_foobar" ramdisk, which contains the two DLKM
directories.
Design doc: go/vendor-boot-v4
Bug: 162864255
Test: Modify BoardConfig.mk to have a product build v4 vendor_boot
Test: Use unpack_bootimg to verify the vendor_boot image
Test: Teach a bootloader how to handle v4 boot image, flash boot &
vendor_boot and boot device
Change-Id: Ibb1bbd7ebe36430c55ec6c4818c1d3888a319089
* Prerequisites: external/f2fs-tools: sload compression support
* Must work with corresponding changes in system/extras repository
* If Board config does not change, it falls back to old behavior,
i.e. no compression for the system partition
* Kernel f2fs compression support is a prerequisite if the Board config
enables the compression (see below)
* Necessary board config change
(e.g. device/<vendor>/<product>/BoardConfig-common.mk)
BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := f2fs
BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE := 200000000
BOARD_SYSTEMIMAGE_FILE_SYSTEM_COMPRESS := true
BOARD_SYSTEMIMAGE_F2FS_SLOAD_COMPRESS_FLAGS := <sload compress sub-options>
Setting BOARD_SYSTEMIMAGE_FILE_SYSTEM_COMPRESS to true enables both the
compression support when the initial empty file system be made (mkfs.f2fs)
and the compression flag (-c) when the system image files be side-loaded
by sload.
Sload compress sub-options (i.e. options other than -c) will be provided
by BOARD_SYSTEMIMAGE_F2FS_SLOAD_COMPRESS_FLAGS. If it is not given, or
is empty, the default sub-options will be used
Please refer to the sload.f2fs manual page.
Setting BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE to f2fs is trivially necessary.
* File system table (fstab), notably the file 'fstab.hardware', should
also changed:
- The file type must be changed to f2fs
- Perhaps also other f2fs-specific options
Bug: 170918499
Test: Pixel4a userdebug build (from build id 6918751)
Signed-off-by: Robin Hsu <robinhsu@google.com>
Change-Id: Id9d67b5cb35dc806e06ff1320e89114abc996a28
It was in the middle of some other logic in main.mk
Put it in Makefile instead next to the other "information" dist txt
files.
Test: make and diff certificate_violation_modules.txt
Change-Id: I5b73a0f89ccf3de69e7608a0568d2b4b6f37e98c
Protected KVM relies on protected VM firmware (pvmfw) to bootstrap the
trust in protected VMs. This firmware is AVB protected and stored in the
pvmfw partition.
Test: build a target with BOARD_PREBUILT_PVMFWIMAGE set, saw the image
included in the product files and used avbtool to check the footer
and vbmeta.img details.
Bug: 171280178
Change-Id: I4d6a1819f307c77ca60c0dd3dff39ee28cece4f6
This is needed after
commit 21c34f78e8
which starts calling host_init_verifier in merge_target_files,
a binary in releasetools.
Test: m otatools
Change-Id: Iee762de9fd6f890b5cc26ee5507da2f3f284fc14
Files are copied into the recovery installation directory by a rule
that runs rsync. The previous logic tried to avoid racing with the
rsync rule by depending on the final packaged recovery image, but
if BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is set then
INSTALLED_RECOVERYIMAGE_TARGET is left empty and no dependency was
added. Depend on the timestamp file used as the output of the rule
that runs rsync instead.
Test: query dependencies of installed-files-recovery.txt
Fixes: 173772240
Change-Id: I5ec77a6933e3a83fe4e4819e0e246017d824d8a5
List of stub libraries from system (and bionic APEX) is currently
managed in static file. This change generates the list at build time and
adds to the system config so linkerconfig can use it.
Bug: 172889962
Test: Build cuttlefish and confirmed list is generated in
/system/etc/linker.config.pb
Change-Id: Idd5a93442f398dd8e88c767c694ddae64d1bb713
Add installed-files-vendor-ramdisk.txt build artifact, so that it is
easy to see what files landed on the vendor ramdisk.
Test: clean build, inspect installed-files-vendor-ramdisk.txt
Change-Id: Ie84d06dc968ad972ab2bfa79db4d1839ba09e09f
check_vintf now accepts a file that contains the full kernel
release string as the first half of --kernel. Use it.
With this patch, BOARD_KERNEL_VERSION can be a full kernel release
string like 5.4.42-something, or 5.4.42-android12-0-something.
The content of target_files/META/kernel_version.txt also contains the
full kernel release, not just the kernel version.
Bug: 161317193
Test: m check-vintf-all
Change-Id: I3b52639f557532077894d9356c745c16b41dd91c
check_vintf now accept a path to a file that contains the kernel
version string. Use it.
Test: m check-vintf-all and manual inspect
Bug: 161317193
Change-Id: I4812c93f352686d73c5832d59e43a297d93e67a2
Currently we support skip building vbmeta.img when
PRODUCT_BUILD_VBMETA_IMAGE is set to false, which is used
when generating a system-only or vendor-only build artifacts.
However, when using `make dist` to build target files,
vbmeta.img is still generated. This change fixes this by
passing the related info to misc_info.txt for the release
tool to skip building vbmeta.img when necessary.
To make this happen, a device config should:
1. Set PRODUCT_BUILD_VBMETA_IMAGE := false
2. Remove 'vbmeta' from AB_OTA_PARTITIONS:
AB_OTA_PARTITIONS += \
boot \
system \
- vbmeta \
dtbo \
product \
system_ext \
vbmeta_system
Bug: 161659370
Test: `make dist` and checks the target file does not include vbmeta.img
Change-Id: Iddca9fe0b171a50a80e5a88aa462e118f18a7e6f
This reverts commit 78b55b2244.
Reason for revert: Replaced by Ib99aca13d4d:
ANDROID: GKI: build in a kernel command line of "rw"
Prebuilt is checked in at Ie34b5b017:
Update kernel to builds 6964541
Fixes: 171512004
Test: TH
Change-Id: I2aec88cc22483a6b3a671fc664d465624a14e5b0
Cuttlefish doesn't support updating the vendor partition. So we change
ota_from_target_files to only generate updates for partitions in
BOARD_PARTIAL_OTA_UPDATE_PARTITIONS_LIST. This CL puts the prop in
misc_info.txt, which will be read by ota scrips
Bug: 171999375
Test: mm -j
Change-Id: I4d9c97c717cb73806f95684b3bc81ef285ccbb8b
If BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES is defined,
in target files, instead of rebuilding the boot image, copy the boot
image already built in $OUT to target files package directly so that
they are the same package.
Define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES for aosp_arm64.
The GKI APEX is built using the boot image in $OUT. If the boot image in
$OUT is different from the boot image in target files, aka the generic
boot image we release, the GKI APEX we built is invalid.
If another device needs to copy $OUT/boot.img to target files, it can
define BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES.
Fixes: 172682114
Test: lunch aosp_arm64 &&
Change-Id: I10fc7a5aa36e976dbeaf25434239687455bba061
Add phony target check-elf-prebuilt-product-copy-files that asserts
PRODUCT_COPY_FILES doesn't have ELF prebuilts.
This helps triage PCF ELF errors by providing a convenient target to
check / list all errors.
Bug: 140560012
Bug: 156534160
Test: lunch aosp_cf_x86_phone
Test: m USE_NDK_TRANSLATION_BINARY=true \
check-elf-prebuilt-product-copy-files -k
Change-Id: Ic7fa43c10b0c30b3b1d9b7c2fae75cc6ea4a3513
* changes:
Mount generic ramdisk as readwrite.
Do not put GENERIC_KERNEL_CMDLINE in recovery image.
Move common code out of the conditional.
Remove device-specific bits if recovery_as_boot
Do not assume GKI just with vendor_boot.
With this change, first stage init can prepare and move
resources to accomodate devices with and without a dedicated
recovery partition.
Test: build with and without recovery partition, and manually inspect
Bug: 171512004
Change-Id: I7bd61f74c16ee77f3f05dc208e0f3cfe81e302b0
The GENERIC_KERNEL_CMDLINE should only be in the generic boot image.
If device uses recovery-as-boot, it never uses generic boot image
because on devices with generic boot image, recovery resources are
moved to vendor_boot instead.
Bug: 171512004
Test: builds
Change-Id: Ia84e604a8ded28af39c7f1861ff5d3b3af55849f
On legacy devices (launched with R and below), if device:
- has a vendor_boot partition, and
- uses recovery_as_boot
Then, when building the recovery/boot partition, the
device-specific bits, including dtb/kernel base/pagesize should
be moved to vendor_boot.
Previously, it is incorrectly assumed that A/B => recovery_as_boot.
In reality, we do have A/B devices with a dedicated recovery partition.
Note that for devices that uses GKI (BOARD_USES_GENERIC_KERNEL_IMAGE),
recovery_as_boot is never set to true. Instead, recovery resources
are moved to vendor_boot. On these devices, the conditional
'vendor_boot && recovery-as-boot' is always false. Hence:
- If the device has a dedicated recovery partition, it should use V3 header,
and dtb/base/pagesize won't be in recovery header.
- If device does not have a dedicated recovery partition, the recovery
image won't be built.
Test: builds
Change-Id: I0db2af20470cbe8a21044a984cccf264590aaccf
This change ensures changes to GENERIC_KERNEL_CMDLINE only affects
devices that explicitly says it uses GKI/generic boot image.
In details, if the device has vendor_boot, but does not explicitly
specify that it uses GKI/generic boot image, do not include
GENERIC_KERNEL_CMDLINE in boot. boot cmdline is left empty
in this case.
The old logic:
- If device uses GKI *OR* has vendor_boot:
boot uses GENERIC_KERNEL_CMDLINE, and do not include kernel base
and pagesize.
- If device has vendor_boot, INTERNAL_KERNEL_CMDLINE, kernel base
and pagesize goes in vendor_boot.
- If device does not use GKI nor have vendor_boot:
boot uses INTERNAL_KERNEL_CMDLINE, and includes kernel base and
pagesize.
The new logic:
- If using GKI, boot uses GENERIC_KERNEL_CMDLINE. Remove kernel base
and pagesize because they are device-specific.
- If not using GKI:
- If building vendor_boot, INTERNAL_KERNEL_CMDLINE, base and
pagesize goes in vendor_boot; boot does not have cmdline, base or
pagesize.
- Otherwise, put them in boot
Comparison of the code before and after:
- If device uses GKI,
- For boot partition:
- cmdline continues to be GENERIC_KERNEL_CMDLINE
- kernel base and pagesize continues to be excluded
- For vendor_boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
- If device does not use GKI:
- If device has a vendor_boot partition:
- For boot partition:
* cmdline changes from GENERIC_KERNEL_CMDLINE to empty
- kernel base and pagesize continues to be excluded
- For vendor_boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
- If device does not have a vendor_boot partition:
- For boot partition:
- cmdline continues to be INTERNAL_KERNEL_CMDLINE
- kernel base and pagesize continues to be included
Test: builds
Bug: 171512004
Change-Id: I4feac435698f43ac299b430bff66147057865a62
Many partners have asked for platform support of system-only update.
So we config cuttlefish as an example to support the partial ota
updates. Also make such package available on the build server.
This allows continuous test to ensure the e2e update flow is working.
Bug: 170921953
Test: generate & apply a partial update, check output in presubmit
Change-Id: I79d0abeb1b2be18e6ff88f0455b6de6540a37794
If recovery resources are moved to vendor_boot, it also means
there's no recovery image to install. Don't build
recovery-resource.dat in this case.
Test: builds with cuttlefish with GKI
Bug: 156098440
Change-Id: I86db08d2dede6af644afadac54ff8beb853f4933
This reverts commit 8197702d73.
Test: lunch cf_x86_auto && m check-vintf-all
Reason for revert: auto targets fixed in the same topic
Change-Id: I193416a4d0718e5790eb54e5c0674edc2d975632
This reverts commit 843240c81a.
Reason for revert: breaks devices with cameraserver
Change-Id: Idedad49276fb928346cee68133e643602b79cd7a
Fixes: 171262706
For some devices, the img.zip package needs to contain the ramdisk
in order to enable device-specific flashing to work properly
This change adds a new flag BOARD_IMG_USE_RAMDISK to the possible
device Makefile configuration. If set to true, the build process
will insert ramdisk.img in the target-files.zip and img.zip
build outputs of "m dist". No change will occur for builds
that do not use this flag, or set it to a non-true value.
Bug: 168642807
Test: lunch trout_arm64-userdebug, m dist with and w/out
BOARD_IMG_USE_RAMDISK added to Makefile;
lunch aosp_cf_arm64-phone-userdebug, m dist
Change-Id: Id29408551cd41c11b96157248e238324a327043d
Merged-In: Id29408551cd41c11b96157248e238324a327043d
When building with BOARD_USES_GENERIC_KERNEL_IMAGE, even if BUILDING_VENDOR_BOOT_IMAGE
is not set, do not include board-specific cmdline, dtb, page size, and base in the
generic boot image.
This change drops buildvariant=* in the cmdline of the generic boot
image
Bug: 156098440
Test: manual. Deliberately set BOARD_KERNEL_CMDLINE for aosp_arm64 and
ensure it doesn't go into the boot image.
Change-Id: I846f600058a4a9b349d55c9773d6dd81bbe49312
This variable indicates whether recovery resources are moved to
vendor_boot. If true:
- $OUT/recovery.img will not be built
- $OUT/recovery/root will be included in vendor_boot ramdisk
Bug: 156098440
Test: set to true and check output
Test: `m target-files-package` and manually inspect output
Change-Id: I56dda56bab7def1540f4fb506323e3e605620cd4
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE removes kernel from the
recovery image.
Test: build recovery image and unpack_bootimg
Test: build target files and unpack_bootimg IMAGES/recovery.img
on device with GKI and dedicated recovery partition.
Bug: 156098440
Change-Id: I5f37d74ed954b26fe3dd778708b6ab9cfdc51f1e
This causes boot-debug.img to build if its main dependency
INSTALLED_BOOTIMAGE_TARGET (boot.img) is defined.
This fixes an issue where boot-debug.img was missing when
BUILDING_BOOT_IMAGE=false, but boot.img exists because the board uses
recovery as boot.
Bug: 170644849
Test: Build target that sets PRODUCT_BUILD_BOOT_IMAGE and
PRODUCT_BUILD_RECOVERY_IMAGE false,
observe no boot-debug.img.
Test: Build target that sets BOARD_USES_RECOVERY_AS_BOOT,
observe boot-debug.img.
Change-Id: Ic887ea93d4c5181eca0f82c3cdf3ce3b72f4c185
The coverage infrastructure will use the proguard_usage.zip files
to filter out classes that were stripped by R8.
Test: forrest
Bug: 170337718
Change-Id: Ia7c07770ff520aaf0a8de213edbe22d6fca5b98a
Add a build.prop file for ramdisk. Properties uses the
name ro.[product.]bootimage*.
These ro.[product.]bootimage.* properties are also included in recovery
properties.
The file is installed to system/etc/ramdisk/build.prop under ramdisk.
On devices with dedicated recovery partition, the file is
installed to ramdisk/, which is installed to the ramdisk in the boot
image. The file is NOT installed to recovery/root to prevent
collision.
On devices with recovery_as_boot, in addition to ramdisk/, it is also
installed to recovery/root, which is installed to the ramdisk in the
boot image.
Test: m bootimage and inspect output
Bug: 169169031
Bug: 162623577
Bug: 170411692
Bug: 170364317
Change-Id: Ica6515b2a4e0f4a7fe4440434a3d7085fde64387
- Introduces PRODUCT_BUILD_VENDOR_BOOT_IMAGE.
- Controls vendor_boot.img, replacing TARGET_NO_VENDOR_BOOT.
- Matches the naming convention of other similar vars.
- Guards boot-debug.img behind BUILDING_BOOT_IMAGE
- Restructures BUILDING_BOOT_IMAGE to give priority to
PRODUCT_BUILD_BOOT_IMAGE, as do other partitions.
- ^ for BUILDING_RECOVERY_IMAGE.
Test: PRODUCT_BUILD_{BOOT,RECOVERY,VENDOR_BOOT}_IMAGE := false
m dist
Observe no boot, boot-debug, recovery, or vendor_boot images.
Bug: 169968221
Bug: 170423509
Change-Id: I629bf08ba08e5db14c1bf92bb338fb3ce59d5b73
For example, if BOARD_KERNEL_BINARIES contains kernel-5.4, make sure
boot-5.4.img depends on kernel-5.4.
Test: remove kernel-5.4 from out directory then build boot image
Fixes: 169725104
Change-Id: I85624f3595c1a698bc27d19c73349138bb6e9e8c
Because flattened apexes are installed in /<partition>/apex, associated
file_contexts file should be modified to accommodate path changes and
also merged into target-wide file_contexts.bin file.
Soong now emits modified file_contexts via LOCAL_FILE_CONTEXTS, and
these files are collected into a temporary file_contexts.modules.tmp
file, which is used as an additional input of file_contexts.bin.
Bug: 166518492
Test: m file_contexts.bin
check the contents of file_contexts.concat.tmp file
Change-Id: I002a2294af9e06baeaf54bc5a9a5380d23b8a3da
* changes:
Add CSV output of remaining makefiles for bp converstion
Refactor the mongo main() into a class in mk2bp_catalog.py
Add per-partition summaries and "easy" transitions to mk2bp_catalog
Modules partition is a dynamic read-write partition.
- AVB is not enabled on the partition
- OTA is file-based; see follow up CL for details
- No build prop files; in particular, no build fingerprint
- No fs_config
- No notice files; notice files are included in individual APEXes
Test: build on CF
Bug: 163543381
Change-Id: Ie397b9ec61dfd1c158450d050196024604854d4d
It isn't doing anything useful that would be necessary to reparse the
Makefiles for.
Test: m target-files-package
Change-Id: I3aa2490480de8dbe0e57fe36221088c3f18017cb
Depend on the files instead of images so that the dist zip files
can run in parallel with the image generation rules.
Test: treehugger
Change-Id: I1f942dc0ce0a2cbc5288c1f0633ea1019e77f91c
Depend on the files going into the images instead of the images
themselves when the images are not prebuilts. This will allow
paralellizing image generation with target-files.zip.
Test: treehugger
Test: m installclean && m target-files-package has same files before and after
Change-Id: If51d0f53602c08bd946ec34a2edae6f9d95f7bf8
Remove the INSTALLED_VBMETAIMAGE_TARGET, which depends on all the
other images, it is no longer necessary after
If1eff317621882994e7dcbf37cd35f5bfa16b69a. This will allow the
next change to parallelize target-files.zip with the image generation
rules.
Test: treehugger
Change-Id: Ie27bdbd2d414e9b475823639a1b3944fe0756d2a
BOARD_PREBUILT_ODM_DLKMIMAGE support seems to have been forgotten
in target-files.zip, and BOARD_PREBUILT_ODM_DLKMIMAGE support had
a typeo.
Test: treehugger
Change-Id: I9663220b43f0df4f39a7ef432ad4cfec39803a20
Non-dist builds don't copy out the bootloader.
This change fixes that.
Bug: 167160541
Bug: 164917252
Test: local build
Change-Id: I9bab9ba3455e8abee9e7a38bff431a142e7d5a57
Creating the symlinks between partitions (e.g /system/vendor to /vendor)
inside the packaging rules requires duplicating the creation in the
system.img rule as well as in the the target-files.zip rule, which can
cause the target-files.zip rule to fail in soong_zip when the symlink
is removed and recreated by the system.img rule.
Now that our Ninja fork supports symlinks in the build graph, move
the symlink creating to their own rules and add them to the list
of files that the image creation and packaging rules depend on.
Fixes: 161280160
Test: m nothing
Test: treehugger
Change-Id: I0f4d16b57b3052efb12a1f086506f1298c22ec84
Revert submission 1411608-revert-1402265-cf-x86-bootloader-XGKLNEQAPF
Reason for revert: Breakage originally caused by change was fixed. Refer to tracking bug for details.
Reverted Changes:
I89e95d4a6:Revert "Add prebuilt bootloader var and add bootlo...
I8fe199351:Revert "Added bootloader binary to cf x86 based ta...
Bug: 166380489
Bug: 164917252
Test: local build and Treehugger build
Change-Id: Ia895aedd77f2ec825aefecaf74c6dfc1ce631c93
Needed to enable a prebuilt bootloader to make it to the dist and img
directories.
Added a flag to ensure only devices that request will have the update
package populated with a bootloader
Bug: 164917252
Test: local build and Treehugger build
Change-Id: Id67b7bddda14b51a523f794976591c6de04d71ca
* changes:
add support to non-A/B for multiple kernels, boot images
add BOARD_GKI_NONAB_COMPAT for non-A/B compatability with GKI
fix recoveryimage-nodeps
Merge all the proguard_usage.zip files produced by the R8 rules and
dist the result.
Bug: 151857441
Test: m TARGET_BUILD_APPS=DocumentsUI dist
Change-Id: I7e6d73241478016093a203dc7bd86407ab86a4ac
This hasn't worked for a couple years, and continues to bitrot. Just
remove it.
Test: treehugger
Change-Id: Iea6caf3c08252a560155e095135c5ddaad712991
Merged-In: Iea6caf3c08252a560155e095135c5ddaad712991
Apparently needed for cts tests due to apks putting intermediate files under
TARGET_OUT even when going to HOST_OUT.
Test: m with and without change verified no differences in notice files
Change-Id: Iea50b6bd9af9452a2600c97e2f7cb89218b9be7f
* changes:
Create $OUT/{vendor,odm}/lib before symlink modules
Add odm_dlkm/etc/build.prop
Install ODM dlkm to appropriate place and symlink
Add notice files for odm_dlkm
Add odm_dlkm partition.
- Adds makefile and which files are installed to the SOONG_CONV CSV file
- Updates soong_to_convert.py to be able to parse that
- Adds new script that is more detailed.
- Outputs that file as part of the droidcore build to
$(OUT_DIR)/target/product/$(TARGET_DEVICE)/mk2bp_remaining.html
Test: m out/target/product/$(get_build_var TARGET_DEVICE)/mk2bp_remaining.html
Change-Id: I7c380b6070754f4329bf3965595751e4dac794a0
We put reproducible timestamps in zip files so that the artifacts
are consistent, but that leads to old timestamps in the output
directory if they are unzipped as part of the build. Use
unzip -DD when unzipping to update the timestamps.
Bug: 161015009
Test: touch -d 2020-01-01 ref; find $OUT/system -not -newer ref
Change-Id: I6f08ba8695d90a8225cfc04e679755e6296deed0
This is used when Soong and Make don't know the full output file list,
and so use a tool to generate a per-module apkcerts.txt file instead.
Fixes: 160119159
Test: m apkcerts-list
Merged-In: I48183bc8cbf9dcc521f791812734205ed3f28f4c
Change-Id: I48183bc8cbf9dcc521f791812734205ed3f28f4c
