cc_fuzz relies on an invariant that's not exactly true. We assume that
for each fuzz target, we'll only have a dependency on a single sanitized
variant of a shared library. In a few instances, this is proven not to
be true, as we end up with a transitive dependency on a shared library
with sanitizer coverage instrumentation, and one without sancov.
This results in breaking the packaging for some fuzz targets. This then
goes on to break `make haiku` in some scenarios.
While this isn't a completely technically correct solution (as we
basically resolve one of the sanitized variants pseduorandomly), it does
resolve the issue for now. Realistically, we should select *both* of
them, and set the DT_RUNPATHS on the shared libraries to point to the
dependencies that have the sanitization that they're expecting. In
practice - this shouldn't break sancov (we might just silently drop some
coverage) or hwasan (we might just silently drop some hwasanification).
I believe that the walk order of VisitDirectDeps is deterministic, and
as such this shouldn't affect the reproducability of fuzz target builds
(and thus won't blow up the Soong rebuilds). ccross@ or dwillemsen@ can
speak better to this than I can though.
Bug: 148306195
Bug: 151102177
Bug: 155123587
Test: lunch flame_hwasan-userdebug && make haiku
Change-Id: I8d4001d93da33e4e5d21f740beb88a20fcc26e2a
Test: m nothing
Test: Build an SDK snapshot including libc, check that the generated
cc_prebuilt_library_shared for it is a stub that doesn't depend on
ld-android.
Bug: 152255951
Bug: 154310674
Change-Id: Ie5ec02aebdf00b75756a6eda40db821488d30065
Adding the Soong header_libs dependencies to
module-info.json allows tools to more accurately detect
all module-level dependencies. This change adds
LOCAL_HEADER_LIBRARIES, populated from header_libs, to
the Soong's Android.mk prebulit module definition so
that it will propagate through the prebuilt into
base_rules.mk and eventually to module-info.json.
Bug: 151755703
Test: Find header_libs deps in module-info.json
Change-Id: Ic7134d33fa71822aae548ca097851dc0c1371bad
Also suppress some warnings/flags globally to pass compilation.
Bug: 149839606
Test: build aosp_arm64-userdebug.
Change-Id: I0ed740e51b6b39c58842a58eabcf3cdf404e73fa
This change adds 'test_for' property to cc_test_* types. The property is
used to mark a module as a test for one or more APEXes, in which case
the module has accecss to the private part of the listed APEXes. For
example, the module is linked with the actrual shared library in the
APEX instead of the stub of the shared library.
Exempt-From-Owner-Approval: already +2'ed by owner
Bug: 129539670
Bug: 153046163
Test: m
Change-Id: I45ed0d7a15540b0d69b2a3b8d9c4cb202adff6f2
"version" mutator creates stubs variants for "cc" libraries with
"stubs.versions". These stubs are for APEX-APEX or APEX-Platform
boundaries.
For host/ramdisk/recovery variants, stubs are not necessary.
Exempt-From-Owner-Approval: cp from internal
Bug: 153698496
Test: m
Merged-In: Id576c4318d9d69246a4a7e2fb4145d5fd2ab9416
Change-Id: Id576c4318d9d69246a4a7e2fb4145d5fd2ab9416
(cherry picked from commit c40b5193fe)
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Merged-In: I11a4e877ee27f7c55e2f00371c6fa58daedb1a9f
Change-Id: I11a4e877ee27f7c55e2f00371c6fa58daedb1a9f
min_sdk_version is the minimum version of the sdk that the compiled
artifacts will run against.
For example, when a module is used by two APEXes and their
min_sdk_versions are set to 29 and 30, then the module should support
both versions even if it is compiled against 30. Therefore,
min_sdk_version of the module needs to be set 29 in that case. In
general, this is set as the minimum value of min_sdk_vesions of APEXes.
For now, there's no build-time checks about this prop even if the prop
is set.
Bug: 145796956
Bug: 152655956
Bug: 153333044
Test: m nothing
Change-Id: I072ad8c317d2615e8b08e4e7ea2db8e7955b4b12
This CL adds a remoteexec package that allows adding a configurable RBE
prefix to the template.
Test: built aosp crosshatch userdebug with and without RBE_CXX_LINKS.
Change-Id: Ica920c3d7f79f2996210b9cbd448126451c1707c
It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Exempt-From-Owner-Approval: cp from master
Merged-In: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
(cherry picked from commit 424175d72a)
Installed name of prebuilt shared library should be stem or module name.
For example:
cc_prebuilt_library_shared {
name: "libfoo",
srcs: ["libbar.so"],
}
should install with the filename libfoo.so, and
cc_prebuilt_library_shared {
name: "libfoo",
stem: "libbaz",
srcs: ["libbar.so"],
}
should install with the filename libbaz.so.
Prebuilt Windows PE library should specify its import library.
For example:
cc_prebuilt_library_shared {
name: "libfoo",
srcs: ["libfoo.dll"],
windows_import_lib: "libfoo.lib",
enabled: false,
target: {
windows: {
enabled: true,
},
},
}
Bug: 151744695
Test: prebuilt_test.go && built walleye-userdebug
Change-Id: Ia8d0afb7fa46783c670870440432779c5fc7321a
For VNDK-Lite devices, which doesn't define BOARD_VNDK_VERSION, VNDK
APEX is built with only VNDK-Sp libraries with core variants.
Bug: 141908078
Bug: 152353068
Bug: 151635128
Test: TH
Merged-In: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
Change-Id: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
(cherry picked from commit 65d8a6262c)
Exempt-From-Owner-Approval: cp from internal
Change-Id: I0d08d32473368fd158818d4c2c72fc4cfad68ce6
The default build-id is generated using timestamp. Pass -Brepro to
avoid using timestamp for deterministic build.
Bug: 153462962
Test: build fastboot.exe twice, got same shasum
Change-Id: I38fe993eec23c60bfcf1b76188774bfe06839fa4
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: m
Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
(cherry picked from commit 29e91d2121)
* Disable it for the next clang compiler update
until all source files with this warning are fixed.
Bug: 153464409
Test: WITH_TIDY=1 make
Change-Id: I126d2f5170f3883192348577e523ef99f5c5a70e
Bug: http://b/153164546
Test: Built aosp_blueline successfully. Kernel also verified without
needing workarounds from LLD crash.
Change-Id: I41ae5a5be0065da98dd941b16196a3f4888b86b1
Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
This partially reverts https://r.android.com/1278193. The propagated
symbol files contain all versions, even though only one is applicable
in a given SDK snapshot.
It's uncertain what repercussions this might have, but one is that if
we were to update a snapshot for a fixed version then it might change
because the symbol file contains new versions that aren't applicable.
Since the symbol file isn't actually needed at this point it's better
to wait with this step until the use cases for it are more clear.
Test: m nothing
Test: Create an SDK snapshot with Bionic libs, drop it into a
master-art tree without bionic/ in it, build ART APEXes, and check
that the Soong phase completes (specifically that the stubs are
detected even without symbol files).
Bug: 152481980
Change-Id: Ic79f89bc6d11d0b6552fa20791f5680ff9a40c0d
