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
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
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
Previously, HOST_CROSS_OS/ARCH were fixed to windows/x86. This change
makes the setting configuration and adds the support for new OS/ARCH
combo: linux_bionic/arm64.
linux_bionic is the Linux-based host target that uses Bionic (instead of
glibc) as libc. Previously, it supported only x86_64 and the x86_64
target was NOT configured via Make, but directly via editing
soong.variables file. Now, the support for arm64 is being added in the
Soong side and this change makes it possible to configure the target via
Make.
The new HOST_CROSS_OS/ARCH combo will be used for building the host-side
tools (adb, crosvm, etc.) for running Cuttlefish natively on Linux/ARM
hosts.
Bug: 159685774
Test: HOST_CROSS_OS=linux_bionic HOST_CROSS_ARCH=arm64 m nothing
Change-Id: I6b8ed8f7e26908749bbe778fbdcc34cfbde68179
It isn't doing anything useful that would be necessary to reparse the
Makefiles for.
Test: m target-files-package
Change-Id: I3aa2490480de8dbe0e57fe36221088c3f18017cb
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
ASAN SANITIZE_TARGET build may have missing dependencies due to
executables being skipped, thus bypass the required module check.
https://source.android.com/devices/tech/debug/asan#sanitize_target
Also streamline the bypassing logic.
Fix: 163802658
Test: TH
Test: lunch aosp_cf_x86_pasan-userdebug &&
m SANITIZE_TARGET=address nothing
Change-Id: Ia43c942ce7eae718bf6fcd254307535e418a70e7
This hasn't worked for a couple years, and continues to bitrot. Just
remove it.
Test: treehugger
Change-Id: Iea6caf3c08252a560155e095135c5ddaad712991
Merged-In: Iea6caf3c08252a560155e095135c5ddaad712991
Now that they're defined with prebuilt_build_tool, we don't need to set
them here.
In future changes we can replace more of these definitions with
prebuilt_build_tool, as it can centralize the selection of
build-from-source or prebuilt for Make, Soong, and user-defined
genrules.
Test: treehugger
Change-Id: I5821bbad1b655d561919245320d7c184a6eac737
This will let us quickly check the system image build type,
and modify *.rc behavior based on that.
Bug: 142430632
Test: adb shell getprop ro.sanitize.hwaddress in hwasan build
Change-Id: Id1738ebc94a7c29ea9902a063f5d8dd6deb48f1b
The prop list the name of the a/b partitions that are supposed to
update via an OTA. The list varies by product, and update engine
needs to know these partitions to install the GKI update correctly.
Test: build and check the property
Change-Id: I5258955a5c3303bdc61b97fc92f5dfa1905f7c37
This reverts commit 3e1c9115d1.
Reason for revert: broke builds where makefiles were using M4 without depending upon it
Change-Id: Ib2deef08255656b91cb8ec42f1cb7e9555364f23
Revert "Track allowed transitive deps in any updatable module."
Revert submission 1312796-apex-allowed-deps
Reason for revert: b/161974327
Reverted Changes:
I52a4be72e:Add a check for apex/allowed_deps.txt to droidcore...
I56771ba3f:Track allowed transitive deps in any updatable mod...
Change-Id: I20ad7bf2001e76b5e3ca4aaf3baa5318e270f3dc
The check ensures that build graph for updatable modules contains only
allowed dependencies at build time.
Bug: 149622332
Test: m
Change-Id: I52a4be72efaa523d53827dd11822a7802543dd10
Merged-In: I5695dd1003386191dbbe0ea511ef5b615d0d5e4e
Exempt-From-Owner-Approval: cp
Android S would not support upgrade from O-MR1 devices, so VNDK Lite
configuration is no more valid. This change removes all VNDK-Lite
related steps and makr BOARD_VNDK_RUNTIME_DISABLE as deprecated
variable.
Bug: 158719241
Test: m -j passed
Change-Id: Ifb355da936933843862426e7ddfce9c7f69cea61
Merged-In: Ifb355da936933843862426e7ddfce9c7f69cea61
Now that they're defined with prebuilt_build_tool, we don't need to set
them here.
In future changes we can replace more of these definitions with
prebuilt_build_tool, as it can centralize the selection of
build-from-source or prebuilt for Make, Soong, and user-defined
genrules.
Test: treehugger
Change-Id: I4bb526492ebc6270b6030913c1f5b3f49dc61284
* 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.
In the concept of system/vendor build split, usually vbmeta.img
won't be built in a system-only build and/or a vendor-only build.
Instead, vbmeta.img will be generated later when combining system
and vendor artifacts.
- system-only artifacts: system.img, system_ext.img,
product.img and vbmeta_system.img
- vendor-only artifacts: boot.img, vendor.img, odm.img and
vbmeta_vendor.img
PRODUCT_BUILD_VBMETA_IMAGE can be used to disable building vbmeta.img.
However, it also disables vbmeta_system.img and vbmeta_vendor.img
generation because both are only depended by vbmeta.img.
This change adds both vbmeta_[system|vendor].img into droidcore,
so they will be built even if PRODUCT_BUILD_VBMETA_IMAGE is set
to false, when we're building system-only artifacts or vendor-only
artifacts.
Bug: 161425613
Test: sets PRODUCT_BUILD_VBMETA_IMAGE := false then build, checks
vbmeta_system.img is generated but vbmeta.img is not.
Change-Id: I39d9819da4704195b0e1ee58d13c848ae97d474a
Yifan Hong