BUILD files of rdeps should depend on stubs via @api_surfaces
indirection. e.g. instead of depending on
//system/logging/liblog:liblog_stub_libs_current, it should depend on
@api_surfaces//module-libapi/current:liblog. This ensures that the
generated BUILD files are compatible with Multi-tree.
Update the unit tests for this change.
Test: TH
Change-Id: Ibcc36dcfbee7b1973b341485f015e67987564dcc
This is part of the changes needed to switch to jdk17 as the default.
Test: presubmits
Bug: 215230098
Change-Id: I4dad9f576c88bdc98f329a35fb8a1eb1527b1366
This will enable its bp2build conversion, and is needed for java_system_modules support in Bazel
Change-Id: I4f3ff5e36c8cd7f78efbb42f641efb2f76a8b71d
Bug: 215230098
Prevents inconsistent load locations from being added for java_library,
android_library, kt_jvm_library targets that are generated in multiple
places.
Change-Id: I66ae5af137d7dff3f6fa6660dee539cf9ab22b9e
Test: go test ./bp2build
These are used to build com.android.neuralnetworks and
com.android.media.swcodec.
Bug: 273927900
Test: b build --config=android //frameworks/av/apex:com.android.media.swcodec
Test: b build --config=android
//packages/modules/NeuralNetworks/apex:com.android.neuralnetworks
Change-Id: Ia36d6e3419fb5034f1dbf410da738fcbf98d6874
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: Ib971981559f3b642ce6be8890679e994e1b44be0
This CL adds a few things:
1) Populate the filesInfo struct with cquery'd information from an
apex's ApexMkInfo provider. This filesInfo is then used in
apex/androidmk.go to generate Make modules (soong_cc_rust_prebuilt.mk),
which are then used in packaging to generate zip files of symbols in $PRODUCT_OUT.
2) Make a list of dicts of primitives JSON-encodable.
3) Tests.
Bug: 271423316
Bug: 271423062
Test: presubmits
Change-Id: Iaa34f51044de310510e580d9cf1fe60bbef801c1
1. extract .ninja_log as const
2. log an error during reading .ninja_log
Test: m nothing
Bug: 271527305
Change-Id: I395dd8419620bfa9fad3af23c96e5a22ca44e2fb
Since the source_library attribute of _cc_stub_library_shared was a
label attribute, the source library was added as a dependency of the
stub which doesn't always make sense. E.g. it caused validation actions
for the source library to run even when we weren't building the source
library.
This change converts the label attriubte to a string attribute so that
we don't add the dependency.
Bug: 263390551
Change-Id: I19c62d1e14847dff68ab37156452addaa119eaf9
It has 3 options for now.
* ninja_log: uses ninja log file for data source
* evenly_distributed: pass empty list for ninja to consider every work as the same
* not_used: do not use critical path logic in ninja
In addition, I added the option in the metrics to track
Bug: 271527305
Test: m --ninja_weight_source=ninja_log|empty|not_used
Change-Id: Ib4c812c20606a34b17d3f0edb71057b477c4f90e
When evaluating whether to build the VNDK for the multi-target
configurations, we construct the API level based on the VNDK
version. When the VNDK version is 'current', we replace the
version name with the platform SDK version e.g. 'UpsideDownCake'.
For architectures that currently have a MinApiArch of FutureApiLevel
(i.e. 'current'), comparing 'UpsideDownCake' with 'current' will
assume 'current' is at a higher API level and skip building the
VNDK.
Before perofrming the API level comparison, we check that the VNDK
version does not match the platform VNDK version. If true, it is
necessary to disable the VNDK when it does not meet the minimum API
level for the architecture. If false, we skip this check and allow
the VNDK to be enabled, as this implies we are targeting the 'current'
VNDK version and should include the target platform VNDK.
Test: m (soong test) & boot
Change-Id: Iacc33d2858fef670ddfdff5bbde9d32b084979c9
The standard go tooling assumes that a package's binary name should be
the name of the containing folder. Before this change, `go install` or
`go build` (without `-o`) names this binary `cmd`.
Test: treehugger
Change-Id: I45a4e97f4a0d59744d644e30636250ceefe3bd1c
Rust snapshot must have proper suffix for androidmk to avoid conflict
with the existing modules.
Bug: 230780263
Bug: 235895567
Test: m nothing
Change-Id: I35794196553621cd722c067d7965b2a61aa351bd
Add a flag that enables logic specific to multitree-build builds.
Bug: b/266730267
Test: treehugger, manual
Change-Id: Ia6f392525faa9d66bb6e0692b2a2e9c3b8493b0d
This reverts commit 1e75eccb18.
Reason for revert: The SBOM generation change has been submitted in aosp/2485540, so its integration test in this change should be ok to submit now.
Change-Id: Idb8c84a871b2a5633bed998eb7483fc91d30e97a
Bazel boolean attributes can only support true or false states, but the
clang-tidy logic changes for modules which don't set a specific value.
Therefore, the tidy attribute should really be a tri-state of "true",
"false", or "" (unset).
Test: b test //build/bazel/rules/...
Bug: 268681923
Change-Id: I85fbaa612d175f475757db806cea6c018901fe3e
For the data to prioritize long running tasks in ninja, I added the
information about that.
Bug: 271526845
Test: build and check metrics
Change-Id: I76807f9b0d6a50d940b5f35dd6a9ef3cf693eec5
