In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink:
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Test: make dist with an odm.img, checks $OUT/odm/etc/build.prop is loaded
Change-Id: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
Merged-In: I6f88763db755c9ec6068bfdd9cee81c19d72e9d7
(cherry picked from commit 6c62884000)
The current solution expects BOARD_PREBUILT_DTBIMAGE_DIR to
contain prebuilt DTB files that are concatenated by the build system
to create $OUT/dtb.img. In order to accommodate devices that build
the dtb image locally, make boot.img creation depend on $OUT/dtb.img
only when BOARD_PREBUILT_DTBIMAGE_DIR is undefined.
Bug: 133161451
Test: Build with BOARD_PREBUILT_DTBIMAGE_DIR undefined and verify
using unpack_bootimg.py that $OUT/dtb.img was included in boot.img.
Change-Id: Iae2c634ccdc1d83589b26d382882f75fb8565a31
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
Change-Id: I86e6a26d27c22b3622cf6ea8760f502f607df6f0
Bug: 131437873
Test: Built system-only and vendor builds for merge. Compared
resulting apkcertx and apexkeys text files to that of a monolithic
build,
Test: Created colliding entries in both apexkeys and apkcerts text
files and ensure the script exited with an appropriate error message.
Test: Created unit tests to cover both non-colliding and colliding
entries
Change-Id: I6e42ce682ffa9059344e8cd63ba3a720c1f93452
Targets with sdk_version values up to and including 29 should not use
Java language level 9, even if EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true
is set.
This change keeps the make logic in sync with the soong logic in the
other change in this topic.
Bug: 131678633
Test: EXPERIMENTAL_JAVA_LANGUAGE_LEVEL_9=true make droid tests docs cts java
Change-Id: Icd5db432f6b18486e8ede006c15a930c754ad4c2
When ONE_SHOT_MAKEFILE is set, the targets of LOCAL_*_REQUIRED_MODULES
may not exist, so skip the error message.
Fixes: 131241991
Test: mmm cts/tests/signature/intent-check
Change-Id: I95c4c901610746854179af8486c8c4767dd18864
Phony rules with recipes run on every build, move the recipe for
check-all-partition-sizes to a rule with an output.
Fixes: 132900128
Test: m && m
Change-Id: I9b4d335bf269cd09a01094e895fc15053b410415
By design doc: go/aidegen-doc-generate-R
In order to generate R.java of app modules, AIDEGen needs to build
the module. It might cause system.img oversized so we turn to build
the target srcjar file if it exists in module-info.json.
Build module-info.json without this change:
Build time: 1m47.227s
File size: 14,186,429 Bytes
Build module-info.json with this change:
Build time: 1m46.796s
File size: 14,614,470 Bytes
Bug: 132407603
Test: 1. m out/target/product/generic_x86_64/module-info.json
2. by grep "target/common/obj/APPS/Settings_intermediates/aapt2.srcjar"
in module-info.json.
Change-Id: I09c812aede0324bc38acbead0a863a85ae15b33e
As a PRODUCT variable, PRODUCT_EXTRA_VNDK_VERSIONS is not allowed to
be assigned from the build command. Instead, we can use
OVERRIDE_PRODUCT_EXTRA_VNDK_VERSIONS in the build command to
override PRODUCT_EXTRA_VNDK_VERSIONS.
Bug: 132412510
Test: OVERRIDE_PRODUCT_EXTRA_VNDK_VERSIONS=28 m vndk_snapshot_package
Change-Id: I91579961ab393f40ddce8bfe9304829b5b669441
Color the node nodes by their location to:
- /build/make/target/product/* => light yellow
- /vendor/* => light red
Test: m product-graph
Change-Id: I911764352e7dc4e2ead2b3770300f48d23dc20b8
os_version is important for keymaster version binding, where it
refuses to perform operations with a key that is bound to an old
system version. This ensures that an attacker who discovers a
weakness in an old version of system or TEE software cannot roll a
device back to the vulnerable version and use keys created with the
newer version.
Previously, os_version for system.img is added into boot.img header
for bootloader to read the value then pass to TEE before booting the
HLOS. However, with project Treble to modularize each partition, all
images are now in the trajectory to be built independently (still
on-going). Also, in the Generic System Image (GSI) compliance test,
the os_version in OEM's boot.img cannot reflect the actual version of
GSI.
This CL adds per-partition os_versions into AVB metadata, which is
readable by bootloader via libavb without file system dependency. It's
still unclear for how os_version in non-system partition should be used.
We just add them for completeness here.
See more details in:
https://source.android.com/security/keystore/version-binding
Bug: 132233601
Test: build and avbtool info_image $OUT/vbmeta.img
- Prop: com.android.build.boot.os_version -> '10'
- Prop: com.android.build.system.os_version -> '10'
- Prop: com.android.build.system.security_patch -> '2019-06-05'
- Prop: com.android.build.vendor.os_version -> '10'
- Prop: com.android.build.vendor.security_patch -> '2019-06-05'
- Prop: com.android.build.product.os_version -> '10'
- Prop: com.android.build.product.security_patch -> '2019-06-05'
Change-Id: I21a77420f2e8a3456f7a8cae5158eb8fc41319e7
They should only be in the Runtime APEX, c.f. discussion on
http://r.android.com/957159.
Test: build/soong/build_test.bash through Forrest
Bug: 124293228
Change-Id: I33e97a56e67c3f4734d14f38e0f1597b697a2604
Should be in product_config.mk, before the variables are readonly'd, or
the default will fail to work.
Bug: 131576555
Test: set PRODUCT_SHIPPING_API_LEVEL := 29 in mainline_arm64.mk && lunch
Change-Id: I25faee7ec0a3fff17e1d08b834d868834effda36
