The ro.build.version.release has updated to use the last stable platform
version in go/ab/10260813. But the logic for per-partition build prop
has never been updated. This mismatch eventually reflects in the
device's build fingerprints and cause confusion. This cl updates the
partition build props to match the behavior of the top level build props.
Also the device's fingerprints is heavily used in static analysis, e.g.
ota targeting, the change to its computation may cause unexpected effects.
Bug: 170968068
Bug: 158483506
Test: build system image for coral, check the build prop
Change-Id: Icf741c915f2eba970258979efc274e424187ac69
Allow the ota generation script to take a list of partitions;
and thus generating a partial ota update package. This allow the
testing of partial update functionality, e.g. system-only updates.
Bug: 170921953
Test: unit tests, generate and apply a partial update on coral with system, system_ext, vbmeta_system
Change-Id: I0d8f93806dfbf7b781ea911117b02fc5c0971434
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT controls whether GSI AVB keys are built
to vendor_boot. On devices without a dedicated recovery partition, GSI AVB
keys used to be built in boot. They are device-specific, so they should be
moved to vendor_boot.
Test: pass
Bug: 156098440
Change-Id: I0a5eaa1b39e88fcca9837c7aa3f475be47d5b0f2
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
Add BOARD_USES_GENERIC_KERNEL_IMAGE to be the global variable to
indicate the device uses GKI image.
Test: pass
Bug: 156098440
Change-Id: Ica553bbdb791e25dfa9bafb524ab2de5e3f8720d
Fix: 170967644
Test: boot
Test: Make sure the following jar files are removed
$OUT/system/framework/service-blobstore.jar
$OUT/system/framework/service-jobscheduler.jar
Change-Id: Ia5351d9d3b1dda7bf96e95bbaad171cd8c3b49fc
Merged-in: Ia5351d9d3b1dda7bf96e95bbaad171cd8c3b49fc
We no longer need to set PWD variable with the introduction of
`-fdebug-compilation-dir`, so removing env var allowlist of PWD variable
to RBE.
Change-Id: Ifa0592af519b6cc4364ee653f1a2174fd680bac1
These changes were necessary to begin merging a new cross-release target
whose vendor half is frozen.
- MergeDynamicPartitionInfoDicts
- Filters combined fields to remove duplicates
- Merges `super_block_devices` as well as other keys that were not
previously used by other targets consuming this tool.
- Introduces --allow-duplicate-apkapex-keys. This gives a warning rather
than fatal error on duplicate apk/apex keys. This flag is needed for
targets that cannot update a frozen half.
- (Formats merge_target_files.py)
Bug: 170683837
Test: Use merge_target_files to merge an S+R build, and boot.
Change-Id: Id5f787e730de8f8ef697e1f2f29ac6514221e58d
When sourcing the envsetup.sh script from a deep directory
inside of the repo, the vendorsetup.sh scripts are not being
sourced. This was causing the ANDROID_ENABLE_METRICS_UPLOAD
not to be set and developer's metrics were not being uploaded.
Provided the top directory to each directory path. Also cleaned
up the function to handle whitespacing correctly.
Bug: b/169699936
Test: *Ran source ../../build/envsetup.sh from external/libchrome dir
*Renamed repo dir to "aosp master" and source build/envsetup.sh
*Ran the script in zsh command line interpretor
*Ran the script in MacOS
Change-Id: I96eb73d50a1923cdda782792778b0d185a341cf9
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
See corresponding build/soong change. This change sets the android
platform to zero all heap allocations by default. To give some
intuition for why this is no so underperformant, zeroing memory is one
way of priming caches.
The main goal of this is to prevent accidental reliance on allocations
being zero, which is UB in C++. In some situations, allocations are
almost always guaranteed to be 0, and so resulting flakes can be
extremely rare.
Bug: 131355925
Test: allocated memory successfully getting zerod
Change-Id: I8c27fbc8c06420a15d022eb810595599d1e56aa0
