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
a0281768fe
This revert includes a fix to use the lz4 variant of the kernel,
as was the case before, rather than the uncompressed one.
Bug: 170451791
Change-Id: Iaab082d8bba04df82d742d682251447f3e21fe9b
An ABI incompatible change along with inability to
express the JNI dependency can result in build failures, see
b/170311371#comment8 for how to reproduce. Tested by using that
repro and verifying this clean step fixes it. Hopefully the
path being removed is correct for all host platforms.
Fixes: 170311371
Bug: 170389375
Test: As described above
Change-Id: I95ea952bf31d8e9caa8c42d21f2db1968cbe9097
Revert "Update kernel to builds 6888926"
Revert submission 1454075-2020-10-07-gki-update
Reason for revert: Looks like this topic changes caused daily build broken, the error log as:
error: +out/target/product/emulator_arm64/boot.img too large (34934784 > 33484800)
I tried to revert this topic first and then feel free to revert revert it.
Reverted Changes:
Ie74ca26e8:use new GKI kernel location
Ibff0d9638:Update kernel to builds 6889747
I693476e82:Update kernel to builds 6888926
I35d7f320c:Update kernel to builds 6888926
Id221a7a30:Update kernel to builds 6888926
I4421dbf67:remove kernel, kernel modules from cuttlefish_kern...
I991f9a6af:Allow downstream devices to customize vendor modul...
I598630e09:load kernel, kernel modules from updated locations...
Bug: 170451791
Change-Id: I4d8f18a7c80eb92cb475c48e1dcf04ceabd08984
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
