Move depsInfo into android for easier sharing with APK code.
Bug: 149622332
Test: m, diff'ing outputs for conscrypt module.
Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
This is a follow-up for https://r.android.com/1292915, which introduced
two-column format for the components of the boot jar list. This CL
fixes build failure for the coverage build.
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true
Change-Id: Ib8b156bf81943fe07084cbce5e7e9bf70e759a5d
This was causing build breaks when different devices moved to Android.bp
at different times.
Bug: 150878976
Test: build *_hwasan targets
Change-Id: I68912bb6a5696809c318d1ec816a1bcfbe2df245
Merged-In: I68912bb6a5696809c318d1ec816a1bcfbe2df245
(cherry picked from commit 7b6af23db6)
Shared lib dependencies of a test is included in the APEX regardless of
whether the test has test_per_srcs or not.
Bug: N/A
Test: m (apex_test.go amended)
Change-Id: I6b16843cc7467c42e250aba88d79d5580ba47324
This reverts commit 17d69e3484.
Reason for revert: This new field is not useful without dependencies in aosp
Test: builds
Change-Id: I87bd820cd6dbc5274ce3d28c4578381718aa805d
Merged-In: I70d6f7dc751510311b03e245b2189a76b395a49c
By the time we do argument parsing, we've already written to $OUT_DIR or
the default, so don't allow overriding the output directory on the
command line.
Test: m OUT_DIR=newdir
Change-Id: I6f8c07cbef3a71d393b766dc5a01ae9c3df8631c
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: Ic229159fdcdaf6182210a53b63850a389dd786fc
CC libraries which depend on Rust libraries get missing dependency
errors when building 32-bit variants dependent on Rust modules which
don't explicitly have "multilib: both" declared.
Because CC libraries use MultilibBoth by default, Rust should do the
same.
This also fixes a bug where the ARM32 toolchain incorrectly embedded
toolchain64Bit instead of toolchain32Bit.
Bug: 154730212
Test: Rust libraries provide both variants by default.
Change-Id: Ia545fe069d3c6b77c3d18f4f10267e2c72ee0bab
The stubs source should be generated using the same classpath that is
used to compile the implementation library, i.e. sdk_version,
system_modules and libs/static_libs.
Previously, the sdk_version used to generate the stubs was different.
It provided access to a wider API surface than was necessary. This
change fixes that.
Test: m checkapi
Bug: 155164730
Change-Id: I7bc54dc4ad12a7d6c7503111d1322ee35c56d713
This change fixes an issue with the definition of the
android_stubs_current (and similar) modules in the sdk tests. They were
incorrectly defined as java_sdk_library_import and not java_import.
Test: m nothing
Bug: 155164730
Change-Id: I4e9bfebdd2ff0a374e12284ccdf5ee5518968969
runtime_resource_overlay is put to an APEX via 'apps' property. It is
placed under ./overlay directory in it.
Bug: 154822536
Test: m
Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
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
Bug: 148447155
Test: built a testing apex with unsigned payload.
Merged-In: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818
Change-Id: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818
(cherry picked from commit 98410fd9d6)
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
