The LOCAL_JAR_PROCESSOR rule should depend on the path to the
processor jar and not the module name.
Test: m -j && m -j
Change-Id: I5ebd4cd3ad4429918edfd0a8cb5cb9a4e7e86ca7
We're removing LocalVariableType / LocalVariableType in order to
save space. Enabling stripping reduces AOSP image size save
by ~12MB.
Bug: 38224820
Test: CtsLibcoreTestCases
Change-Id: I3168d73ec6825aa5879db7e1135d7ed61d488d72
Replace java -> $(JAVA), etc. to prepare for moving java binaries
out of the path and using full paths to them.
Test: builds
Bug: 62956999
Change-Id: I5dfcd0d4e855ecde69cd127169e9545e59723d12
Fixes build breakage caused by having duplicate versions of
a class in the application and in the API. This workaround will
be removed once junit classes have been removed from the API.
Bug: 30188076
Test: make Browser2 ANDROID_FORCE_JACK_ENABLED=disabled
Change-Id: I9a9031d3ef6d82f35413b229d588a605f9ed39dc
Allow using a host java library as an intermediate processor step
after javac but before desugar, proguard, or dx.
Test: manual
Change-Id: I7fb843e10d96c0167f6e4371582fabcc1454521f
Previous change that moved com.android.internal.util.Predicate
to the legacy-android-test JAR caused a proguard build breakage
due to duplicate classes in the application and library. This
fixes it in the same way as previous issues with junit and
android.test classes were resolved by excluding those classes
from the application JAR.
Bug: 30188076
Test: make checkbuild and make -j ANDROID_FORCE_JACK_ENABLED=disabled checkbuild
Change-Id: Ica0089607187f970251ddba339a1f71d4cad80cc
Building all java to dex is very slow. Make javac checkbuilds act
like jack checkbuilds and only build to class files for unused
modules, and add a java-dex target that can be used to build
everything to dex.
Test: m -j checkbuild
Change-Id: Idcf9c9e0223b9dd88aaa53beb0cb50a230034b0f
Allow working around Jack bugs by using javac to compile *.java
to class files, and then pass through Jack for desugaring,
proguarding, and dexing.
Also make ANDROID_COMPILE_WITH_JACK=false override LOCAL_JACK_ENABLED.
Bug: 37483961
Test: m -j checkbuild
Test: Add LOCAL_JACK_ENABLED := javac_frontend to a target
Change-Id: I2189055aac9deccc36b8eab8e949796dddadf7a1
Add soong_javac_wrapper to all javac commands. soong_javac_wrapper
colorizes javac output, and hides noisy messages.
Previously attempted in I7e8fcd2e4e1ed3ff530a8ccfe931ceb7e411e0ad
and I449a61ed2c95b3e1afd51a31a11baab15d97e2f2.
Test: m -j ANDROID_COMPILE_WITH_JACK=false
Change-Id: I9d7a20d766fadab323a4cf95e5734741b3f578bb
The codebase is growing more uses of annotation processors,
through a mixture of LOCAL_ADDITIONAL_DEPENDENCIES and
LOCAL_JACK_FLAGS. Add LOCAL_ANNOTATION_PROCESSORS and handle
the rest in the build system.
For now we also need LOCAL_ANNOTATION_PROCESSOR_CLASSES to
work around bad behavior in grok (b/25860419).
Test: m -j java
Change-Id: I465b021e65d25ed3ea517333a82ec4ebd63fc038
(cherry picked from commit cde14987ba)
The codebase is growing more uses of annotation processors,
through a mixture of LOCAL_ADDITIONAL_DEPENDENCIES and
LOCAL_JACK_FLAGS. Add LOCAL_ANNOTATION_PROCESSORS and handle
the rest in the build system.
For now we also need LOCAL_ANNOTATION_PROCESSOR_CLASSES to
work around bad behavior in grok (b/25860419).
Test: m -j java
Change-Id: I465b021e65d25ed3ea517333a82ec4ebd63fc038
This will allow individual modules to enable error prone checks
as needed so that the change to treat an error prone check as a
compiler error can be done atomically with the changes to fix
the issues that check reveals.
Tested with the following steps, cleaning up the targets in
between to ensure that it was rebuilt everytime.
Set LOCAL_ERROR_PRONE_FLAGS := -Xep:ClassCanBeStatic:WARN
compiler error in junit-params-test target. Built
javac-check-junit-params-test with RUN_ERROR_PRONE=true to make
sure that compilation failed.
Built the javac-check-junit-params-test without RUN_ERROR_PRONE
set to make sure that the flag is not included unless explicitly
requested.
Built the junit-params-test as normal to make sure it still
worked properly.
Bug: 31507496
Test: See above
Change-Id: I88b5800dacd0e30dd9dcfa5f42e89d1428957365
Merged-In: I88b5800dacd0e30dd9dcfa5f42e89d1428957365
(cherry picked from commit 3ca9298d99)
I6730e2d3ec38004874265b2a690442dec57b33f4 introduced duplicate rules
to build classes.jar for static java library prebuilts, and left rules
to copy $(built_dex_intermediates) to $(built_dex) for modules that
don't build dex files.
Move prebuilts LOCAL_BUILT_MODULE back to javalib.jar to match
non-prebuilt modules, and remove the manual building of javalib.jar.
Add a check around $(built_dex_intermediates) for static java libraries.
Bug: 36901093
Test: m -j ANDROID_COMPILE_WITH_JACK=false
Change-Id: I291510b56162f0d35553e3c7ccd59b1382224d62
Jack can silently handle using a java library as a static java
library by merging in the java library dex file. This causes
problems when switching to javac, because dex doesn't support
dex merging with multidex enabled?
Make the output files consistent between java libraries and static
java libraries. Java libraries will now produce:
classes-pre-proguard.jar: the classes before proguard processing
classes.jar: the final jar file containing classes before dexing
javalib.jar: a jar containing classes.dex
Static java libraries will eventually only produce
classes-pre-proguard.jar and classes.jar. All inter-library
linking is done with classes.jar, so a java library can be
used as a static java library.
There are too many dependencies outside the build system that
expect javalib.jar to exist for static and host java libraries,
so for now continue to build a javalib.jar that is a copy of
classes.jar.
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Test: m -j java
Bug: 36901093
Change-Id: I6730e2d3ec38004874265b2a690442dec57b33f4
Downstream users of a library always link against javalib.jar, which
is either the dex jar for java libraries or a copy of
proguard.classes.jar for static java libraries. In preparation for
making java libraries a superset of static java libraries, make
classes.jar always be the final class-containing jar for use
downstream, and always create a classes-pre-proguard.jar for
users that need a jar without shrinking or obfuscation.
Also rename the intermediates to be consitent: classes-<tool>.jar
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Change-Id: I3df8b9a4edcd5db996f1fedc54c8a782d4f36a92
Merged-In: I3df8b9a4edcd5db996f1fedc54c8a782d4f36a92
(cherry picked from commit 6fabefa88e)
Don't copy jar files for disabled stages. Instead, set the name of
the output to the name of the input so the next stage will directly
pick up the output of the previous stage.
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Change-Id: Ib7268cbff7ea7ff2ad2caf994aa145e1b7a12b83
This reverts commit 440079b84b.
Adding the pipe interferes with error codes, which results
in an empty classes-full-debug.jar output file being left
after the failure. The next build sees the output file with
an up-to-date timestamp and doesn't rerun the failing rule.
Bug: 36666657
Change-Id: I6658edb766d8ba3120f88e3d8d6eda6ea6c691da
Modules compiled with javac 1.7 may have LOCAL_STATIC_JAVA_LIBRARIES
pointing to jars that contain code compiled with javac 1.8, and may
need desugaring.
Test: m -j ANDROID_COMPILE_WITH_JACK=false checkbuild
Change-Id: I470fc0a2fba51179a3ef95986cb3030194cd8f1c
Static java libraires are designed to be included in another
java library. If desugar runs on the static java library,
the resulting jar will contain the desugared lambda classes.
When the static jar is included into another java library
and desugar runs again, it desugars the static java library
classes again, producing the same desugared lambda classes
and colliding in the final jar.
Test: m -j ANDROID_COMPILE_WITH_JACK=false
Change-Id: I0508b2cc9c56dbbd4ac0aba44fb99ea2a27715e0
The new javac/desugar/proguard/dx based toolchain can fail if
there are duplicate classes in the -injars and -libraryjars
passed to proguard. That causes problems for b/30188076 which
is attempting to remove various junit and android.test classes
from the API because it requires the changes to add those
classes statically to applications are submitted simultaneously
with the change to remove the classes from the API which is not
feasible.
This change simply causes Proguard to ignore the classes from
the application JAR so it will always use them from the library.
That allows the changes to be done separately and only requires
that this change is reverted simultaneously with the change to
update the API.
Bug: 30188076
Test: make checkbuild and make -j ANDROID_FORCE_JACK_ENABLED=disabled checkbuild
Change-Id: I6ed6c45a159d6261d90245551aa2913cc82d2e8b
