libclang_rt.builtins has default visiblity set to public and is the
last included static library for all modules. This means that it is
possible for libraries to pick up libclang_rt.builtins from their
shared library dependencies, instead of libclang_rt.builtins directly.
Particularly, a vendor prebuilt in AOSP was picking up __floatditf()
from libhidlbase.so instead of from libclang_rt.builtins. A change to
libhidlbase.so that removed the symbol caused thos prebuilt to fail to
link at runtime.
Bug: 138809247
Test: build, boot internal
Test: don't see libclang_rt.builtins symbols in libhidlbase.so
Change-Id: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
(cherry picked from commit d000254202)
Merged-In: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
For all vndk snapshot libraries, header files exported by the libraries
will be included to the snapshot. Android.bp will contain necessary
information to link against/install vndk snapshot libraires:
export_include_dirs, export_system_include_dirs, export_flags, and
relative_install_path.
Bug: 132818174
Test: 1) m nothing && mv out/soong/build.ninja /tmp && m nothing &&
diff -u -u out/soong/build.ninja /tmp/build.ninja
Test: 2) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true \
development/vndk/snapshot/build.sh
Test: 3) development/vndk/snasphot/update.py
Test: 4) see contents of Android.bp and include directories
Change-Id: I791ab181545eb483242b04446afd40958bbb2b17
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
The NDK is built like this. Having it for app builds within the Android
build system allows us to distinguish platform code from app code.
This is specifically to distinguish AIDL interfaces using libbinder_ndk.
'myBinder-ndk_platform' libs will use additional functionality that
'myBinder-ndk' libs won't use (in the future, these may be separate
variants with the same name, see b/121157555).
Bug: 136027762
Test: using this to distinuish code in NDK vs platform code
Change-Id: I4de6f2e066982e7573ffd28cda44407d9e5648e4
libclang_rt.builtins has default visiblity set to public and is the
last included static library for all modules. This means that it is
possible for libraries to pick up libclang_rt.builtins from their
shared library dependencies, instead of libclang_rt.builtins directly.
Particularly, a vendor prebuilt in AOSP was picking up __floatditf()
from libhidlbase.so instead of from libclang_rt.builtins. A change to
libhidlbase.so that removed the symbol caused thos prebuilt to fail to
link at runtime.
Bug: 138809247
Test: build, boot internal
Test: don't see libclang_rt.builtins symbols in libhidlbase.so
Change-Id: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
This change fixes a problem in sanitizerMutator where a module is linked
with of non-sanitized variant of a lib at build-time, but is linked with
the sanitized variant of the lib at run-time.
This happened because, for each sanitizer type, every shared libs are
split into non-sanitized and sanitized variants, and then either of the
variants are suppressed from Make so that it isn't installed to the
device.
This change fixes the problem by NOT splitting for shared libs; only the
sanitized variant is created if needed. Header libs, static libs and
shared libs for a few sanitizer types (asan/fuzzer) are however split
into two. This is because the static and headers libs become part of the
depending module, and asan/fuzzer require that the depending module and
the dependant module should be compiled for the same sanitizer.
Bug: 138103882
Bug: 138426065
Test: m com.android.runtime.debug
Check that libziparchive exists under both
/system/apex/com.android.runtime/[lib|lib64]
Change-Id: Ia447785c485c0d049e19477b32bc638bfe6f1608
This commit adds tags, such as NDK, VNDK-core, and PLATFORM, to
LSDUMP_PATHS. The script updating the reference ABI dumps uses the tags
to determine the directories where the dumps should be created.
Test: make findlsdumps
Bug: 133176785
Change-Id: I8540286238cf0ec55c65e1c4f60cb9c12e5e57a1
Bug: 131771163
LTO is currently broken when building with SANITIZE_TARGET=fuzzer. The
compiler bug is currently being addressed upstream (see linked bug), but
we have applied a local workaround in the build system to disable LTO
when building using the fuzzer config.
There is a bug here however. In the sanitizer mutator we explicitly
remove -flto and add -fno-lto. The sanitizer mutator runs after the LTO
mutator, so (in general) this works just fine. The problem exists when a
target specifies an explicit 'lto: { ... }' flag in their Android.bp. In
this case, the sanitizer mutator disables LTO, then the flags are parsed
from the Android.bp, re-enabling LTO.
This patch fixes this issue. If the sanitizer mutator has added the
-fsanitize=fuzzer-no-link flags, then the LTO mutator won't add the LTO
flags after this fact.
Test: Build a target with SANITIZE_TARGET=fuzzer (or a cc_fuzz target),
where there is an explitiy 'lto: { ... }' and watch it now succeed in
building.
Change-Id: I6643909417f666539c23469816926b806e204b06
When no-vendor-variant VNDK is enabled,the vendor variant of VNDK
libraries are not installed.This should not be fit for recovery module.
Recovery module deps should be always installed.
Bug: 138812833
Test: `adb reboot recovery;` recovery mode boot ok
Change-Id: I0c3b8ac0fb0176677ddd94ba7216dd068f2eb81b
If sort_bss_symbols_by_size is true, a shared library is built twice.
The first build generates an unsorted output file, which is used to
generate the symbol ordering file. The output of the second build is
a shared library with its bss symbols sorted by their size.
With this, the only user of symbol_ordering_file, libc, is migrated to
use the new property, so we remove symbol_ordering_file support as well.
Bug: 135754984
Test: Build and check the resulting libc.so has its bss symbols sorted.
Change-Id: I5c892b44d82eb99cbc070cfa2c680be3087f3364
In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the
"all tests" ("") module as `module` for all `apexFile` objects created
from a test module using `test_per_src: true`. An immediate issue of
this situation was that the "" module is hidden from Make, which made
all the generated `apexFile` objects hidden from Make too. This would
break the construction of flattened APEXes, as they rely on Make logic
to install their files.
Instead of collecting `test_per_src` test variations' output files in
`cc.Module.GenerateAndroidBuildActions` and using them in
`apex.apexBundle.GenerateAndroidBuildActions` as part of handling the
"" variation as a direct dependency of an `apexBundle`, process them
as indirect dependencies (and do nothing for the "" variation direct
dependency).
Adjust the indirect dependency logic in
`apex.apexBundle.GenerateAndroidBuildActions` to allow not only
shared/runtime native libraries as indirect dependencies of an
`apexBundle`, but also `test_per_src` tests.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
Use Kythe (https://kythe.io) to build cross reference for the Android
source code. ~generate the input for it during the build. This is done
on demand: if XREF_CORPUS environment variable is set, build emits a
Ninja rule to generate Kythe input for each compilation rule. It
also emits two consolidation rules (`xref_cxx` and `xref_java`),
that depend on all Kythe input generation rules for C++ and Java.
The value of the XREF_CORPUS environment variable is recorded in the
generated files and thus passed to Kythe. For the AOSP master branch it is
`android.googlesource.com/platform/superproject`, so the command to build
all input for Kythe on that branch is:
```
XREF_CORPUS=android.googlesource.com/platform/superproject m xref_cxx xref_java
```
Each Kythe input generation rule generates a single file with .kzip
extension. Individual .kzip files have a lot of common information, so
there will be a post-build consolidation step run to combine them.
The consolidated .kzip file is then passed to Kythe backend.
The tools to generate .kzip files are provided by Kythe (it calls them
'extractors'). We are going to build them in toolbuilding branches
(clang-tools and build-tools) and check them in as binaries into master
and other PDK branches:
For C++, `prebuilts/clang-tools/linux-x86/bin/cxx_extractor`
for Java, `prebuilts/build-tools/common/framework/javac_extractor.jar`
Bug: 121267023
Test: 1) When XREF_CORPUS is set, build generates Ninja rules to create
.kzip files; 2) When XREF_CORPUS is set, building
`xref_cxx`/`xref_java` creates .kzip files; 3) Unless XREF_CORPUS is
set, build generates the same Ninja rules as before
Change-Id: If957b35d7abc82dbfbb3665980e7c34afe7c789e
