Source tree may include prebuilt vndk snapshot libs that are newer
than or equal to the PLATFORM_VNDK_VERSION.
Ignore those prebuilt vndk snapshot libs.
Bug: 296488609
Test: lunch cf_x86_64_phone-next-userdebug; m nothing
Change-Id: I3adaf3b7636f53884f08540959d2ec2fddfb6921
expandSrcsForBazel always prefixed : in OriginalModuleName. The
exceptions to this are filegroups that appear in a different soong
namespace. For these cases, we were not correctly substituting the soong
module name with the equivalent bazel label.
Test: go test ./bp2build
Change-Id: If090f3f8819835177c1f4d191b3eef6bb6e30ace
Without an explicit deduping in this helper function, a dependency may
appear multiple times in the generated BUILD files. I noticed this while
converting some internal google tests.
This currently does the deduping for the non-configurable root value. I
ran into some issues deduping the configurable values, and I will
address it in a followup CL.
Test: go test ./bp2build
Change-Id: Ie7b588a9c922d72e4fabfb1414a7cc3dc402ff86
Revert submission 2713677-revert-2655262-move_java_api_libraries-JTESUMBERD
Reason for revert: Initial revert was created to resolve build breakage, but the breakage was caused because not all CLs included in the topic were being included in the build, and was not a problem of the CLs itself.
Reverted changes: /q/submissionid:2713677-revert-2655262-move_java_api_libraries-JTESUMBERD
Merged-In: If66b5bba719bb389a69f2353d2218a89b2b96b90
Change-Id: I879c9d3fb7427cfeff45fff423d4d536548e766f
Due to upstream changes in python path calculations, I'm simplifying the
python launcher to work more like a standard python distribution. This
is effectively changing the stdlib path from `internal/stdlib` to
`internal/python3.10` (or `3.11`, etc). This allows us to specify the
zip file as PYTHONHOME, set PYTHONPLATLIBDIR to `internal` and use the
default detection after that.
That does mean during upgrades that the stdlib pkg path will change, so
move the source vs prebuilt calculation from the Android.bp into Soong
to choose which stdlib module to pick up (with the corresponding
`pkg_path`)
Bug: 278602456
Test: treehugger with python3.10
Test: a python3.11 source + 3.10 prebuilt build
Test: a python3.11 source+prebuilt build
Change-Id: I8b02e7b22a1f1d1e02819ae1a31a99cdc985542c
This change moves java_api_library modules that were previously defined
in build/orchestrator closer to where their from-source equivalents are
defined.
Test: m (default to from-text stub build)
Bug: 274805756
Merged-In: If66b5bba719bb389a69f2353d2218a89b2b96b90
Change-Id: If66b5bba719bb389a69f2353d2218a89b2b96b90
Using Label struct as the map key causes issues because it contains
OriginalModuleName. The same module will have a different value for this
property when called from inside a soong namespace vs from outside.
If there are dups, we can just choose the first one. OriginalModuleName
is often used with ModuleFromName, and that function panics if there are
modules with the same name in two separate soong namespaces
Test: go test ./bp2build ./bazel
Change-Id: I2ee33efab03016a72f1eea99cb958b6198baeca2
Mostly so that genrules can have their command qualified on a product
variable.
Bug: 295910468
Test: m nothing
Change-Id: I28cc18a1b3b00368f4768a1326259a656ce970ec
We encountered a duplicate sources bug in python proto generation
because we're only using the base name. This CL makes it use the
entire path to avoid this.
Fixes: 295333879
Test: Presubmits
Change-Id: I4ab821508cd5979bd595e327c1ccd3d68110fba6
- Hide universal binary dependency for rust
Without a darwin_arm64 libstd prebuilt, many rust binaries are not
possible to build as a universal binary anyway. This fixes an
intermediate error with compiling rust FFI targets, where C++ shared
library dependencies for both architectures were combined into the same
linker command.
There is still an outstanding problem with C++ executable targets that
include rust FFI library targets, as the rust FFI library targets
fail to find a proper libstd to build the arm64 side of the universal
executable.
- Use dynamic_lib instead of soname
This matches similar logic in cc/library.go : linkerFlags for including
shared libraries.
Bug: 291830024
Test: m libkmr_cf_ffi (when enabled for darwin)
Change-Id: I1d6b6a7855c6649b93ab6592ea43b17c6e37b3a3
Because enabling ThinLTO makes some constructor functions not called
in arm64 executables.
Bug: 295944813
Test: build
Change-Id: Ic0cab5fd80aa86d0d9ca1131564b747a445c6e46
Since full_api_surface_libs extract class files instead of srcjar file,
full_api_surface_stub can be replace with android_*_stubs_current,
instead of the api_library android_*_stubs_current.from-text.
Functionally, the class files of the two modules are identical (in
from-text stub build), but depending on the from-text java_api_library
leads to missing dependency errors in partial branches (especially ART
branches). To resolve this problem, make sdk_library generated
api_library depend on the missing dependency handled
android_*_stubs_current.
Since android_module_lib_stubs_current.from-text does not have its
from-source equivalent, this can remain as dependency as the module is
moved to build/soong in aosp/2674196
Test: m (default to from-text stub build)
Bug: 274805756
Change-Id: Ic8bbd25252e5f9f1dc7c059ce6b00a951188985d
This is a fix for aosp/2693190 that handled .proto files that end up in
different bazel packages. It did it by creating proto_library targets in
the correct bazel package.
Changing the granularity causes issues if the the new proto_library in
the subpackage imports a .proto file from a parent package or a
different package. e.g.
```
tmp
├── foo.proto
└── subdir/import_foo.proto # contains an `import "foo.proto"`
└── subdir/Android.bp # package boundary
├── Android.bp # contains a cc_library with foo.proto and
# subdir/import_foo.proto
```
At ToT, the ProtoInfo we provide to CcProtoGen is correct, but the
proto_library in subdir/BUILD will not compile because it does not have
a dep on the proto_library in ./BUILD
This CL creates a workaround by adding `manual` to the proto_library
targets. This CL is based on the assumption that the buildable unit in
bp2build is cc_library_*, and not proto_library necessarily (atleast
till we do a manual/automated cleanup)
Test: Created an integration test in build/bazel
Test: go test ./bp2build
Bug: 292583584
Bug: 246997908
Change-Id: I73120be2411967cb144f37ed4417f76ecf1a6ffa
So that users can use soong config variables / product variables
to adjust a genrule's command.
Bug: 295910468
Test: m nothing
Change-Id: I9fedf8d5d52e515c3fdb913411ce1b3fecb7ba81
For device build, rust defaults to dylib linkage for rustlibs deps. `dylibs` prop was provided for flexibility.
By removing it, we're enforcing users to either use the default linkage (dylibs for device and rlibs for host) or rlibs prop explicitly. This means no dylibs for host modules. This makes sense because host modules always uses rlib linkage against libstd. The flexibility with dylibs prop opened room for linkage collisions because the dependencies don't link against libstd the same way.
Test: go test
Change-Id: I2fc221daa8a9bb42bdcf6d9823c723a4ddabe7b5
`Previous_api` is used to migrate nullness information in metalava (i.e.
convert @Nullable and @NonNull to @RecentlyNullable and @RecentlyNonNull
for some methods). The input is required to generate loosely equivalent
from-text stubs.
Test: m && compare nullness annotations between from-source stubs and from-text stubs
Bug: 293962901
Change-Id: Ic7a0868415fdb2c65d0d472e527fe73280b7651d
legacy.i18n.module.platform.api, stable.i18n.module.platform.api and
conscrypt.module.platform.api contributes to api surfaces, but the
corresponding stub libraries were being generated from source during
from-text stub build. This discrepancy may lead to hiddenapi failure.
Thus, enable these modules to be built from txt files during from-text
stub build.
Test: m
Bug: 274805756
Change-Id: I940dc8484b210bb8aea57ead1055983be7cdf5ec
