* Now header-abi-dumper does not complain about -fno-sanitize=implicit-integer-sign-change
Bug: 119558057
Test: make checkbuild
Change-Id: I80be08dd5aa184498bdbb83b42b877dbec152165
Not all projects can be built when their base directory (the
directory containing the Android.bp file) is automatically included.
For example, external/jsoncpp has a file named version, which will
override the standard library's <version> header.
It would maybe be reasonable for this to be on by default, but many
projects in the tree currently depend on this behavior.
Test: make checkbuild
Bug: None
Change-Id: I58dff2689270ae56fef7cf83be31262d16794fc4
This reverts commit 4f0ce757aa.
Reason for revert: Breaks several targets in internal git_master, e.g. http://ab/5165971.
Test: Build failing library
Change-Id: I02a5ade05a76b24020586c55a4e8f441ca7708a9
Add dependencies for source modules when they are referenced in
library.Shared/Static.Srcs. Use ExpandSources to expand filegroups
for these properties.
Bug: http://b/120534727
Test: make
Change-Id: I58d02d8f7d60026abbcde75298c7a61b27bdbf12
* Add -fno-sanitize=implicit-integer-sign-change when
there is any integer related sanitizer, and this check
is not explicitly specified.
Android core does not boot with this new sanitizer yet.
* Filter out -fno-sanitize=implicit-integer-sign-change
from tooling flags.
Bug: 119329758
Bug: 119557795
Test: make checkbuild, boot, go/clang-r346389-testing
Change-Id: I709de569cb73d070fc4958e2b4387f4041bc5438
When a native module is built for an APEX and is depending on a native
library having stubs (i.e. stubs.versions property is set), the stubs
variant is used unless the dependent lib is directly included in the
same APEX with the depending module.
Example:
apex {
name: "myapex",
native_shared_libs: ["libX", "libY"],
}
cc_library {
name: "libX",
shared_libs: ["libY", "libZ"],
}
cc_library {
name: "libY",
stubs: { versions: ["1", "2"], },
}
cc_library {
name: "libZ",
stubs: { versions: ["1", "2"], },
}
In this case, libX is linking to the impl variant of libY (that provides
private APIs) while libY is linking to the version 2 stubs of libZ. This is
because libY is directly included in the same apex via
native_shared_libs property, but libZ isn't.
Bug: 112672359
Test: apex_test added
Change-Id: If9871b70dc74a06bd828dd4cd1aeebd2e68b837c
VNDK libs are system defined libraries. They must not be product
specific. Adding sanity check and a test to prevent setting
`product_specific: true` on VNDK libs.
Bug: 119575107
Test: building a vndk lib with 'product_specific: true,'
must return error.
Change-Id: Ie0326540a692573f076ee08baf5d2e2f09d1007e
Even though we aren't doing any linking for static libraries, the
default libraries (libc, libm, libdl) are now exporting headers, so we
should be using those for both static and shared libraries (especially
when re-using objects between the two). Without this we've been in a
state where a cc_library will compile differently than a
cc_library_shared, as we'd re-use the compilation units from the static
variant in the shared library.
This does require marking many of libc's dependencies as not using libc
with system_shared_libs, otherwise we run into dependency loops.
Test: treehugger
Change-Id: Ie42edc5184f315f998db953594e425214b810e0e
