You can get a system.img without current VNDK libs.
This may help when you want a smaller system.img given that the image
will be used with a specific version (not current) of vendor image.
Bug: 132140714
Test: m TARGET_SKIP_CURRENT_VNDK=true && see if current VNDK is not
installed
Change-Id: Ie0815e6dd6ce2f861b6c42e637da4bb146320673
This enables mixed builds to use the file_contexts.bin from the system
build when regenerating images that come from system target files, and
similarly for file_contexts.bin from the other build when regenerating
images from other target files.
In monolithic (non-mixed) builds all image-specific selinux_fc props
point to the same file_contexts.
Bug: 132108151
Test: Built and booted mixed build devices.
Change-Id: Id51ed6d96ea6337879f1ab21d47c93c67bc25312
arm64 guest libraries are located in lib64/arm64
Bug: http://b/77159578
Test: lunch cf_x86_64_phone-userdebug in internal master; mm -j48 dist
Change-Id: I9f1f9426cbaed0a269126cb242e1a6df9249b167
Since aosp/887473 removed ro.expect.recovery_id,
There is no usage of "RECOVERYIMAGE_ID_FILE" which points
$(PRODUCT_OUT)/recovery.id.
Test: m && boot
Change-Id: I704af874b7e4141d2e006595242f7b681aa47f05
Running 'm samplecode' fails with
"build/make/core/main.mk:1834: error: overriding commands for target
`out/target/common/samples/libsimplejni.so', previously defined at
build/make/core/main.mk:1834"
This proves that noone has been using 'samplecode' target at least since
the build started generating both 32- and 64-bit shared libraries by default,
because development/samples/SimpleJNI/jni/Android.mk defines libsimplejni.so
as 'sample', and the deleted code in core/main.mk causes duplicate rule in
such case.
Test: treehugger
Change-Id: I38a4c478fcb0e60793129fe2513a8cdc6d2c79fb
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
This is the first commit to generate VNDK snapshot with Soong: .so
files, some txt files, and notice files are captured with Soong. As
ld.config.txt is currently in Android.mk and will be deprecated soon,
configs files (and zipping all of artifacts) are still handled with
Makefile.
Bug: 131564934
Test: 1) DIST_DIR=out/dist development/vndk/snapshot/build.sh
Test: 2) try installing vndk snapshot with:
development/vndk/snapshot/update.py
Change-Id: Ia904e8a1b44824d6c9556ada93bf1616620a1363
Values should be comma-separated, and things won't go down well
if there are multiple words in this variable.
Bug: 123783710
Test: Put this in product_config.mk and ran multiproduct_kati:
ifneq (1,$(words $(PRODUCT_CHARACTERISTICS)))
$(error oops)
endif
Change-Id: I5627f416093d68d8d19916a914739686b74d392f
This has been a warning for a long time. Make it an error instead.
Once this has been verified to not cause any problems, it can
likely be changed to instead default to setting
TARGET_SUPPORTS_64_BIT_APPS := true.
Test: build_test
Change-Id: I0d03fed2085009c64880a594d5a3aadf72187e60
Move the dexpreopt.config passed to Soong to out/soong/dexpreopt.config
and let it write a new copy in a rule and pass the path back to make
as DEX_PREOPT_CONFIG_FOR_MAKE.
Bug: 132379813
Test: m checkbuild
Change-Id: Iac29beac3af8864d36d1563ce42bed11b685548d
