rust_protobuf were unable to import protos from other rust_protobuf
modules. This CL adds support for that. rust_protobuf modules which are
listed in rustlibs will have their modules imported into the generated
protobuf stub. Additionally, rust_protobuf modules which define
"exported_include_dirs" will export those include paths to dependent
rust_protobuf modules.
Bug: 301266700
Test: m rust
Change-Id: I132edffa4d77e0ac80a7ac934f873374c8e94c1b
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
android_library does not accept deps when there are no srcs because
there is no compilation happening. The libs of android_library module
are unnecessary as deps on the android_library since they aren't
being propagated to any dependencies.
So we can drop deps here.
Test: the updated test case and CI
Bug: 302290600
Change-Id: Ib43a1c273a5f3b3e0aa6f29f4e8569ad3487e451
APIs annotated with @FlaggedApi should not be included in the artifact
when building sdk target products in the "next" release configuration.
This change adds such logic by passing additional flag to metalava in
droidstubs.
The flag does not need to be passed to metalava invocation done in
java_api_library, as java_api_library generates stubs using api
signature files (i.e. *-current.txt files), and they will not contain
apis marked @FlaggedApi. The metalava invocation in droidstubs is
responsible for removing such apis.
Test: go test ./java && m TARGET_PRODUCT=sdk TESTING_TARGET_RELEASE_NEXT=true nothing and inspect ninja command for generating stubs and verify the flag is included
Bug: 299570421
Change-Id: Ia4b699b6e3ff6324f050eecc9ff5b622fdc04621
The variable is a release config variable which will be used to
determine whether if the api marked @FlaggedApi is exposed or not.
Test: m nothing
Bug: 299570421
Change-Id: I5647608065543cf5059836f6d6e8906a23145541
Test: go test soong tests
Test: verify no NeuralNetworksTest_random_graph sdk variants in
build.ninja when aosp_x86 is lunched
Bug: 302093869
Change-Id: I6429aa75518cca6974abcf7330236a6a07135ea1
Error message in case of not valid "nextAbiDump" included wrong
"prebuiltAbiDump.InvalidReason()". Refactor error message to include
"nextAbiDump.InvalidReason()" instead.
Change-Id: I2581734dd16649af2b282b3459f461658abd3d87
Signed-off-by: Aleksei Vetrov <vvvvvv@google.com>
The code previously assumed an annotation meant there was no package
declaration, but package declarations can be annotated. Update the
code to consume any leading annotations.
Bug: 151360309
Test: jar_test.go (& manual verification on full bootclasspath srcs)
Change-Id: I3de5a2a675363fc3627a278103dd2cabe80a2d80
java_library rules with javac_shard_size set split the sources into
shards to invoke javac multiple times, but were using a single javac
invocation for all srcjars. For fraemwork-minus-apex, this srcjar
shard was the long pole at 15.7 seconds, containing 266 srcjars with
1542 java files with a total of 614593 lines.
Use a rough approximation of 5 sources per srcjar to determine the
number of shards to split the srcjars into based on javac_shard_size.
This results in splitting the srcjars for frameworks-minus-apex into
8 shards, with the longest taking 10.5 seconds to compile.
The longest shard contains most of the aidl srcjars, which have been
generated by sharded groups of 50 aidl files and have a much higher
average number of sources per srcjar (a mean and median of 27). A
future improvement could be to shard those separately assuming a
higher number of sources per srcjar.
Bug: 302033097
Test: USE_RBE=false m frameworks-minus-apex
Change-Id: I85e740c7fcf5651cf18c0cdc90ab8c6ee39cb47b
We only supported bp2build for rust_protobuf_host because the non-host toolchain for rust is not checked in yet. aosp/2759750 changed a converted module from rust_protobuf_host to rust_protobuf and broke CI.
This CL adds bp2build support for rust_protobuf but makes the target incompatible with android os for now untilnon-host rust toolchain is checked in.
Bug: 301956497
Test: b build //build/make/tools/aconfig:all --config=android
Change-Id: I739896c79f32674000c2603e394f16860a6fc57d
This target will have a dependency edge to every bp2build equivalent of
Soong's ndk_headers. In b builds, sdk variants will compile against this
aggregated CcInfo providing target
A non monolithic alternative was discarded after conversations in
b/300504837#comment1-5
Contents of bp2build generated target: https://paste.googleplex.com/6643820291686400
Implementation details
- Since there is no equivalent Soong module for ndk_sysroot, hardcode
bp2build/build_conversion.go to collect all ndk_headers soong modules.
Add them to `deps` of a ndk_sysroot target
- Create `ndk_sysroot` in build/bazel/rules/cc/BUILD.bazel. This is
expected to be a temporary location. This will use the
cc_library_headers macro
- Update SetStubsForDynamicDeps so that sdk variant of rdeps depends on
//build/bazel/rules/cc:ndk_sysroot. This will provide a CcInfo during
compilation. Since ndk_sysroot is of type cc_library_headers, it will
not get packaged into the apk.
- Refactor `goBazelTarget` to a generic `bTarget` so that it is
representative of the expanded usage by ndk_sysroot
Test: b build //build/bazel/examples/android_app/java/com/app:app_with_sdk_variant_of_jni_deps --config=android (with aosp/2755284)
Bug: 300504837
Change-Id: Ifa427dd78115703ab251b0e1a0b71d3f19e91008
This change imports NextReleaseHideFlaggedApi exported from soong_config
Test: m nothing
Bug: 299570421
Change-Id: I410596a39d2ba9ad353c5cf48bd38b1e843633b2
