The hash is calculated for the list of the resource files to determine if the
files were changed (added, removed, renamed, etc). The current way of doing it
may explode the command line length over the system limit. To avoid it, the list
of the input files is written to a temporary file on disk and the file is used
to calculate the checksum.
BUG=177552
R=cjhopman@chromium.org, newt@chromium.org
Review URL: https://codereview.chromium.org/20313002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@213849 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently, we are generating v14 layout and style resources from v17
resources by replacing Start and End attributes to Left and Right
attributes. However, it is not necessary for all cases, so make an
option to disable generate_v14_compatible_resources.py script and
only verify that there is no RTL attributes in the pre-v17 resources.
BUG=247049
Review URL: https://chromiumcodereview.appspot.com/18653002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@210555 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Gyp supports only very limited ways of changing behavior based upon
CONFIGURATION_NAME. Particularly, it does not support the way that was
supposed to enable/disable use of proguard.
Instead of trying to switch behavior in gyp, instead pass
CONFIGURATION_NAME, proguard_enabled, and
proguard_enabled_dex_input_path to dex.py and switch the behavior
there.
This also extracts the dex actions into build/android/dex_action.gypi
and uses that for the actions in both build/java.gypi and
build/java_apk.gypi.
BUG=240837
Review URL: https://chromiumcodereview.appspot.com/15231006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200958 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
There are several attributes introduced in API 17, mostly for BiDi(RTL) support, e.g., paddingStart.
This build script will generate another set of resource that is API 14 compatible by
converting those API 17 attributes to API 14 attributes, e.g., paddingStart -> paddingLeft.
The goal of this script is for programmers to use those attributes without worrying
about backward-compatibility care and related bugs. About the bugs, please refer to crbug.com/235118 .
BUG=235118
Review URL: https://chromiumcodereview.appspot.com/14476011
git-svn-id: http://src.chromium.org/svn/trunk/src/build@198325 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The native component build creates .TOC files for each of the native
libraries. These files contain the compile-time visible API of the
corresponding library. That is, if something changes in the native
library that could have an effect on linking of dependent libraries,
then that change will be reflected in the .TOC file. Then, these .TOC
files can be used to determine if linking of dependents is required.
This change brings that same magic to Java.
When building a .jar, we also create a .jar.TOC that includes the
signatures for public/protected classes/functions/variables (including
the values for constants since they can be inlined dependents).
When compiling a Java library, use an Md5Checker over the .java files
and the classpaths .jar.TOC (using the .jar if the .TOC isn't available
as is currently the case for prebuilt jars).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/14203002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@194080 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some commands that are called by build scripts are particularly verbose
(ant, dex, readelf). For these commands, the output (when successful)
is not useful (unlike javac, for example). Add an option
(suppress_output) to build_util.CheckCallDie to disable printing of
stdout/stderr when the call is successful.
Also, move remaining build scripts in build/android to
build/android/gyp.
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/13473017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192409 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some build steps, particularly javac, have really loose input rules.
I.e. javac steps are re-built when any input jar changes. Often, this
leads to unnecessary rebuilds of all the following steps.
Other build tools (ninja, goma), will check the contents of the inputs
to a step, and if those inputs haven't changed that tool doesn't
actually re-run the command for creating the output.
This change brings that same benefit to some of the Android python
build scripts. Particularly those that will save a significant amount
of time by adding input content checks.
The checking checks both the input files and the command that will be
run. It compares this against a stored md5 digest. If it has not
changed, then the output does not need to be recreated (though it is
still touched to trigger following steps).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13432002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192265 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
For the component build, it is impractical/impossible to explicitly
list all library dependencies. This list is required (in dependency
order) for several of the apk-building steps.
For now, we will generate this list as follows:
Use readelf to find all transitive dependencies
Topologically sort those dependencies
Once we can expose this information from gyp
(http://crbug.com/2255588), it is straightforward to update this action
to use the gyp-exposed list of libraries.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13261024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192103 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Libraries could previously access dependencies' resources in Java code
but not in XML layout files. This enables accessing these resources in
layout files as well, with the compromise that resources can now be
accessed using the wrong package name in Java code. Since resource
names are global anyway (an APK can't contain two resources with the
same name), this is deemed OK.
BUG=176069
Review URL: https://chromiumcodereview.appspot.com/13107002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190896 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This enables Android layouts and Java code to use strings from
generated_resources.grd directly. Strings tagged with
formatter_data="android_java" in generated_resources.grd are used to produce an
Android strings xml file.
BUG=176069
Review URL: https://chromiumcodereview.appspot.com/12529025
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190573 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
r188747 didn't actually fix the webview build problem (though it's still
a useful refactoring) - the right fix is just to add quotes to the
expansion in java.gypi such that the shell doesn't try to expand make
variables.
BUG=
Review URL: https://codereview.chromium.org/12917008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@188760 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is a fairly straightforward translation of the ant build script
into two python actions.
Two things have been moved into the gyp file: adding android.jar to the
classpath and specifying the jar_excludes (currently just R.class and
R$*.class).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/12853002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@188594 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This appends the list of inputs to the ant and process_resources.py
commands. Thus when the list of inputs changes, the command line
changes, and ninja will re-run the command.
This will be removed once ninja is updated to automatically rebuild
when the input list changes.
BUG=177449,177552
Review URL: https://chromiumcodereview.appspot.com/12379066
git-svn-id: http://src.chromium.org/svn/trunk/src/build@186299 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
This generates localized strings.xml files (e.g.
values-fr/strings.xml) from grd and xtb files at build time. This
means we no longer need to check in localized strings.xml files. Note:
the xtb files are empty until translations are available.
Benefits:
- 41 fewer extraneous results when grepping Java string IDs
- Switching from maintaining strings in strings.xml over to using a
grd file is One Trivial CL* away: just include English in the list
of languages for which we generate strings.xml files.
*Restrictions may apply
Originally landed as https://codereview.chromium.org/11659006/
This can be re-landed as of https://codereview.chromium.org/11880050/
BUG=167248
TBR=yfriedman@chromium.org,thakis,jam@chromium.org,cjhopman,shashishekhar@chromium.org
Review URL: https://codereview.chromium.org/11967005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@177170 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Some fixes included:
- Changes to resource management to account for new R.java packaging
from library projects
(https://android-review.googlesource.com/#/c/43134/).
- Fixed the package for some inludes in ModalDialogTest.java. This only
worked because of how we previously used to aggregate all resoures
from the prior layer. With the new packaging, we must use the resource
from the appropriate layer.
BUG=163001,166434
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/11819047
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176176 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
> [Android] Generate localized strings.xml files at build time.
>
> This generates localized strings.xml files (e.g.
> values-fr/strings.xml) from grd and xtb files at build time. This
> means we no longer need to check in localized strings.xml files. Note:
> the xtb files are empty until translations are available.
>
> Benefits:
> - 41 fewer extraneous results when grepping Java string IDs
> - Switching from maintaining strings in strings.xml over to using a
> grd file is One Trivial CL* away: just include English in the list
> of languages for which we generate strings.xml files.
>
> *Restrictions may apply
>
> BUG=167248
>
> Review URL: https://codereview.chromium.org/11659006TBR=newt@chromium.org
Review URL: https://codereview.chromium.org/11820058
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176151 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This generates localized strings.xml files (e.g.
values-fr/strings.xml) from grd and xtb files at build time. This
means we no longer need to check in localized strings.xml files. Note:
the xtb files are empty until translations are available.
Benefits:
- 41 fewer extraneous results when grepping Java string IDs
- Switching from maintaining strings in strings.xml over to using a
grd file is One Trivial CL* away: just include English in the list
of languages for which we generate strings.xml files.
*Restrictions may apply
BUG=167248
Review URL: https://codereview.chromium.org/11659006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@176134 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This generates the copy of R.java used to compile the library jar (formerly
done in gyp) and adds a new step to crunch image resources.
The imaging crunching step fixes the link preview 9-patch drawing artifact,
among other benefits.
BUG=163602
Review URL: https://codereview.chromium.org/11516024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@172655 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This provides support for android-style resource folders in content and other
non-apk Java targets. The AppResource hack can then be removed shortly.
Details: while building a non-apk target (e.g. chromium_content.jar), we
generate an R.java file with non-final constants and in the appropriate Java
package (e.g. org.chromium.content.R) using the resources in the target (e.g.
content/public/android/java/res). This R.java is used to produce the jar, but is
not included in the jar itself.
When we later build an apk, we merge the resources from the apk (e.g.
org/chromium/content_shell/res) with the resources from the non-apk targets it
depends on (e.g. content/public/android/java/res). A new R.java is generated
using the merged resources with the correct mapping from resources to integer
IDs. This R.java file is copied into each needed package (e.g.
org.chromium.content.R and org.chromium.content_shell.R) and included in the
apk.
This is the first of three CLs to replace AppResource with R:
1. http://codereview.chromium.org/11363150 - Support Java resources within content
2. http://codereview.chromium.org/11360207 - Add Java resources to content and chrome
3. http://codereview.chromium.org/11377117 - Remove AppResource and unneeded resources
BUG=136704
Review URL: https://codereview.chromium.org/11363150
git-svn-id: http://src.chromium.org/svn/trunk/src/build@168283 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The cacheinvalidation_java target is also added to build/all_android.gyp to
ensure it is always built since nothing currently depends on it upstream.
When all of Android-specific sync code is upstreamed, a target for sync
should be used instead of cacheinvalidation.
BUG=158382
Review URL: https://chromiumcodereview.appspot.com/11146005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@167746 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
all_dependent_settings is more like the link_settings that we would like
to use here. This variable is used by java targets to set the classpath
for javac, i.e. to set the libraries that are needed by the target.
Use of direct_dependent_settings with export_dependent_settings causes
unnecessary duplication of all java dependencies for all of our java
library targets.
BUG=146049
TBR=sky,brettw
Review URL: https://chromiumcodereview.appspot.com/10986094
git-svn-id: http://src.chromium.org/svn/trunk/src/build@160768 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The ant build files for each of the apks that we create consisted of
only fairly straightforward boilerplate. With the recent changes to
java_apk.gypi and the gyp targets we can now build these correctly from
a single .xml with the differences in how the targets are built being
reflected in the gyp files (and then passed into ant).
TBR=joth
BUG=145991
Review URL: https://chromiumcodereview.appspot.com/10959034
git-svn-id: http://src.chromium.org/svn/trunk/src/build@160396 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
Add a new property generate.test.jar to ant scripts.
When this property is set, a jar containing all compiled
classes and referred classes is generated and placed in
out/{Debug|Release}/test.lib.java directory.
This makes it easier and cleaner to write ant build files for test apks.
New directory structure for the build:
Apks are placed in : out/{Debug|Release}/apks
All java libraries in : out/{Debug|Release}/lib.java
All test java libraries in : out/{Debug|Release}/test.lib.java
This CL also includes cleanup to work with the modified output
directory structure.
BUG=146583
Review URL: https://chromiumcodereview.appspot.com/10905138
git-svn-id: http://src.chromium.org/svn/trunk/src/build@157570 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This is the first CL to replace the ant property toolchain.dir with
android.gdbserver.
After this submitted
- Add android_gdbserver into WebKit gypis.
- Retire the toolchain.dir from ant by using android.gdbserver.
- Remove the ANDROID_TOOLCHAIN from both WebKit and chromium's gyp/gypi
- Remove the android_toolchain from envsetup_function.sh
TBR=jam
BUG=
Review URL: https://chromiumcodereview.appspot.com/10886046
git-svn-id: http://src.chromium.org/svn/trunk/src/build@154298 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The ant build files for each of the jars that we create consisted of
only fairly straightforward boilerplate. With the recent changes to
java.gypi and java_aidl.gypi we can now build these correctly from a
single .xml with GYP passing in defines for the minor differences.
BUG=136756
Review URL: https://chromiumcodereview.appspot.com/10831227
git-svn-id: http://src.chromium.org/svn/trunk/src/build@151334 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
Both java.gypi and apk_test.gypi expect the jar path in
input_jars_paths. This means that we were specifying the dependence in
both 'dependencies' and 'input_jars_paths'. This change makes it so that
we don't need that redundancy.
Also, make java.gypi use input_jars_paths in its input so that we
actually rebuild targets when we should.
BUG=136756
Review URL: https://chromiumcodereview.appspot.com/10837143
git-svn-id: http://src.chromium.org/svn/trunk/src/build@150850 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Also includes a refactoring of the Ant xml scripts to use a common template (contributed by shashishekhar@chromium.org). As part of this, I also continued Torne's effort of removing our reliance on environment variables. Unfortunately this currently means that you have to specify 5 gyp flags:
ANDROID_SDK, ANDROID_SDK_ROOT, ANDROID_SDK_TOOLS, ANDROID_SDK_VERSION, ANDROID_TOOLCHAIN.
This'll get better as we make further use of the checked in sdk both upstream and downstream. The problem stems from the android tree and released sdk having different configurations.
Review URL: https://chromiumcodereview.appspot.com/10830012
git-svn-id: http://src.chromium.org/svn/trunk/src/build@150172 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The logic to calculate where the SDK should be is already done by
envsetup and made available to gyp as a variable, so just have gyp pass
this as a command line argument to ant. The behaviour is identical.
This change is to move toward making it possible to build the Android
port without having envsetup.sh sourced at build time (only at
gyp-generation time), making it more like other platforms. It also
simplifies the ant buildfiles.
Review URL: https://chromiumcodereview.appspot.com/10821105
git-svn-id: http://src.chromium.org/svn/trunk/src/build@149400 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The primary issues is specifying the right path to PRODUCT_DIR (i.e.
out/Release). The gyp generator for make specifies the absolute path but
for ninja would use a relative path. Since the gyp targets don't line
up with where the ant build files are located this causes failures such
as base's java being generated in base/android/out/Release/...
See:
https://groups.google.com/forum/#!msg/gyp-developer/K2T_9obUya0/qq78_Ut-E-AJ
for details.
A couple of other minor fixes:
- content java files are placed in out/Release/java/content to be
consisent with other packages.
- shared-libraries are now referenced by correct variables for apk-based
tests
- removed unused media/base/android/java/java.gyp (target is in
media/media.gyp)
TBR=mark@chromium.org,ben@chromium.org,rsleevi@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10386188
git-svn-id: http://src.chromium.org/svn/trunk/src/build@139418 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Build media java files (we weren't).
Fix adb_install_content_shell for cases where the app was stuck.
Add upstream staging gyp var / #define.
Be more consistent about jar output files (all in lib.java).
Upstream a bunch of random files (e.g. ppapi).
Upstream a bunch of java and native code hit as part of shlib init.
Properly package jar files in content shell.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10377059
git-svn-id: http://src.chromium.org/svn/trunk/src/build@136219 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
avayvod@chromium.org
andrewhayden@chromium.org
kkimlabs@chromium.org
cjhopman@chromium.org
yfriedman@chromium.org
boliu@chromium.org
newt@chromium.org
torne@chromium.org
smckay@chromium.org
nyquist@chromium.org
yusufo@chromium.org
peter@chromium.org
shashishekhar@chromium.org
michaelbai@chromium.org
jrg@chromium.org
tedchoc@chromium.org