Currently we document the semantics of these two symbols. I would like
to add some documentation about why this granularity is necessary. The
majority of the details are contained in b/191371676
Test: N/A (documentation change)
Bug: 265485106
Change-Id: I752c921eabceff94f92f24a46c9a16dc28a2af19
* Remove `Bp2buildCcLibraryStaticOnlyList` it is never set
* Remove the rest of the sutff related to it
* Streamline MixedBuildsEnabled
* Rename BazelContext.BazelAllowlisted to BazelContext.NameFilter
to reflect its action
* Rename bazelContext to mixedBuildBazelContext
* Fix minor warnings from Go static analyzer
Test: treehugger
Change-Id: Ie245c992f94bbfd5c7c23dd06917026200a28263
When a cc library has stubs, its static variant shouldn't be included in an apex to ensure the library with stubs isn't statically linked. See https://cs.android.com/android/platform/superproject/+/master:build/soong/apex/apex.go;l=2804;drc=89b01aeaa9e19377ff547baab791277719b8aaf3
This CL modifies bp2build so that it excludes apex_available tag from the static target if the library has stubs. This way, we can ensure that no apex can depend on the static target which results to static linking.
Test: go test
Bug: 255589949
Change-Id: Iedf248994b808436f2440570b094fd06d6284ae9
The developers can apply different configurations to vendor, product,
and platform libraries. In LSDUMP_PATHS_FILE, the vendor and product
variants are tagged with VENDOR and PRODUCT. Their ABI dumps will not be
generated in the directories under prebuilts/abi-dumps.
Test: make libutils.vendor libutils
Bug: 227282691
Change-Id: I747ceb174a070a67d592c5a47fcc848a6129661d
Because when stubs_symbol_file is defined on cc_library_shared, has_stubs is already implied to be true.
Bug: 260771171
Test: go test
Change-Id: I3b9a2cfb9000411d1b5f22da87dc339267775799
The fdo_profile targets are handcrafted in ag/20469925. Bp2build creates fdo_profile attribute on cc_library_shared and references to the fdo_profile target if the profile exists. This works under assumption that all afdo profiles have an associated Bazel fdo_profile target declared in the same folder/package.
As noted in b/253540178, this won't work when we check in the BUILD files (which is likely 6+ months away) because some profiles might only exist internally but not in AOSP. We will implement a long-term solution once we figure out all the requirements we need to support afdo both in Soong and Bazel.
Bug: 253540178
Test: go tests
Change-Id: Iebd5dd7a76583b4b2bf0d9ee56d58f247d313a54
Merged-In: Iebd5dd7a76583b4b2bf0d9ee56d58f247d313a54
The tags will then be read by an aspect applied from apex attributes to
validate that the deps are explicitly opt-in to the appropriate apex.
The semantics of this is the same as the Soong apex_available property.
This also adds the "base_apex_name" attr to override_apex conversion so
that apex_available checks continue to work on the non-Google and non-Go
apex names.
Test: presubmits
Fixes: 218841706
Change-Id: I19b3637da9aa47573b252d74f62b601fbdc3784d
The developers can specify ref_dump_dirs for shared libraries in
Android.bp. Each of the ref_dump_dirs generates a command to diff the
ABI with the reference dumps in the directory. The existing ABI diff for
VNDK, NDK, and Mainline are not changed.
Bug: 227282691
Test: make libutils
Change-Id: I62158393c8804200e96d538bc69c24147cb5caa5
ABI dumps in gzip are no longer supported because they cannot be
reviewed or merged.
Bug: 227282691
Test: make
Change-Id: I9fdf943fb8ae30aeae884d4d361a65034ab6fa94
- Move the logic that determines the versioned dump directories
from pathForVndkRefAbiDump to linkSAbiDumpFiles.
- Move sourceAbiDiff which generates the flags for ABI diff from
builder.go to library.go.
- Define two functions that generate the rules for cross-version and
same-version ABI diff.
Bug: 227282691
Test: make
Change-Id: Ic33799e86dd9ae627f5680b70973f96e15c030e9
When defining a stubs library, allow specifying that the
implementation library does not need to be installed. This allows for
cases where the implementation is deployed in some non-standard way -
e.g. inside a Microdroid virtual machine.
Without this, we get build errors like: "TARGET module
com.android.compos requires non-existent TARGET module: libvm_payload".
Default behavior is unchanged. The change is protected by an allowlist
to limit usage to the immediate use case.
Bug: 243512108
Test: builds; soong tests pass
Test: Remove allowlist, see build failure
Change-Id: Iaae75f2e93b842f5944a7518cc95069d62c5a638
The condition for vendor libraries is inconsistent between
getRefAbiDumpFile and linkSAbiDumpFiles. It causes the ABI check not to
be triggered for vendor libraries. This commit fixes linkSAbiDumpFiles.
The vendor libraries' ABI dumps are placed in the "platform" directory
for now. A follow-up commit will allow configuring the dump directory
paths.
Test: make
Bug: 227282691
Change-Id: Iad8f92145bce6264bf51efb4b8180bb917a1476d
IsLlndk() returns whether the library is an LLNDK stub. The ABI check
should identify LLNDK implementation by isImplementationForLLNDKPublic().
Test: development/vndk/tools/header-checker/utils/create_reference_dumps.py \
&& make
Bug: 227282691
Change-Id: I570871e24d9029992a722b3052f8bb6e7f3c0f52
Define CcApiLibrary Variants for LLNDK. Each variant will be defined as
below.
cc_api_variant {
name: "libc",
variant: "llndk",
arch: {
x86_64: {
src: "libs/x86_64/libc.so",
},
...
},
}
And CcApiLibrary will be marked to use this variant as below.
cc_api_library {
name: "libc",
...
variants: [
"llndk",
...
]
}
Soong will replace source of libc cc_api_library as src from
cc_api_variant during build time.
Bug: 244244438
Test: cf vendor build succeeded with LLNDK variants
Change-Id: I317ed1f558beb1f82f9f2d70811fa8f765bcad2b
Currently, it skips it for files in out/soong/. This was a valid
assumption since all intermediate artifacts in soong are placed under
out/soong, and soong modules cannot depend on make modules.
However, this might change in multitree, since the headers provided by
build orchestrator will be under out/api_surfaces (next CL in this stack). The good side effect
of this is that we do not retrigger a rebuild of soong/build.ninja if a
new API file (.h/.map.txt) is added to this directory (ctx.GlobWithDeps
adds the files to the deps of out/soong/build.ninja).
Test: TH
Change-Id: I3c3722390d04a50d793b1646df00cdf7acb12b49
The build uses unstripped binary/shared library to extract function
signatures, so for each each target of this kind Bazel should return
its unstripped version, too.
Fixes: 220164721
Test: treehugger
Change-Id: Id5f6143340519bf2ae98791a9e981d1306bb08d1
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
Currently, tagging a symbol with #apex is not required when the symbol
is in a non-NDK library. However, this is considered dangerous because
such a symbol will automatically be promoted to NDK APIs when the
library is promoted to an NDK library. When that happens, the native API
council won't be able to notice the promotion because promoting a
non-NDK library into an NDK library doesn't require an update of the
map.txt file, but Android.bp only.
To prevent that, we should mandate #apex (or #systemapi if the api is
provided by the system, not apex) tag for Mainline APIs regardless of
whether the library the API belongs to is an NDK library or not.
Bug: 184712170
Test: m
Change-Id: Iad589b606bc6ed06ef1237f4c9f0c22518b0db75
Overrides properties will now be captured in json flag files, which will
be copied to installed vendor snapshot modules.
Bug: 216567575
Test: soong test && manual install
Change-Id: Ife5e84b126e798fba7802b9cff000c9197756cb9
Context
- Android-<target>.mk currently does not contain information about partition for its dependent unembedded jni libraries, but only lists the name of the unembedded jni libraries.
- If an android_app module depends on an unembedded jni library that is located in a different partition, make cannot find the library.
Implementation
- Create a string field partition in jniLib struct.
- Add variable "LOCAL_SOONG_JNI_LIBS_PARTITION_<target>", an array of mappings of the name of the jni library to its partition.
Bug: 154162945
Test: m
Change-Id: I6b8e1272ff59dc70e3dd6ce8c6c8e4686dad76df
In Soong, aidl cc binding code is built with all the libs defined in the cc modules. In Bazel, because cc_aidl_library creates a cc_library_static target with the generated .h and .cpp files, it needs to depend on the libs from the parent cc modules in order to build successfully.
We can also consider including static libs but that requires a larger change to cc_aidl_library macro (e.g. renaming deps to aidl_libraries and preserving deps for static libs to be consistent with cc lirary macros).
This CL only adds shared libs (e.g. (implementation_)dynamic_deps) and ignore static libs for now since they're not needed for the modules currently allowlisted.
This fix is similar to https://android-review.googlesource.com/c/platform/build/soong/+/2219103/4/android/proto.go#207 for proto.
We can follow-up with adding static libs to cc_aidl_library later if needed.
Bug: 247151591
Test: presubmit is able to build allowlisted modules successfully
Change-Id: I40f14297f8c8f4c2a36b1e972d009824398b59cd
* changes:
Move function PathForVndkRefAbiDump to Prevent unnecessary exports in paths.go
Change the type of parameter prevVersion to int in sourceAbiDump
Support this in cc_{binary,library{,_shared}}
Bug: 204811222
Test: Suffix additions to cc_{binary,library{,_shared}}_conversion_test.go
Test: mixed_{libc,droid}.sh also builds newly allowlisted
Change-Id: I596694794b01b04c542cbcd7d54baeb7d914ba50
This CL moves function PathForVndkRefAbiDump from android/paths.go to
cc/library.go to prevent unnecessary exports.
Test: make libz
Bug: 239915696
Change-Id: I1270e8d07edb09d93621c049acab9196757d356b
