With this change, in a user build the dependency looks like:
package.apk -> progaurd.classes.dex -> ... -> proguard.classes.jar
While in an eng build:
package.apk -> noproguard.classes.dex -> ... -> noproguard.classes.jar
Because package.apk is product-specific and removed when switching between
user and eng builds, it can always be built with the correct and up-to-date .dex file.
Bug: 3022484
Change-Id: I3a732cb3e256f193088c294dc4a0573188283cb2
With this change, you can add your .rs files to LOCAL_SRC_FILES.
The .rs files will be compiled by slang and the output .java files
will be compiled into the jar, while the generated .bc files will
be put into the final apk as raw resources.
Change-Id: Icde3d6139951d6d039b4b37376e72e1fc5c8b0d4
JarJar, like DX, can't handle the local var corruption that Emma
performs. To fix this, I'm moving the JarJar step before the Emma
step.
Couple other minor changes:
* Improved the comment about emma hardcoding its output filename,
since this took me about an hour to track down.
* Changed one line from "Copying $<" to "Copying $@". It seems to be
the convention that such lines print the destination, not the
source, so I made it consistent.
Change-Id: I9f5c36b4f5af15daf15025b89860e942f15bb668
Merging from master because I'm bringing my maps API work into
gingerbread.
Fix and enable JarJar in Java builds.
java.mk contained a target to enable JarJar in Java builds, but it was
being bypassed. This change enabled JarJar as part of the build
process, and fixes a slight bug with the way it was set up.
Change-Id: I814e64eb30b41bf249a63d683c03040e2658fe0d
commit 7401608f3b9b52b3348e32ec9fefe7583d6c2fa4
Author: Guang Zhu <guangzhu@google.com>
Date: Fri Apr 23 11:54:37 2010 -0700
collect emm meta files for emma instrumented build
when doing 'make dist', with EMMA_INSTRUMENT on the coverage.em files
generated for each module will be collected into one emma_meta.zip file
Change-Id: I382c39a97005e6cae5c79ad7eaef1c8857f658af
commit 8376d70938f6507d54b66fe5832a637aa883974e
Author: Guang Zhu <guangzhu@google.com>
Date: Wed Mar 10 15:48:03 2010 -0800
enhancement for building app with emma code coverage
* global filter to avoid applying instrumentation on emma classes
* remove local variable information at dex step instead of compile time
Change-Id: If04c27bc717f34816077a98ead9ceb0dbcbb0d2f
Change-Id: I971bd0f291bede2568b21347247d37a7d035c661
java.mk contained a target to enable JarJar in Java builds, but it was
being bypassed. This change enabled JarJar as part of the build
process, and fixes a slight bug with the way it was set up.
Change-Id: If24113f399a168939a1a1d0738c5df57caf8d05f
Also extending the arbitrary limit on build argument sizes,
which I ran up against in building after this change.
Change-Id: Iba79a37b27e7d5efa2b02a99aa253a2eec7ede75
* global filter to avoid applying instrumentation on emma classes
* remove local variable information at dex step instead of compile time
Change-Id: If04c27bc717f34816077a98ead9ceb0dbcbb0d2f
The Dalvik core libraries team would like to start making warnings
errors in certain packages by definition LOCAL_JAVACFLAGS. This will
allow easier debuging of warnings in other packages by supplying
"-Xlint:..." options.
1. Dedup LOCAL_JAVA_LIBRARIES.
2. Even no resource or asset for a package, we still need to set
package_expected_intermediates_COMMON, which is anyway used by ProGuard.
Now, by default, instead of fully building everything,
we skip dexing the modules that aren't going to be included
in the current build.
This will slow down some of the incremental builds (like tests),
but it improves the regular eng build from 27.5 minutes on my
Mac Pro to 25 minutes. That's not as much of an improvement
as I had hoped for, but it's still better.
There is also a change in here that puts the java-source-list
file which is used to get around limited command line lengths
in the proper directory. Before this change, it was an
accident that the directory for that file existed!
Original change by joeo@abreu on 2009/04/06 19:54:13.
Implement SDK add-ons in the build system.
- Add an option to use the standard javadoc doclet instead
of droiddoc, since droiddocs non-sdk templates aren't
ready for prime time.
- Add the notion of a stubs for a library. It's only
implemented for java libraries, but when we do native
libraries in the NDK or sdk-addons, it will work there too.
Original author: joeo
Merged from: //branches/cupcake/...
Automated import of CL 145618
