tldr: remove protobuf2 from Android Rust and upgrade everything to pb3.
These commits update:
- The grpcio rust crate to use protobuf 3
- The build system to always use the new libprotobuf (pb3) instead of the _deprecated variant (for pb2); they also force-enable libprotobuf everywhere, ignoring the use_protobuf3 flag, removes the tests related to pb2
- The following modules, which required syntax changes:
-- packages/modules/Bluetooth
-- device/google/cuttlefish
-- vendor/auto
Bug: 308790516
Test: m rust
Ignore-AOSP-First: must be done in main to upgrade cuttlefish+vendor with the rest all at once
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:7d0783ce22b3d7d369786d4b16067c79c033185b)
Merged-In: I1d07c433aca41ccfe2e710821cf930c413dc12d6
Change-Id: I1d07c433aca41ccfe2e710821cf930c413dc12d6
TestAarImportProducesJniPackages was attempting to assert that an
aar_import module always had a JniPackageProvider, but was instead
asserting that the return type was always a JniPackageInfo. Since
ModuleProvider returned the zero value of JniPackageInfo even when
there was no provider that was always true.
Fix aar_import to always set JniPackageProvider.
Test: TestAarImportProducesJniPackages
Change-Id: Idaf106e14373490d4eb807892e174aaaf094bbcf
art java_test modules need to specify compile_data, make it common
to all java modules.
Bug: 307824623
Test: m lint-check
Change-Id: I68640f14137f9cadaf0c454d3b5abc9e2d1d9b4b
It was fixed with aosp/2866315.
Bug: 307824623
Test: ./build/soong/tests/genrule_sandbox_test.py camera-its
Change-Id: Iaf3871682e99ceb7161c159acb757ce2949f5b3d
Some users want to repackage the results of an sdk module.
Genrules have 3 variants: linux, android, and common_os. The common_os
one produces a snapshot zip file that users want. In order to get
access to it, we need a genrule in the same variant, so create
an sdk_genrule for that.
The sdk_genrule shouldn't have linux/android variants either, because
those other variants would get errors when trying to depend on the
sdk modules because the snapshot zip doesn't exist in those other
variants. The code in arch.go needs to be tweaked to allow a common_os
variant without the other variants.
Bug: 315962165
Test: m dist out/dist/art_release.zip
Change-Id: Idc9b3cae7a525d71aed6bafa0f8724a89f75a94b
clang silently ignores such things rather than reporting them as errors.
With this change, verbose.log.gz says android10000 instead, as expected.
Bug: https://buganizer.corp.google.com/issues/315788463#comment24
Test: treehugger
Change-Id: I0d92b0747912f28065de0d2dc6b4d33d1c2c9857
The original `tradefed_binary_host` in Soong always used the host OS
architecture when writing the `arch` in `test-suite-info.properties`.
This change introduces the `Suite_arch` attribute in
`tradefed_binary_host`, allowing users to specify the architecture
for `test-suite-info.properties`.
Bug: 313535357
Test: 1. Add property of `suite_arch` in the Android.bp
2. m cts-tradefed
3. check `test-suite-info.properties` in cts-tradefed.jar
Change-Id: Ib95db4e0e8d238c9bb8a2a3fffea606fa6a764ce
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Use --revert-annotation instead of --hide-annotation
Use of `--hide-annotation android.annotation.FlaggedApi` was always an
intermediate solution until the required semantics for `@FlaggedApi`
was determined. The `--revert-annotation` option provides those
semantics. When the `@FlaggedApi` is applied to an existing API, e.g.
because it has moved from system to public, or because it has changed
in some way, e.g. modifiers, then the correct semantics for when that
API is not required is not to hide the API but to revert it to what it
was before the change necessitating the `@FlaggedApi` annotation was
made.
Bug: 314196587
Test: ./gradlew
Change-Id: Ic97f29dd2b9f598ba0851f5f622c2a2724f18037
