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
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, when BOARD_PREBUILT_DTBIMAGE_DIR is undefined,
make boot.img creation depend only on $OUT/dtb.img.
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
Merged-In: Iae2c634ccdc1d83589b26d382882f75fb8565a31
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)
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
