networkstack-aidl-interfaces-*java has explicit apex_available now.
Accordingly, remove it from the whitelist
Bug: 133526962
Test: m nothing
Change-Id: If5427afb2470a7dffbd418e1c405af508577ad93
Merged-In: If5427afb2470a7dffbd418e1c405af508577ad93
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
Soong was referencing the baseline file regardless of whether it was
valid or not.
Also update the lint message to match the one metalava itself prints,
which only suggests whitelisting the error if it's not possible to fix
it properly.
Bug: 154616909
Test: m (with lint error)
Change-Id: I4c6ec327a59aefe74825b4c4719393dd267ba3aa
Merged-In: I4c6ec327a59aefe74825b4c4719393dd267ba3aa
(cherry picked from commit 34ced82d2a)
A user was trying to use OUT_DIR=/tmp/...-out DIST_DIR=/tmp/...-dist
Test: OUT_DIR=/tmp/test-out DIST_DIR=/tmp/test-dist m nothing
Change-Id: I811cc8e1bda8d766406603df47309a8637cef48c
This makes it consistent with android_app. Also, most android_app_import
modules with JNI libs target a single arch.
Test: TreeHugger
Bug: 154281342
Change-Id: I5bbb2d2b733bbd6b868898285683ba5ff45be10b
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
Previously, errors that were found when splitting visibility rules were
only reported in the check phase and simply ignored during the gather
phase. That was because every visibility property that was processed in
the gather phase had already been checked in the check phase. However,
that is not strictly true as it has always been possible to add a
mutator between the check and gather phases that creates a module with
invalid visibility properties that will just be ignored. Fortunately,
that has not happened.
A follow up commit will add the capability to create modules after the
defaults have been applied which means the chances of invalid visibility
properties being ignored will increase.
This change makes both phases report any errors they find. It will not
have any impact on existing code as if any errors are reported in the
check phase then the build will exit before the gather phase. It will
prevent any invalid visibility errors from being ignored.
Bug: 155295806
Test: m nothing
Change-Id: I101fa6b03d2530b16e4394a9e466fead48be0ff0
Adds a couple of new methods to manage visibility property instances to
reduce duplication and encapsulate the implementation slightly better.
The AddVisibilityProperty method is exported as it will be needed by
other packages in follow up commits.
Bug: 155295806
Test: m nothing
Change-Id: Ic1a9bb1e151fc6ae65761344fd210b4e4ba74fbc
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
