load statements will all now point to rules.bzl files and won't have to
be constantly updated.
Bug: 271612705
Test: CI
Change-Id: I663b9730f1b5b333682ea301ce4d9a505626faaa
* changes:
Add an integration test for API export from another bazel package
Generate a BUILD file for every Android.bp file in api_bp2build workspace.
This revert was created by Android Culprit Assistant. The culprit was identified in the following culprit search session (http://go/aca-get/5b65d203-d364-4ade-aabb-1330fe45236a).
Change-Id: I10231bc624a15a2ba477712b3a5950f5fc9113e8
This test ensures that API export works ok if the api file exists in a
different directory (precisely, package) than the *_api_contribution
target.
Test: tests/run_integration_tests.sh
Change-Id: I1ff171b93773b514a9a081f962606f4c28abe42e
workspace.
This is necessary to solve bazel package boundary issues where the api
file might exist in a different directory
Test: m api_bp2build && build/bazel/bin/bazel build --config=android
--config=api_bp2build //build/orchestrator/apis:system
Test: multitree_build system/nothing (in multitree)
Change-Id: Id64085d65a1943bdb394ea80c875db96ca373839
api providing modules (droidstubs, cc_library etc.) can refer to the api
file via a separate filegroup module. Therefore these modules should be
generated in the api_bp2build workspace as well
Test: m api_bp2build && build/bazel/bin/bazel build
--config=api_bp2build --config=android //build/orchestrator/apis:*
Change-Id: I77371bd94a2794770b01b98aaf84b1bc42810841
Except if BUILD_BROKEN_USES_SOONG_PYTHON2_MODULES is set, and except for
some core py2 modules that can't be removed until python2 is fully gone.
Bug: 203436762
Test: m nothing
Change-Id: I62ccb6f5687eab1e79c372ffc234a90ca5b566ac
Currently, non-apex variants of modules that are in apexes are not
exported to make unless they're apex_available to the platform. This
means that you can't `m` those modules directly.
However, there is a workaround in the apex androidmk implementation that
emits make rules for the removed modules, but just redirects them to
build the apex itself. We want to remove that, but one of the problems
with doing so is that you can no longer `m` many modules afterwards.
To fix that, unhide the apex's dependencies from make. To ensure they're
not installed, call SkipInstall() on them, and update SkipInstall() to
be more strict by setting `LOCAL_UNINSTALLABLE_MODULE := true`.
Bug: 254205429
Test: Presubmits
Change-Id: Ib094feb2c437ad50d8319c58caa997759e7ce32f
PermissionImpliesUnsupportedChromeOsHardware
is ChromeOS specific and does not apply to the
Android tree, thus disabled.
UnsafeImplicitIntentLaunch surfaces false
positives and crashes in a specific corner case.
Disable until the related detector can surface
errors only when it is certain the intent will
get launched.
InvalidId gives false positives due to the package
name that is used in several places in platform.
Bug: 264608708
Test: TH
Change-Id: I441ba27a6fa97ed674145a051944dce4280692cd
to cover the recent features.
- conv_linker_config proto with empty input
- conv_linker_config proto with existing output
- conv_linker_config proto with --append
- conv_linker_config proto with --force
Bug: n/a
Test: conv_linker_config_test
Change-Id: I0de79b6e05c2608e0e2f30dfbf04d8289672f362
`conv_linker_config proto -s` should work with multiple json input
files, but ParseDict() overwrites list fields (e.g. provideLibs), not
appending elements.
Also added a test.
Bug: 264330513
Test: conv_linker_config_test
Change-Id: Idc482f941201f15e5fc276c0ffc0dfeaa09d0cc2
- Create the alias under the module-libapi directory. This is the
api_surface that cc_stubs_suite maps to.
- Create the alias only for "current" (atleast for now)
- Create one alias for the stub shared lib, and another for its headers
Test: b build @api_surfaces//... (with aosp/2475091)
Change-Id: Ib004c2c34256f971e74d75317fa5fbbe7273720e
The expected use case for this is to create aliases for stub libraries
in the @api_surfaces repository in build/bazel/api_surfaces.
This restricts the scope to just aliases. If we have a use case for
generating actual Bazel targets in another directory, a workaround could
be to generate the targets in the current directory (via
CreateBazelTargetModule) and aliases to it in the other directory
Test: go test ./bp2build
Change-Id: I6b63d9d018618d447fc7c260a2a94aaa00e57a4d
override_apex's bp2build converter had a bug where it was looking at
the product variables for the override_apex module itself instead of
for the base module it is overriding.
Fixes: 271424349
Test: go test
Change-Id: If1e2653d3751fa908faf0ab97dfa2e943ebe98ec
