Sort the list of input java files for the aidl build step so that
the contents of generated makefiles in WebView have a stable ordering.
BUG=
Review URL: https://codereview.chromium.org/323803003
Cr-Original-Commit-Position: refs/heads/master@{#292686}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8eff03f99038a90198095d0bab3363a249357cb5
At runtime, the classloader will look for classes in both apk's dex
files. In the standard Android build system, an instrumentation test
apk's dex file does not include the classes included in the tested apk's
dex file.
To do this, when doing obfuscation for an apk, write the list of
libraries included in the obfuscated jar and the list of proguard config
files. Then, when proguarding the test apk's code, exclude those
libraries included in the tested apk, use the configs from the tested
apk, and apply the proguard mapping (the renames from obfuscation). Also
add some extra test-specific proguard options.
Now that the test apk does not bundle its own copy of all the tested
apk's classes, some things may need to be kept in the main apk just for
tests. However, we already keep everything in org.chromium.** and
com.google.android.apps.** because of the fact that the test apk was
using its own copy of all the classes and so we couldn't depend on the
tests to actually catch us from over-optimizing with proguard.
BUG=272790
Review URL: https://codereview.chromium.org/321883002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@277257 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
We were using package_name as a unique name for naming output files and
directories. package_name was typically the same as _target_name or a
variation of it (like dropping _apk). Using _target_name instead means
we need to specify one less thing and it is (maybe?) guaranteed to be
unique.
TBR=brettw,joi,jar,fischman,zea,sky
BUG=
Review URL: https://chromiumcodereview.appspot.com/11308030
git-svn-id: http://src.chromium.org/svn/trunk/src/build@183639 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently chromium_testshell_test_apk and content_shell_test_apk compile
and package java files from two different directories. Supporting this
in a good way is a requirement for using a single ant template for all
apks.
Introduce a new gyp variable for apk/jar targets, generated_src_dirs.
Now, generated_src_dirs is for directories that contain .java files that
are generated at build time and additional_src_dirs is for extra normal
directories to include in the jar/apk.
Change content_shell_test_apk and chromium_testshell_test_apk to use
additional_src_dirs for their extra dirs.
Add documentation for the gyp variables for jar/apk targets.
Reorder the ant defines in the java.gypi and java_apk.gypi.
BUG=136756,146056
Review URL: https://chromiumcodereview.appspot.com/10987083
git-svn-id: http://src.chromium.org/svn/trunk/src/build@159299 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Native code generation rules typically add their output directory to
their dependent's 'include_dirs'. This change makes targets that include
java_aidl.gypi do a similar thing for other java*.gypi targets.
Make java.gypi pass this variable to ant and content.xml use the
variable rather than hardcoding the directory.
Also, move the aidl output folder into <(SHARED_INTERMEDIATE_DIR) as it
should be.
BUG=
Review URL: https://chromiumcodereview.appspot.com/10855060
git-svn-id: http://src.chromium.org/svn/trunk/src/build@151315 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The Java file generation rule in java_aidl.gypi assumes the wrong output path
for the generated file. This leads to spurious rebuilds.
The problem is that by default, the aidl tool outputs the Java file to
<output-path>/<package-path>/<input-file-root>.java, not to
<output-path>/<input-file-root>.java as assumed by the rule. This change fixes
the problem by explicitly specifying the output path to aidl.
Also remove superfluous path components on input files.
Review URL: https://chromiumcodereview.appspot.com/10690092
git-svn-id: http://src.chromium.org/svn/trunk/src/build@145982 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
torne
cjhopman@chromium.org
dtrainor@chromium.org
steveblock@chromium.org
michaelbai@chromium.org