These bazel-built modules will be installed into the system image
as part of the bazel rule, rather than going through the make staging
directory.
Bug: 297269187
Test: m bazel_sandwich
Change-Id: I96c6e58f8e0898b2ad92cb7069745ca2059a39f8
Bug: 304814040
Test: CI, unit test,
b build build/make/tools/aconfig:aconfig.test.cpp
b test build/make/tools/aconfig:AconfigJavaHostTest
Change-Id: I9ca939348a063c39e9528f24e788f9757458d30c
Bug: 297269187
Test: m bazel_sandwich (updated partition_inspector to show selinux contexts, but still haven't figured out how to show avb information)
Change-Id: I6911c2fc75495f9722887925d8609c9a171901c6
Because we're going to start generating partition images for the
product, and the partitions will eventually be checked in, we want
them to be in sensible locations. And the platform should be there as
well so all the targets for a product are co-located.
Bug: 297269187
Test: m nothing && b build --config=android //build/bazel/examples/apex/minimal:build.bazel.examples.apex.minimal
Change-Id: Iaa25c44aa00295ada279d5fd49b5498bbafb89d5
The logic of EffectiveVersionString is product-variable dependent and
is being implemented bazel-side in order to produce product agnostic
BUILD files. A required additional product variable is added to the
export list, and the "updatable" property of android_app is also bp2build-converted.
Handling of max sdk version was not correct (it does not affect
manifest values in Soong), so removing it for now.
Bug: 274474008
Bug: 274474002
Test: CI
Change-Id: I7a10bfabf914c8e86064b7ce61926701f87517e3
Previously, partners were required to add an
android_certificate_directory filegroup in their certificate
directories, and allowlist that BUILD file. Now, we generate the
filegroup automatically.
We're using a different name, generated_android_certificate_directory,
to avoid conflicts with already-checked-in filegroups.
Bug: 285777389
Test: b test //build/bazel/rules/apex/...
Change-Id: Ib1bde487acd79d58368faf0aad02ded0bcdaceb4
To maintain good backwards compatibility with the legacy partition
building behavior, allow actions to read
BUILD_BROKEN_INCORRECT_PARTITION_IMAGES so that we don't have to rerun
analysis.
Bug: 205632228
Test: Presubmits
Change-Id: I2b55c0143cbdaf010e6b5fd0c3d51d6930a94eff
Soong adds "--no-ndk" to cc stubs for apexes if the library is not an
NDK library. In order to port this logic, emit the list to a .bzl file.
We cannot use the exportedVars.Export* soong_injection api for this
since we need to visit all modules to get this list.
Test: m nothing
Bug: 299501496
Change-Id: If8487db85e08b32b9b40aef3371d9f3f7d5a77e0
That build doesn't set platform_sdk_version.
Bug: 269577299
Test: ./prebuilts/kernel-build-tools/build-prebuilts.sh on the kernel-build-tools branch
Change-Id: I68eb33bfb80770cef9c3a9c5e01f1ed746a2d069
...instead of based on constraint settings.
Bug: 269577299
Test: m nothing and ./build/bazel/ci/bp2build.sh
Change-Id: Ib9caec79c92b8fd304e46be841de5612bd1637e3
Revert submission 2651299-bazel_sandwich
Reason for revert: b/293883239, checking if this breaks the build.
Reverted changes: /q/submissionid:2651299-bazel_sandwich
Change-Id: I5f1d4bb13d21e6599f5c353dcaba2375f5ec234d
The "bazel sandwich" is a mechanism for bazel to depend on make/soong
outputs. The name comes from the fact that bazel is now at the top
and bottom of the build graph. This is intended to allow us to work
on converting the partition builds to bazel while not all of the
dependencies of the partition have been converted.
It works by adding the bazel_sandwich_import_file rule, which emits a
dangling symlink that starts with bazel_sandwich:, and includes
information that the aquery handler in soong reads. The aquery handler
rewrites the symlink so that it points to a file generated by
make/soong, and adds a ninja dependency from the symlink to the file
it's targeting.
This allows us to depend on make-built files from bazel, but notably
it doesn't allow us to depend on analysis-time information from make.
This shouldn't be a problem for the partitions, but limits the use of
the bazel sandwich to similar, less complicated types of builds.
go/roboleaf-bazel-sandwich
Bug: 265127181
Test: m bazel_sandwich
Change-Id: Ic41bae7be0b55f251d04a6a95f846c50ce897adc
This allows us to set product variables as build settings instead
of loading them from a target's provider, which further allows us
to read product config variables in transitions.
Bug: 287539062
Bug: 269577299
Test: Presubmits
Change-Id: I8497703f706162572ceb3486240e1eb02a37f5f6
This is a followup to aosp/2606989.
This flag is not necessary now that we're using one platform name
for all of mixed builds.
Also rename current_product to mixed_builds_product so that it's clear
that that this platform should only be used for mixed builds.
In addition, make the bazelrc files point to the named products again
instead of the mixed build product so that b builds will still have
qualified outputs, but mixed builds won't.
Test: Presubmit and kernel build tools abtd run
Change-Id: I7f764cf42cd1323f4b495d1320931f59a076ac63
This is a followup to aosp/2606989.
This flag is not necessary now that we're using one platform name
for all of mixed builds.
Also rename current_product to mixed_builds_product so that it's clear
that that this platform should only be used for mixed builds.
In addition, make the bazelrc files point to the named products again
instead of the mixed build product so that b builds will still have
qualified outputs, but mixed builds won't.
Test: Presubmit
Change-Id: I5acbd18869589f67efb0ad3ebfda2c4d5a6a3850
This enables output paths of product agnostic targets (e.g. mainline
apex) to be identical when switching between target products, since the
product name is no longer embedded in:
1) the output path prefix in bazel-out
2) the PlatformOptions contribution to the configuration hash as part of a transition
Test: treehugger
Change-Id: I3fd0f7134209aa7eede3ed98412a1c5482689b57
See the other cl in this topic for more information.
Bug: 269577299
Test: b test --config=android //build/bazel/rules/apex:all
Change-Id: I1f20bc5f85398cd79dc5b7fe9d0bd4d93d442383
These must be added in the soong_injection code as opposed to just
defined loosely in checked-in bzl files because the product_vars
select statement must be updated to support the new platforms.
Bug: 269577299
Test: b test --config=android //build/bazel/...
Change-Id: I7bba9af214896dd3b5938bae70b7c0cea4f75e41
Create a
build/bazel/product_config/generated/products/<product_name>/BUILD
file that contains the platform definitions needed for
a particular product. Currently we just create it for the
current lunch target, but the idea is that eventually when
all product config is in starlark, all the products will
have their platform definitions in the tree at once.
Bug: 249685973
Test: Presubmits
Change-Id: I08c82ff28dcf62f09d3b1d2e3186a6b961e12f6e
