* 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.
This involved moving the find-shareduid-violation.py script to
releasetools to simplify the cross-tool usage. This new location aligns
this script with other similar python host tools.
In a future change this violation file will be used to check for
shared UID violations across the input build partition boundary.
Bug: 171431774
Test: test_merge_target_files
Test: Use merge_target_files.py to merge two partial builds,
observe shared UID violations file contents in the result.
Test: m dist out/dist/shareduid_violation_modules.json
(Checking that existing behavior in core/tasks is presereved)
Change-Id: I7deecbe019379c71bfdbedce56edac55e7b27b41
Passes the SKIP_BOOT_JARS_CHECK property through to Soong and removes
the boot jars check. Moves the check_boot_jars directory containing the
script and data file into build/soong/scripts.
Test: m check-boot-jars - for failing and passing cases
verified manually that apart from path differences the same
files (same check sum) were checked in both old make checks and
the new Soong ones
Bug: 171479578
Change-Id: I61c128806065befce239bbdd5491567827e1b2f5
Fix a bug where if module A requires module B, and for whatever reason
module A and B have some common installed files, then all required
dependencies of the common files would be lost.
For example:
```
# A requires B
ALL_MODULES.A.INSTALLED := a
ALL_MODULES.B.INSTALLED := a b
```
Right now the build system wouldn't generate any dependency for `a`.
However the correct behavior should be: `a` has a order-only dependency
on `b`.
Bug: 157444528
Test: Check generated build-*.ninja
Change-Id: Iec60231f6597ec46077393d1defa109b9c07b208
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
Revert "Add -fdebug-compilation-dir option"
Revert submission 1461902-debug-compilation-dir
Reason for revert: "-Xclang" isn't being uniformly respected everywhere. For example, in ".S" compilations, when I pass `-Xclang -fdebug-compilation-dir=.", the assembler seems to be ignoring it and then inserting the `pwd` into the command, however when I pass "-fdebug-compilation-dir=.", it strips out the path to the current working directory.
This indicates that we need to update re-client's input processor so that we can pass -fdebug-compilation-dir=. without "-Xclang" and then remove `PWD` setting.
For now, I'll update this patch to pass both "-fdebug-compilation-dir=." and `PWD` and when RBE side fix is done, I'll remove `PWD` in a separate CL.
Reverted Changes:
Ib0f271e55:Add -fdebug-compilation-dir option
Ifa0592af5:Remove env-var-allowlist
Change-Id: I7c690b3e00d37dbcc8fbaa66dda49f39032be3ab
This reverts commit 843240c81a.
Reason for revert: breaks devices with cameraserver
Change-Id: Idedad49276fb928346cee68133e643602b79cd7a
Fixes: 171262706
In terms of sepolicy rules, every property should have an apporpriate
owner attribute, which can be one of: system_property_type,
product_property_type, or vendor_property_type. This will be enforced
for devices launching with S or later. Devices launching with R or
eariler can relax this by setting following under BoardConfig.mk:
BUILD_BROKEN_ENFORCE_SYSPROP_OWNER := true
See system/sepolicy/public/te_macros for more details.
Bug: 131162102
Test: system/sepolicy/tools/build_policies.sh
Change-Id: Iee05fc15beac1ccf61da4ea901a85b9d4068e0ca
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
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
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
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
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
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
Pulls out all of the per-file rules into their relevant directories
and includes platform/build/soong:/OWNERS as the authoritative
list of approvers.
Test: treehugger
Bug: 170407947
Change-Id: Icb885fc25a638f2f5134f6223df656ef4438bb67
- 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
The function was in test/framework/build/utils/vtslab_package_utils.mk
It was removed as part of the cleanup of vts10.
Function target-native-copy-pairs is still used to package kernel native
tests.
Bug: 170339160
Test: m vts
Change-Id: I0097022f05fc9adc47a664c63a8341040b4af106
Non-installable generated intermediate data modules can have
notice files attached when they're defined in the same LOCAL_PATH
as the installable module that depends on them. This makes uninstallable
DATA modules silently ignore the fact that the build doesn't know where
to install the notice file.
Bug: 160248517
Test: build
Change-Id: I09a8a253dda52c2d78a1ebc0c33cd96e3505e2e3
Merged-In: I09a8a253dda52c2d78a1ebc0c33cd96e3505e2e3
Amends https://r.android.com/1439191; I realised echo-error doesn't
imply a false status.
Test: m art-check-{release,debug,testing}-apex-gen-fakebin
without https://r.android.com/1441933.
Bug: 169375644
Change-Id: Ice75aeab30120e781df50a28c3dce3874ec0bfd1
The new variable name reflects its actual usage.
Keep compatibility with BOARD_PLAT_* because it has been a
convention for years. Also add warning messages for BOARD_PLAT_*
variables via KATI_deprecated_var.
Test: `make selinux_policy` with
`SYSTEM_EXT_{PUBLIC,PRIVATE_SEPOLICY_DIRS}` set,
observe additions in `$(TARGET_COPY_OUT_SYSTEM_EXT)/etc/selinux`
Signed-off-by: Felix Elsner <google@ix5.org>
Change-Id: I58c64839cc513ae082cd3ee3c1e108843ea7439e
Align with changes in build/soong and system/sepolicy.
Test: build
Signed-off-by: Felix Elsner <google@ix5.org>
Change-Id: I73b773a4fb0bd626a989251d5c61381fcafaa1eb
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 boot/etc/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
Change-Id: I94b993ce3214356036d038b6db57c4e1b755c111
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
If a module, which is installed to both the host and the platform,
fails the platform-availability-check, the build system might use
the host install path to report errors. Filter out the host install
path so that the platform install path is used.
Bug: 169393514
Test: make
Change-Id: Ib39715ffc45cc32e3bd7ce5f2a3725d243f3237f
Yifan Hong