In a trunk stable branch, the ABI-monitored libraries under different
release configurations share the source code. The exported symbols are
filtered by version scripts and API level. header-abi-linker needs to
take the API level as a parameter.
Test: make
Bug: 308192597
Change-Id: I4b55b7ec023451b3a4cd1da308a1de10842d51d2
Product modules install required vndk modules in /product/lib[64].
But still the product modules can link to the llndk from system
partition using the list in /system/etc/llndk.libraries.txt.
To install /system/etc/llndk.libraries.txt file, use
llndk_libraries_txt singleton without versioned name.
Until VNDK is fully removed, the vndk apex must install the versioned
llndk.libraries.<ver>.txt file to the vndk apex.
Use llndk_libraries_txt_for_apex singleton for this purpose.
Test: lunch cf_x86_64_phone-next-userdebug; m
Test: atest GtsVndkDependencyTestCases
Bug: 299867815
Bug: 302255959
Change-Id: I058616081fe31597a9b76b772b69927807436896
More might be added later when we have an allowlist.
Bug: 305998969
Test: b build with the change in ag/25094394
Change-Id: I92df843ac81f4e33ce7506db61c989a380015975
(This CL is a cleanup, and should be a no-op)
Currently we support three variations of cc api stubs.
1. publicapi stubs, i.e. ndk stubs (empty additional args to ndkstubgen)
2. module-libapi stubs that are also an ndk library (--systemapi --apex)
3. module-libapi stubs that are not an ndk library (--systemapi --apex
--no-ndk)
ndk_libs.bzl was used to differentiate between (2) and (3). This creates
an additional layer of indirection - users will need to modify this
external .bzl file if they would like to add a library to an ndk.
Replace this with an explicit atttibute in cc_stub_suite macro for better UX.
Test: go test ./bp2build
Test: b test //build/bazel/rules/cc:cc_stub_library_tests (added in
sibling CL)
Bug: 299501496
Change-Id: Idd3579e8013bae7a1740534f90d2767df5bac1a5
The data attributes for cc library rules is dropped by their starlark
macros, so serves no real purpose. Furthermore, this unused dependency
proves problematic for allowlist v2, as there are many cases at HEAD
where the corner-case "requires" dependency would otherwise mark a module
as unconvertible.
Fixes: 303307456
Test: New unit test
Test: Manual verification to unblock allowlist v2 `bp2build.sh` runs in
AOSP
Change-Id: I6ca6104b958d2b428fc2ca5b3fa794106571acca
This is the bulk of the "allowlist v2" feature. It will disable bp2build
generation for modules which have transitive dependencies without a
bazel build definition.
This CL includes this mutator, but doesn't register it as a bp2build
mutator (outside of a few unit tests). This allows us to easily iterate
on completion of this feature and ensure there are no launch blockers
before we finalize the change in AOSP.
Bug: 285631638
Test: Unit tests
Change-Id: Ifb0a079c409ca19b02cafa3fab2efa0d3deebc50
This should be no-op, as the underlying mutator has not changed yet.
Some other refactoring is required and done in this CL:
- Delete some old, dead ApiBp2build code
- Fix casting to TopDownMutator when it's not necessary
This change is required to prepare for allowlist v2 work, as only
BottomUp mutators can AddDependency.
Bug: 285631638
Test: m nothing
Test: presubmits
Change-Id: I5212a5f5634cc13056195783e6df37ff8eb000da
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
cc_stub_suite now has an additional attribute correponding to the api
surface. This attribute will be used to pass additional args to the stub
generator.
Update bp2build to set the api_surface of the apex stubs. This ensures
that its stubs are generated with "--systemapi --apex"
Test: unit tests
Bug: 298085502
Change-Id: If4c479f85e6e485b5c795a565a0c559f1f013bf5
Install VNDK libraries into vendor or product lib when flag
'KEEP_VNDK' is set as false from build. This flag will be used to
test while deprecating VNDK step by step.
Bug: 290157355
Test: build succeded with DEPRECATE_VNDK succeded
Test: Cuttlefish boot succeded with sepolicy disabled
Change-Id: I05b166f054113ae2775df4e310916d0ea4af3fb6
Normally, the users of opt-in ABI check do not enable it for all
architectures. The error message instructs the users to update the ABI
reference dumps for the product failing on the check.
Test: make
Bug: 254141417
Change-Id: I19d28c83a3485266a190ba8abc9ddfb8deeb5106
Use Go's generics for DepSets so they don't require a type-specific
wrapper and reflection.
Test: depsets_test.go
Change-Id: I22ba0b7d680d37d2cd05230b0f560d166c4dd20b
By default, the artifacts generated by cc_binary and cc_library in Soong
track the module name. But Soong supports overidding this using the stem
property. e.g.
```
cc_library {
name: "foo.1.2",
stem: "foo",
}
```
will generate foo.so
This CL adds this property to bp2build
Test: bp2build unit tests
Bug: 240563612
Change-Id: I1dfed870d5bad450511b72c397d2355c01fa3b60
Bug: 279960133
Test: go test
Test: Remove hdrs prop from IDropBoxManagerService_aidl && run BUILD_BROKEN_DISABLE_BAZEL=true m libservices && Expect an error from aidl
Change-Id: Ifdb260d8e2da9a5767f1e212393de4134b210616
https://source.android.com/docs/core/architecture/aidl/aidl-backends#custom-parcelables
Some aidl files have custom parcelables with references to cpp headers. Hence, we need to pass the include dirs from cc libs to cc_aidl_library so that custom cpp headers are findable by the generated cpp/h files.
Test: go test
Bug: 278704136
Change-Id: I4ede1d23fbc04bdbfb69823d955c6df6b0a7b4ee
Introduce aidl.libs prop on cc libraries to pass in aidl_library. The goal is to eventually disallow aidl.include_dirs (a pattern for passing aidl headers dir for aidl compilation) and enforce aidl headers to be explicitly specified in Android.bp.
Bug: 278704136
Test: go test
Change-Id: Ia78bc11dfa12f47d2d1bb90dc65372ddb17f7e14
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
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
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
This reverts commit ca438e6b72.
Reason for revert: ci post-submit failures in aosp-master-bazel of targets mixed-droid-clean and mixed-droid-incremental:
FAILED: ninja: 'out/target/product/generic_arm64/obj/SHARED_LIBRARIES/libc_intermediates/libc.so.toc', needed by 'out/target/product/generic_arm64/obj/EXECUTABLES/updater_intermediates/LINKED/updater', missing and no known rule to make it
12:21:27 ninja failed with: exit status 1
Change-Id: I081b499d23f2568cdf6227c4e3b0278164086b69
Bug: 270408757
Test: go test
Test: m NeuralNetworksTest_shared_partial --bazel-mode-staging
&& verify that Ninja commands link libneuralnetworks via stubs
Change-Id: I19bf5a829cea7fd00c0f82511ad2bddbc40fae4f
libc_hwasan is a new library in the runtime apex that lives in
bionic/hwasan/libc.so and is symlinked to /system/lib64/hwasan/libc.so.
This is chosen by the linker if an app or binary requires HWASan
support.
Bug: 276930343
Change-Id: If331744ad84241ad99a41805ea3110d37cf9b0af
We've been fixing this up on the NDK build side for ages. The
platforms/ subdirectory is a legacy thing from very old NDKs. Fix the
install paths to match what the NDK actually uses. This both lets us
delete some code on the NDK side and also makes the platform's output
easier to consume directly without having to wait for an NDK release
(or even a canary).
Bug: None
Test: treehugger
Test: inspected out/soong/ndk/sysroot
Test: build/soong/scripts/build-ndk-prebuilts.sh, imported into NDK
Change-Id: I3c4e0ce6d7960ae0138d1cf803755e4f1e575631
The static deps of the parent library can be necessary to build a
bp2build-generated cc_aidl_library target. We should add these deps as
implementation_deps so that they are accessible.
Bug: 250876486
Test: b build //frameworks/native/libs/gui/...
Change-Id: Ibe7c3598a684907473e2a4e040fb3976455a59e9
This reverts commit 502da3987a.
Reason for revert: b/274195633
```
In file included from out/soong/installs-aosp_cf_x86_pasan.mk:134984:
In file included from out/soong/Android-aosp_cf_x86_pasan.mk:981696:
In file included from build/make/core/soong_cc_rust_prebuilt.mk:76:
build/make/core/base_rules.mk:342: error: packages/modules/Uwb/service/uci/jni: MODULE.TARGET.SHARED_LIBRARIES.libuwb_uci_jni_rust already defined by packages/modules/Uwb/service/uci/jni.
```
Change-Id: Ic1ea6969e54c23a7d126eb0fb47ab6f2e44ee965
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
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
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
