This makes it possible for Android.bp files to depends on the srcjar.
Bug: 151360309
Test: m platform-bootclasspath.srcjar
Change-Id: Id42cc3cff89c084b55c7fb0726ad84ecd4f50f58
This output contains all the transitive sources that are contained in
the bootclasspath.
It's currently limited to source-built bootclasspath components. Future
work will make this deal with sdk_library prebuilts.
Bug: 151360309
Test: unit test, as well as manual inspection of platform-bootclasspath
Change-Id: Ie05d8125e19736d8b4b9ebafb70b88a0a40069d5
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
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
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 should be no-op, as the underlying mutator has not changed yet.
Some other refactoring is required and done in this CL:
- Delete some old, dead ApiBp2build code
- Fix casting to TopDownMutator when it's not necessary
This change is required to prepare for allowlist v2 work, as only
BottomUp mutators can AddDependency.
Bug: 285631638
Test: m nothing
Test: presubmits
Change-Id: I5212a5f5634cc13056195783e6df37ff8eb000da
If a java_library module has proto srcs, a java_*_proto_library target
will be created for it. Proto sources are generated and then compiled
by a java_library target. We need to pass the libs and static_libs of
the java_library module to this java_library target so that
the compile-time classpath is correct.
Test: updated unit tests and CI
Bug: 301469542
Change-Id: I05b2efce6fda2223e85728b3c4c7b1815d04c3dd
With api_files property being removed from java_api_library, all api
files are passed to java_api_library via java_api_contribution, which
provide api_surface information. Instead of relying on the naming
convention of the api files, java_api_library can utilize this
information to sort the api files from narrower api scope to the wider
api scope.
Test: m --build-from-text-stub
Bug: 295429988
Change-Id: Idd832778833c072c6b7e9d1f775533e5f4e2af00
java_api_contribution provides api_surface information, but files
directly passed to java_api_library do not possess such information.
Currently, the api surface is assumed via naming convention for api
files passed via api_files property, but this is fragile.
This change removes the api_files property from java_api_library and
enforce all api files to be passed via java_api_contribution
Test: m nothing --build-from-text-stub
Bug: 300964421
Change-Id: If01d9ed978fe469d4ee0d685582a51629ebecc56
