Create a select statement for every api_domain a library could be
included in. The stub/impl
selection heuristics per apex domain are
1. If dep has stubs and the api domain appears in dep's apex_available, use
impl
2. If dep has stubs and the api domain does not appear in dep's
apex_available, use stubs
(Category 3: If dep does not have stubs and the apex does not appear in
dep's apex_available, then a separate apex_available validation in Bazel
will emit an error).
Platform variants have been special-cased for now to use equality of
apex_available for stub/impl selection
Test: go test ./bp2build
Bug: 272378496
Change-Id: Ibd29efd763c8863c7e6d2a9af0da30bbde07175d
apex_test do not "override" the source apexes that they test. However,
similar to override_apexes, test apexes have the same path
(/apex/<apex_name>) on device. Instead of creating another property,
reuse the existing base_apex_name property. The use case for this will
be for creating selection statements for stub/impl selection.
Test: go test ./bp2build
Change-Id: I4b7548e0e0fc920e407e1c5e5c00e87efc6e70c9
Vendor snapshot libraries generated from prebuilt libraries set
"apex_inherit" to their min_sdk_version property to allow them to be
used by vendor APEXes.
Bug: 277403349
Test: m vendor-snapshot
Change-Id: Idd9e5f8e94b3fa2adf47a04507bf0c50c59edfb7
so that Vendor APEXes don't embed the LLNDK prebuilts (which are just
stubs of LLNDK libraries).
Bug: 280697209
Test: m nothing (soong test)
Change-Id: I9e6c123e73fa0ab56d8494a01652ee32a9b6a6cd
These libraries now set the correct apex_available in their Android.bp
files. Therefore, they do not a separate entry in the baseline
apexAvailable map.
Test: m nothing #passes
Bug: 281077552
Change-Id: Icf6b97c3bcc4bda96eefa14ba6d4bf10614bc378
The use case for this is for creating a select statement for stub/impl
selection. Since Bazel propagates apex_name from the top-level apex,
the source apex and test apex builds a specific library in two different
configurations. We need select statements for both these two
configurations, but this metadata might not always exist in Android.bp
since test apexes are not necessary to be listed in Android.bp files.
To overcome this, the select statements will be created per api domain
instead. This CL uses a naming convention to infer the api domain of
apexes.
Test: go test ./bp2build
Change-Id: Iad2b45f736bc98a24d2ce1cf2f69aad67973092d
This effectively undoes both If6c3ee82d588e2742c85cef7244c090c93f38b8e
and I682e4f1f477f3024f7719dfaa67006ef335e0640. SDK variants are now
installed again, which will fix unbundled builds of cc_test modules.
The platform variants used by com.android.virt are now packagable
even though they are not installable.
Fix the original problem in b/194403710 by adding a flag to platform
variants of modules in apexes that are not platform available, and
using that to prevent install and packaging dependencies. That
allows the HideFromMake flag to go back to being used for preventing
install dependencies but not packaging dependencies.
Test: TestPackagingWithSkipInstallDeps
Test: TestFileSystemShouldInstallCoreVariantIfTargetBuildAppsIsSet
Test: TestFileSystemShouldSkipApexLibraries
Bug: 194403710
Bug: 268582372
Fixes: 274443025
Change-Id: If5418df3ddbb940bd631caebdf38daa81e71f40e
Without respecting the relative install path, the snapshot install
path may collide when they use the same stem name.
To avoid this, respect the relative install path when generating the
snapshots.
Bug: 279652606
Test: RECOVERY_SNAPSHOT_VERSION=current m recovery-snapshot
Change-Id: Ic70a5855aeb2a6eda397b4dd06113dddb6ef70f4
These are created by bp2build in /build/bazel/rules/apex. Eventually
these config_settings should likely be colocated with the source apex
definition.
Another alternative was to make Bazel's apex a macro that generates a
config_setting. I did not pursue this further for now since it requires the
apex_available of every allowlisted cc_library to also be allowlisted.
This might not always be true (e.g. com.android.runtime)
Test: go test ./bp2build
Change-Id: Ibbb14b0d9c1491b3c79b7634a18d9d35b03922c1
The default ELF segment alignment will be 4096. This alignment
can be overriden by setting the desired alignment in
PRODUCT_MAX_PAGE_SIZE_SUPPORTED flag. The alignment has to be
a multiple of the configured kernel page size.
Test: Built changes for Pixel 4a, 6 and checked alignment.
Bug: 276963698
Bug: 276801883
Change-Id: Icb380041a5b27da1fa0d86b302e1e7cde9a236d7
If a library contributes to an API surface, it will have only a single
copy on device. Therefore, we should disallow installation to muliple
apexes/platform.
There are some exceptions to this rule today, and they have been relaxed
using allowlists.
Bug: 277651159
Test: go test ./apex
Change-Id: Ice3023ecd28412a2610d8b98628cb727b58c5c3b
Soong does not enforce apex_available on the contents of test apex. To
prevent special-casing test apexes in the apex validation aspect in
Bazel, drop the test apexes from the tags altogether.
( The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. apex validation happens
to be a nice side benefit)
Bug: 277651159
Test: go test ./bp2build
Change-Id: Ibb3cfedb5c0f2cda0464bf3758c70b67cb5885d1
The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. In Soong, this will be
enforced using some graph walk which is not easy to port to Bazel.
However, we might need to revisit this when we build the enforcement
mechanism in Bazel. We likely need a `test_for` on the top level
apex_test Bazel rule so that the test apex is _allowed_ to link against impl
of the library it is trying to test.
(This CL retricts this to cc_library, I can expand this to other modules
if this is the right approach.)
Bug: 277651159
Change-Id: Iaeec22c5626df79a33785c766ed29102b1da403e
Currently, there is little verification around allowlisted modules
actually being mixed-built. This flag would allow us to verify
that a module allowlisted is mixed-built for at least one variant.
Bug: 278910100
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
Test: m nothing --bazel-mode-staging --ensure-allowlist-integrity
--bazel-force-enabled-modules=com.google.android.neuralnetworks (This
fails, as expected)
Test: build/soong/test/mixed_mode_test.sh
Change-Id: Icd5976f4f44f1a8caca1e5247d986642f7995f97
This was disabled because of some non-determinism in Soong, which has
been been fixed in aosp/2559590
Bug: 275313114
Test: go test ./cc -run TestMixedBuildUsesStubs -count 1000
Change-Id: I261dc785c832e66f8e213132c19111b8b90e40e9
In addition to the license text files, include license kinds
information to json file. Also, use the original paths of license
text files that are copied to NOTICE_FILES directory.
This will be used when generating snapshots from the snapshot build.
Bug: 271539873
Test: m vendor-snapshot
Change-Id: I0c0427bb66f2c1fca322d5554aa66220a3b62fb3
This reverts commit 1db4348734.
Changes from original:
- extracted function to add the current version to stub
versions for bp2build.
- added libc++ to mixed builds denylist
Reason for revert: re-uploading with fix in topic
Change-Id: Ifa0ed456bf8cb4a7f861d6826263adfedb4fdd9c
Modifying the list in-place causes some non-determinism.
Test: go test ./cc -run TestStubsForLibraryInMultipleApexes -count 1000
Bug: 275313114
Change-Id: Ia2519e146d97667ad5900cf68ab9935fcbaf08a4
The Bazel rules don't currently support any sanitizers other than ubsan,
so we should disable mixed builds for modules which are sanitized.
Test: go test
Bug: 278772861
Bug: 253433725
Change-Id: Ia01fb8cb59154bdfb21a111b04af0350e1876b0b
system libraries (libc, libm, libdl) belong to the runtime apex api
domain. platform and other apexes should link against stubs and not impl
of these libraries. Update bp2build so that both apex/non_apex picks
stubs. These axes need to be more granular in the future, but for now
this works because
- non_apex axis (platform) is a separate api domain than the runtime apex
- com.android.runtime which matches apex axis has not been allowlisted
yet.
Test: TH
Change-Id: I43f429a90875f30d176db17b144dd51674ec8adf
We used to enable unique names only when a profile is available.
But A profile generated for a binary without unique names doesn't
work well when building a binary with unique names. To avoid a
chicken-and-egg problem, this CL enables the flag when afdo=true,
whether a profile exists or not.
Bug: 241523910
Test: build
Change-Id: I74d834510d81d2db76e34d0488c74a60e1fcecd5
Previously we were treating it as a shared library only, but
cc_test_library produces both a static and shared library.
Test: bp2build tests
Change-Id: I293d4246d581212b95765fa8f084301514d00dbf
in bp2build. The context here is that `-fvisibility=default` should
only be added for CFI if `-fvisibility=hidden` is not already
specified. This will be achieved using toolchain features. Note
that Soong itself never adds `-fvisibility=hidden`. This is only
ever added in the `cflags` property of a bp file.
Bug: 261733820
Test: Unit tests
Change-Id: Ib821e8c30a9cd03d2929b4bd2e771bec7b33fa66
We can just rely on the prod/staging allowlists which name the modules directly.
Test: presubmits
Test: m nothing; showcommands adbd_test | grep bazel-out
Fixes: 279004435
Change-Id: I666855d6bbe63c628256c3eebd7ae581c0cbdedb
