Make build system respect ALLOW_MISSING_DEPENDENCIES, when building
architecture B products, and ignore targets with dependencies that
are not available for architecture B.
Bug: 142701187
Test: # Add a dummy Android.bp with a module only for arm64
$ m -j TARGET_PRODUCT=aosp_x86 TARGET_BUILD_VARIANT=userdebug
Change-Id: I64de33674732df8c286671c806a07bcd19862b80
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
This was unnecessary in the past, when -nodefaultlibs was used while
linking, but that changed with
aosp/I722bd6596a1f3f5819f2767c29c0fa1e8b3ec0e8.
Test: simpleperf_ndk64.exe no longer depends on libgcc_s_seh-1.dll.
Change-Id: I435d7302906eb3758e758b5aefca8763bfba6290
apex_available property can be appended differently per the linkage
type. This will be used to restrict certain libs (e.g.
libc_malloc_debug) to an APEX while allowing them to be statically
linkable from platform for testing purpose.
Test: m (apex_test amended)
Change-Id: I6dec23129c5ac93a3ef06fea28f26f240c0ba410
If fuzzer coverage sanitized shared libraries are not deployed - we shouldn't
break users during dynamic link time. I need to think more about how we
should solve this problem in earnest, but for now let's just disable
static linkage of libc++ on device.
Bug: 142671952
Test: Cherrypick ag/9550833 and ag/9544155, make and run the fuzz target
there.
Change-Id: I39dfd6ba314e7a610ef3f0b30f35383a5e3a1e4b
With __ANDROID_APEX_<NAME>__ definition, native modules may have
different behavior when it is built for a specific apex module.
Previously, the name is passed as value of definition __ANDROID_APEX__
like -D__ANDROID_APEX__=com.android.foo. But it is difficult to do
conditional compilation with it.
Now, since the name is incorporated into definition itself, it gets
easier to set #ifdef condition.
Bug: 142582178
Test: m (soong test added)
Change-Id: I3c90c789fa692a19addf2e5a7c8d4cc571cde112
Older VNDK libraries are provided as vndk_prebuilt_shared modules. Those
are added to corresponding VNDK APEX as dependencies.
With VNDK APEX installed, VNDK libs are unnecessary. By the way, since
there can be vendor modules which depend on VNDK libs, Make targets are
still emitted with UNINSTALLABLE=true.
Android.mk has additional modules for vndk libraries which are named
with apex name as suffices. For example, if libfoo is a vndk library,
then libfoo.vendor is its vendor variant and it would be in
/system/lib/vndk. But with vndk apex, it has additional
libfoo.com.android.vndk.current variant.
Bug: 141451661
Bug: 139772411
Test: m (soong tests)
Test: boot with aosp_arm64 system image on Q vendor device
Change-Id: I269c28a4d4c4e2f1518bd51df558438fe5316774
Fuzz targets currently have dependencies on multiple libclang_rt runtime
libraries when building with ASan/HWAsan on device. This is an error.
This happens as Soong adds the dependency on the ASan/HWASan shared
runtime library. These libraries should provide the required UBSan
components. The clang driver was previously being passed
-fsanitize=fuzzer-no-link at link time, and as it doesn't know about the
already-established dependency on ASan/HWASan, it mistakenly thinks that
there is not runtime providing the UBSan components.
This patch fixes that problem by not adding -fsanitize=fuzzer-no-link to
the link-time flags.
This revealed a underlying issue in the upstream runtime compilation.
Android uses emulated TLS, which changes the symbol names from
<my_symbol_name> to __emutls_v._<my_symbol_name>. In particular, this
fails to account for the '__sancov_lowest_stack' symbol, as it no longer
matches the linker script rule for '__sancov*', and the symbol is no
longer exported in the shared library variant of ASan/HWASan.
This patch works around the discovered issue, which is being tracked in
the linked bug. It disables stack depth instrumentation, and we no
longer depend on this symbol. This means we get a missing sanitizer
coverage feature when fuzzing, but shouldn't be too detrimental.
Bug: 142430592
Test: SANITIZE_TARGET=hwaddress m example_fuzzer && \
readelf -d example_fuzzer # ensure only ONE libclang_rt dep (in this
case, hwasan)
Change-Id: Iea6df55d592a801732511c9b690134367429d62a
