This new entry in the JavaInfoProvider lists all the transitive source
files contained within the library. That is, the source files of the
module and all its static dependencies.
Bug: 151360309
Test: unit test in java_go + some manual testing
Change-Id: I7fe3035b9e46774095c0e9196cd77fa1027adf6d
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
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
When targetSdk is >= 30, the system verifies that you use a valid
signature V2+ certificate. Uncompressing ndk/dex files or aligning
the zip file will break a signature V2, so these apks should really
just set preprocessed: true.
Fixes: 185811447
Test: Presubmits
Change-Id: Id89c42bcd5b5daa6eda1716bff4023423298036b
Flag for java_library modules to build just the Turbine headers and
skip building an impl jar.
Test: go test java
Bug: 289776578
Change-Id: Iad0babf951710476bc32df93c25d17065a14ab84
Add a property to export proguard flags files for libs dependencies.
Currently only proguard flags files from static deps are propagated up
to reverse dependencies, but it is necessary sometimes to have flags
from libs dependencies also be propagated.
Bug: 289087274
Test: go test ./java
Change-Id: Ic0aa22b086792bf322041aa5780db6c4f4eb2770
The R.Java files generated by aapt2 link --no-static-lib-packages
cause scaling problems by combining all resources into every package
listed in a dependencies' AndroidManifest.xml file. For SystemUI-core
this results in 74 R.java files, each with 76k lines, and takes 20
seconds to compile in javac.
Both AGP and Bazel have workarounds for this that avoid using the
R.java files generated by aapt2, instead generating more efficient
R.class files directly based on the R.txt file.
Bazel uses the ResourceProcessorBusyBox tool that is already present
in our tree to process the resources. Reuse the same tool in Soong
to create the R.jar.
The more efficient R.class files require modifiying source files
that use incorrect packages to refer to resources.
Bug: 284023594
Test: TestAndroidResourceProcessor
Change-Id: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
Merged-In: I026073b40dabcfdb10e5d7a52e9348205b0e9a66
If a header jar couldn't be built (for example when an API generating
annoation processor is in use) the implementation jar is reused as the
header jar. If the implementation jar contains an annotation processor
listed in META-INF/services/javax.annotation.processing.Processor then
later javac executions with the implementation jar in the classpath
could attempt to run the annotation processors unexpectedly. Remove
the META-INF/services directory when using an implementation jar as
a header jar.
Bug: 290933559
Test: builds
Change-Id: I40d48644bc5a09a9564dc2c4b38f627edd00fcf8
Currently, java_library.stem property is not correctly reflected in the
output jar name in java_library when the module specifies
java_resource_dirs property. This change fixes the unexpected behavior
so that setting the stem property behaves as expected.
Test: go test ./java && m
Bug: 285843207
Change-Id: I0941fcea83c92f4c42ae415aa6ad9125da5cf57b
The Java compiler may generate sources when processing annotations.
These sources are currently not included in the IDE project model, which
results in unresolved symbols when using Hilt and other annotation
processors. These sources are not passed to the Java compiler for
compilation, so they cannot be handled like other Java module sources.
This change archives the generated sources and appends them to the
existing srcjar list in module_bp_java_deps.json.
Test: go test .
Test: Verified that module_bp_java_deps.json contained srcjar entry
Test: with path/to/android_common/javac/anno.srcjar.
Test: Verified that IntelliJ can resolve generated symbols after
Test: invoking aidegen.
Change-Id: I6a3011f9140fd25f785178baee0cd6074ad94600
Use Go's generics for DepSets so they don't require a type-specific
wrapper and reflection.
Test: depsets_test.go
Change-Id: I22ba0b7d680d37d2cd05230b0f560d166c4dd20b
This also changes the expectation of ConvertWithBp2build. Each
implementation must either create one or more Bazel target modules, or
mark the module as unconvertible (with a specific reason).
Manually verified no runtime hit in AOSP
In AOSP, the metrics file size increases from 252K to 1.6M
This changes some effective module counts in bp2build metrics:
- Removes "package" modules from the module count list in
metrics, as these will not be converted like regular modules.
- Counts Handcrafted modules as being "unconverted", as bp2build is not
responsible for them.
Bug: 285631638
Test: Verified generated BUILD.bazel files are bit-for-bit identical
with this change
Test: Manually verified one case of each implemented reasonType
Change-Id: I308dd451d8f28379b15671dae9f931bd0446f5c1
Rename java_library created inside sdk_library with the ".from-source"
suffix, and set it as static lib of the top level java_library, which
gets java_api_library instead as static lib during from-text stub build.
Test: m nothing && m nothing --build-from-text-stub
Bug: 286446015
Change-Id: I32e8ea264987e9f9df05e462292bd54e45074912
I suspect this was accidentally committed. We shouldn't just printf such
a statement every build analysis.
Test: Presubmits
Change-Id: If5ee66ce1b366f28254cd1bfdcaed9e085a60094
Also add unit tests for the rest of device_config
Bug: 283475679
Test: m nothing (soong unit tests)
Change-Id: Iee18a1f2f2cbb23e8c8d84c54e903b32be29a693
This change cleans up references to android.JavaApiLibraryName() so that
rdeps link against "android_*_stubs_current" instead of
"android_*_stubs_current.from-text".
Bug: 284995489
Test: m
Change-Id: Ibdf33b15981317c43e468dbc1657229d54bbd226
Exclude_static_libs property can be used to specify static libs that
should not be used to build the module. The list acts as filter for
static_libs.
Bug: 285410821
Test: go test ./java
Change-Id: Iee7f160ba88b5f64bdd265c30d47c9f51feb0f5e
Use JavaApiLibraryName function to redirect the usage
of core platform api stubs from .txt files based on config.
Test: m --build-from-text-stub
Change-Id: I926a0a455fed301ba4ff9dfa509d4dbbbd076029
In scope:
- core.current.stubs
- system modules generated for core's public stubs
- system modules generated for core's module_lib stubs
The system modules generated for core_platform api surface will be
handled in aosp/2514755
Test: go build ./java
Change-Id: I34134f79c8ae6e5b218d0b85553de5a748a8cc3f
max_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid max_sdk_version in bp
files
Bug: 208456999
Test: no change in ninja file (this should be a no-op)
Test: TH
Change-Id: I304b5ad802bde200137d8e225182828dfd6f7227
target_sdk_version signifies device version and does not need an sdkKind to
describe it fully. Update the type and cleanup existing usages. As a
side benefit, we also get better error handling since users can no
longer enter something like `public_30` as a valid target_sdk_version in bp
files
Test: m nothing
Test: no change in ninja files (this should be a no-op)
Bug: 208456999
Change-Id: I3c19245e29184bd9e5660ad8981966f64dfa9424
This relands aosp/2457063. The original change broke T and U since those
branches still contain soong modules of type (kind+level). Those soong
modules have been cleaned up now
Test: Used go/abtd to test T and U branches with this change
Bug: 208456999
Change-Id: I0ef7933c055f88cb512a02108f1173e51156ef1c
These hardcoded refs will need to be updated when we start using .txt
stub equivalent (single-tree/multi-tree). Instead of strewing this logic
all over the codebase, create a helper function that contains the
replacement logic. All other places should call this helper function
instead of calculating the name of .txt equivalent soong module by
itself.
(Will do a similar cleanup in build/make)
Test: no change in ninja file
Change-Id: I6bf999eb4aeaba6ac2a44b9016bae4ec8c79ce19
The type of min_sdk_version is being migrated from
android.SdkSpec(kind+level) to android.ApiLevel(level). This affects
`ShouldSupportSdkVersion` for java modules. This function skips the
check for modules compiling against `core`, and that requires access to
SdkVersion and not MinSdkVersion after the migration.
Skip the check explicitly using SdkVersion.
Test: go test ./java
Test: No change in ninja file
Bug: 208456999
Change-Id: I14eca4f8e8c5d7477ded00c4fe54097323fab4a2
This reverts commit 7eb9243fa7.
Reason for revert: The original change was reverted since it was suspected to cause missing libc++.so errors. It was a red herring, and the root cause has been fixed now b/264588525
Change-Id: Ib9110c41bacf220b91f24de11589f63235895e56
The -libraryjars argument to r8 was missing transitive dependencies, and
so complained when there were classes used in the program JAR which were
not provided via libraries. This CL propagates transitive dependencies
to the r8 command to reduce the warnings that are generated for missing classes.
Bug: 242088131
Change-Id: Ifad7bc7c5d406e3de8d98ea963c97e88c84b45a1
This reverts commit daa220ae8c.
Reason for revert: Suspected to be a cause for build failure (b/264446640). Will use go/abtd to verify
Change-Id: Ibfdf893f2426b1119923467027e0acedd08808c1
`min_sdk_version` is used to represent the api_level of the device and
its type will eventually become android.ApiLevel. OTOH,
`sdk_version` property represents the API surface a module builds against
_and_ the version of that API surface. For
R8/D8, the additional `--android-platform-build` should be determined
using the sdk_version of the soong module and not min_sdk_version, since
min_sdk_version will not contain information about the api surface used
for compilation.
The unit test for `core_platform_app` in TestR8 were passing since
min_sdk_version was not set, and therefore it implicitly defaulted to
sdk_version.
Also created a custom struct to propagate params to the helper dex
functions
Test: In build/soong, go test ./java
Test: TH
Bug: 208456999
Change-Id: I08ac6f496444d603557e498c8a1794af665abc7a
Allow genrules to access the turbine header jar outputs
from java_library modules using the .hjar output file
tag.
Bug: 251871740
Test: m checkbuild
Change-Id: Ib1ec9734323a51583057fb458f791e1e0bd0d767
