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
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
This relands Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c with a fix
to include additional manifests from dependencies in the final
manifest merger.
Test: app_test.go
Test: TestManifestMerger
Change-Id: Ied0a6cfee2f18e87188db145b9411d4a903ab6c9
Add a test for the manifest merger command line that would have prevented
b/291252863.
Bug: 291252863
Test: TestManifestMerger
Change-Id: I8c025efe7ccb06ad97b405e2927a4df07f9d3f27
* changes:
Add a Make variable to determine ART boot image jars for testing.
Add a Make variable that overrides configured jar locations.
Refactor dexpreopt for boot jars to make it flexible to config changes.
We had hardcoded logic to override "framework-minus-apex", but we need
to override more jars, so this CL adds a general solution for this.
Bug: 290583827
Test: m nothing
Change-Id: I211ebda7aa2803886ab6e6d081d26327665e49a6
In the past, dexpreopt for boot jars was very inflexible, and it was
incredibly hard to make a change that is as simple as adding a jar to a
boot image. Boot image generation was handled by
"platform_bootclasspath" and "bootclasspath_fragment" separately. This
caused not only code duplication but also the inflexiblity as such a
design did not fit today's use cases, where a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. The design casued a huge
maintenance burden as any change to the boot image cost multi-week
efforts.
In recent years, efforts have been made to improve this a bit by a bit.
This change is another step towards making dexpreopt reasonable.
After this change, all boot images are generated by "dex_bootjars",
which is in build/soong and is therefore available on both the full
source tree and the thin manifest (master-art). The change decouples
profile generation/extraction from boot image generation. Profiles for
mainline modules are still handled by "bootclasspath_fragment"
because they need to be packed into APEXes when building mainline
modules and extracted from APEXes whem building the system image from
prebuilt modules. Boot images are not handled by
"bootclasspath_fragment" anymore.
Bug: 290583827
Test: m (all existing tests are still passing)
Test: Manually checked that the boot images are exactly the same as
before.
Change-Id: Ib5a5f401bee334ffcab5c26618e0c8888b84575a
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
metalava no longer prints an ASCII banner, and has removed its
--no-banner argument. Update all call sites accordingly.
Test: presubmit
Bug: 286023667
Change-Id: I61cf5f1125dfbd93496e6a59eb1ea62886b32046
* changes:
Change the profile path on host.
Extract duplicate code to common helper functions.
Fix dumpOatRules.
Remove Modules() from BootclasspathFragmentApexContentInfo.
Fix some tests for dexpreopt and remove unnecessary tests.
This is to decouple profile generation from image configs. A boot image
profile is either for a mainline module or for the platform, which is
orthogonal to boot images.
Bug: 290583827
Test: m nothing
Change-Id: I0918f2fa945a2af1839f1a08ecede331c64d0317
Also, fall back to using a default name for the dexpreopt directory if
we are not building for Android.
Bug: 290583827
Test: m nothing
Change-Id: I3fc6ff9142a2dcdf995796f75891b242fe2848d0
Instead of rolling assets and manifests up through each static lib,
provide them as a DepSet. This will help with the next patch, which
needs to pass all the transitive manifests and R.txt files together.
Test: app_test.go
Change-Id: Id8b3aa2bed3771e82ab6bde192c9b43baa38b54c
This method generates a build rule that runs oatdump for debugging
purposes.
- Pass "--runtime-arg -Xgc:CMC" to oatdump if UFFD GC is enabled.
- Build the phony name from the image name to avoid conflicts when using
this method for multiple boot images.
Bug: 290583827
Test: m dump-oat-boot
Change-Id: I7adc97cb85b571486b78f173fb80ff7da2c4bfe4
The Modules() method was for the ART boot image in the ART APEX. It's no
longer needed because we don't install the ART boot image in the ART
APEX anymore.
Bug: 290583827
Test: m nothing
Change-Id: I674a5fa1ed18908413a64129df5947c7d26e638e
This CL is to prepare for the changes in http://r.android.com/2652081.
See the description of that CL for the reasons.
Some tests were set up in a fragile way and were easy to be broken when
the implementation changes. This CL is a pure test change that fixes
them.
This CL also removes TestNoUpdatableJarsInBootImage. That test checks
what should go to the ART boot image and what should go to the
platform one, which does not apply today because boot images are not
associated with mainline modules anymore: a boot image may take jars
from multiple mainline modules and the platform, and a mainline module
can contribute to multiple boot images. In practice, we have ART jars in
the platform boot image, and we are going to add core-icu4j and
consrypt to the ART boot image, which is now for testing only.
Bug: 290583827
Test: m nothing
Change-Id: I22c45cbf6f853b030b68edb51197854e9c53a02e
android_app_import and android_test_import modules with processed: true
and skip_preprocessed_apk_checks are used directly from the source tree.
If the source file name doesn t match the module name and the file is
used as test data it can result in the wrong filename being used. Copy
the source file to an output file with the correct name first.
Bug: 290376750
Test: m CtsAppSecurityHostTestCases
Change-Id: I4a6dd1c5e48db7085ea41035def31f0844948a46
Add a test for the aapt2 resource processing code that will be affected
by the resource processor feature in a subsequent CL.
Test: TestAndroidResourceProcessor
Change-Id: I39712853f7bbfb7963f1b71e234d039d5ccaae53
Currently, stub java files are extracted from srcjar file provided from
dep_api_srcs in java_api_library module generated in java_sdk_library
per api scope. However, compiling the java files may lead to difference
in the content of the generated class files even if the stub java files
are equivalent, as javac may arbitrarily add overridden methods. Thus,
create a stub jar file instead of creating a stub srcjar file and
compiling it, in order to guarantee stub jar files content equivalence
and thus enable hiddenapi during from-text stub build.
Note that this change does not fully resolve differences between the
full api surface csv and the per sdk_library csv. Instead, it removes
the difference caused by methods arbitrarily added by javac.
This change also renames dep_api_srcs to full_api_surface_stubs to be
more intuitive.
Test: rebase on top of aosp/2617274 and `m --build-from-text-stub`
Bug: 275570206
Change-Id: I22b6d56624633681f5c3b000370b5782655c7b8d
Starting from aosp/2594905, dexpreopt depends on
`$PRODUCT_OUT/product_packages.txt`. When PRODUCT_PACKAGES changes,
dexpreopt has to rerun for all apps. This is not ideal.
After this change, dexpreopt uses a per-app product_packages.txt that is
filtered by the app's dependencies, and it uses `rsync --checksum` to
prevent the file's mtime from being changed if the contents don't change.
This avoids unnecessary dexpreopt reruns.
Bug: 288218403
Test: m
Test: Change PRODUCT_PACKAGES and see no dexpreopt reruns.
Change-Id: I5788a9ee987dfd0abfd7d91cbcef748452290004
This provides significant size savings over the default compatibility
mode, roughly ~20MB in aggregate for a recent Pixel build. Targets can opt out using `proguard_compatibility = true`.
Future work will enable for all targets, not just apps, but this
incremental change yields the most benefit.
Bug: 215530220
Test: m + presubmit
Change-Id: I52a9b27ebe71835849e200e23ae2a250eaf1bbe1
The conversion of FirstUniqueStrings to be implemented on top of the
generic firstUnique accidentally used a different threshold to switch
from the list implementation to the map implementation. Modify the
threshold of firstUnique to match the old value from FirstUniqueStrings
now that it doesn't have the reflection overhead. While we're at it,
also make firstUnique make a copy of the list, and make FirstUniqueStrings
a pure wrapper around firstUnique.
Test: BenchmarkFirstUniqueStrings
Change-Id: Icc2febea663142c508ff2e4be65a8a68121631d5
Use Go's generics for DepSets so they don't require a type-specific
wrapper and reflection.
Test: depsets_test.go
Change-Id: I22ba0b7d680d37d2cd05230b0f560d166c4dd20b
Metalava no longer looks for common typos. It relies on the code
analyzers that run on Gerrit to detect them.
Bug: 288072162
Test: m checkapi
Change-Id: I08eca8008af39ebe69442db419ebd3d3378aa0de
The resourceshrinker command prints an info log for successful runs,
which we don't really need to surface in build output. Suppress stdout
for such invocations; errors will surface through stderr.
Bug: 202959019
Test: m + compare log output
Change-Id: I08ed465bb7e3a0fa8d5e967d858f6739b5ef7fad
