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
Bug: 36902714
Test: m -j ANDROID_COMPILE_WITH_JACK=false
Change-Id: I291510b56162f0d35553e3c7ccd59b1382224d62
(cherry picked from commit 96476c1d50)
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
Bug: 36902714
Change-Id: I6730e2d3ec38004874265b2a690442dec57b33f4
(cherry picked from commit 941b682099)
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
Bug: 36902714
Test: m -j ANDROID_COMPILE_WITH_JACK=false java
Change-Id: 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
(cherry picked from commit 0e53734035)
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
(cherry picked from commit fc8ead6609)
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
Emma is unable to process framework.jar, and making framework
classes.jar depend on the emma output causes builds to fail when
emma is enabled. Make classes.jar depend on the jarjar output
instead, bypassing emma for now.
Test: m -j EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true check-public-api
Change-Id: I861282292816e29ca27b67a3eef978d951c1a4dc
This enables support for lambdas by passing class files through the
desugar tool.
Test: m -j checkbuild tests cts
Change-Id: I14ec152355243fd67fe2f107ccbe67a1b4e7e262
This reverts commit a341bf0f86.
Breaks grok builds that replace javac with another tool:
reading standard input: bufio.Scanner: token too long
Change-Id: I825587c465b05c1fbddb7794dc1c84f5f2c883d1
This is a partial revert of commits:
858657366f Remove support of disabling Jack.
3ae7861252 Remove javac support in host dex rules.
22313f2b2a Remove rules for building dex with dx
Test: builds
Change-Id: Ie12d743cbe978bdeb030910848b67f5945a4fec8
Just move the proto and renderscript sources into their own directories
-- the entire directory is wiped if the file list changes since the
command line will change. So we can just enable/disable pulling sources
from those directories based on whether there were files in the list or
not.
Bug: 30947985
Test: m -j java
Test: Remove a proto file from a java lib, ensure the generated source
is not included.
Change-Id: If7529979de6fa62a651933a3a974f47b033851d6
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
Changed to LOCAL_JACK_PLUGIN.
(cherry picked from commit 17924b136cb5bfc60d138e8c7e5c18a90b5965c3)
Test: Manually tested by some manual activations of the coverage plugin.
Change-Id: I1be4aaa502103fc308d35a5672dc4fe5900c4ebe
And ensure compatibility with coverage plugin.
(cherry picked from commit 862bb84d37e3e6ca61080de58f206e512e09d4e0)
Bug: 28876950
Test: Manually tested by some manual activations of the coverage plugin.
Change-Id: I804558a501825357bf0812de626d2957eedbdc13
This is needed in order to be able to run error prone (which is
a plugin replacement for javac) on a subset of the java code.
Bug: 31507496
Test: Build javac-check-core-tests and check the resulting JAR
Change-Id: I5a556920572fcdad7b39d67e3f00fe0e0f1f8f46
Colin Cross