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
With the component build we need to always trigger stripping because we
can't specify the inputs correctly at gyp time. This is not required
for the non-component build.
Also, slightly refactor strip_native_libraries.gypi and its users to
make it more clear what variables are being used by the .gypi.
Review URL: https://chromiumcodereview.appspot.com/14844009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@200422 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Debug APKs with native libraries should include gdbserver. Copy this
into the apk_package_native_libs_dir. Then, the apkbuilder task will
include this in the APK for debug builds (but not for release builds).
TEST=unzip -l ContentShell.apk should list gdbserver for debug builds
(but not for release)
Review URL: https://chromiumcodereview.appspot.com/14200040
git-svn-id: http://src.chromium.org/svn/trunk/src/build@196203 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
If the device folder is not specific to debug/release, then switching
configurations changes the state on the device without updating the
corresponding records on the host (i.e. it only updates the ones for
that configuration).
NOTRY=true
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/14238023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@195852 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
On new versions of Android, re-installing an APK creates a new /lib/
folder for native libraries. This means we need to recreate all the
symlinks in that directory (not just the ones that have changed).
To make all these links quickly, it should run as a single adb command.
To make that simple, we first create a simple script that, when run,
creates all the symlinks for an APK. Then, after any install, we send a
single adb command to run that script.
This also requires that the apk_install script only triggers its
dependents when it actually installs an apk.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/14017010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@195124 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Repurposes the gyp scripts for processing native libraries for an apk and use them for a native library (i.e. forwarder).
Additionally, adjusts the forwarder python script to set LD_LIBRARY_PATH when invoking the forwarder.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/14322004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@194833 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This adds a fake output path to several actions in java_apk.gypi:
push_libraries
apk_install
strip_libraries (when component==shared_library)
Adding this fake output makes the build system think that these actions
always need to be run when building the corresponding APK (because the fake
output is never up-to-date).
For the first two actions, this is required to ensure that (when
gyp_managed_install==1) the APK on the device (and its libraries) are
always up-to-date. If a user switches the connected device, then these
actions must be run even if no files on the host changed.
For strip_libraries, we do not know at gyp-time what the real inputs to
the action are (i.e. all the library dependencies). Also, ninja does
some build magic such that if you change a library (base.so for example)
its dependencies will not necessarily change.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13599002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@193518 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Splits apk-package.xml into apk-package.xml and
apk-package-resources.xml and adds a new gyp action for
package-resources.
This continues the simplification of gyp actions (i.e. each individual
action should be simple).
Also, allows more accurate specification of inputs for
-package-resources vs -package (and allows -package-resources to be
done in parallel with javac/dex/etc.).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13811027
git-svn-id: http://src.chromium.org/svn/trunk/src/build@193491 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Currently, normal APKs and instrumentation APKs are both built using
java_apk.gypi (which includes all kinds of new hotness). Native
unittest APKs, though use apk_test.gypi and thus the complicated
native_test_apk.xml and Android's Ant build.xml. That is bad.
This change updates apk_test.gypi to include java_apk.gypi and so
brings these two ways of building APKs into alignment. It also very
slightly updates the configurability of java_apk.gypi and
apk-package.xml.
There are still a couple of targets in WebKit that use
generate_native_test.py and native_test_apk.xml directly that need to
be updated to use apk_test.gypi before those two scripts can be
simplified/removed.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13564003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192662 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With gyp_managed_install no shared libraries should be packaged in the
APK (except gdbserver).
When toggling gyp_managed_install, there may be left over libraries in
<(intermediate_dir)/libs. APK packaging should use a different
directory when doing a managed install, so that it does not include the
library from a non-gyp_managed_install build.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13651003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192617 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The md5 stamp path includes the device serial (i.e. the stamp is
library-device specific).
Also, this no longer creates a shell for-loop as the command to send to
adb. adb shell has a ~1000 character limit for commands, and the
for-loop was exceeding that limit. Now that we only create links for
libraries that actually have changed, there is not as much benefit to
creating all the links in one adb command.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13537006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192484 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
With the component build, we tell Dalvik to load each library separately by name. Some of our library names conflict with android shared libraries resulting our library not getting loaded. When building for components on Android, change the suffix of libraries to "cr.so" e.g. libnetcr.so to avoid colliding with Android's copies
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13549002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@192258 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
When an APK is installed, any native libraries it contains are
extracted to the APK's lib folder on the device. It is actually
possible to add, change, or remove libraries in that folder directly.
This means, that when gyp is managing the install of APKs, the APK does
not actually need to include the native library, and that can be pushed
separately.
This does several nice things:
libraries can be pushed while a .apk is building
.apk no longer needs to be rebuilt+reinstalled when a library changes
if native library isn't changed, it doesn't need to be zipped+installed
w/ component build, only changed libraries will need to be reinstalled
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13334003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@191888 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Add a gyp variable "android_managed_install" which defaults to off/0.
When this variable is 1, building an apk target will install that
target.
This will allow us to do crazy things with the install like pushing
native libraries independent from the apk they belong to.
This currently just does an "adb install -r <(apk_path)". I.e. it only
works for (the typical) single device attached workflow. This could
be made configurable to handle other cases (or maybe just install to all
devices attached, or just to the first device).
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13269002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@191840 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
First, this allows us to correctly have the output of the copy/strip
action be an input to the apk package action.
Second, this step now uses the list of libraries created by ordered
libraries step. This is required to support the component build where
we can not manually list the required libraries.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/13058003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@191754 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
At build time, we know what native libraries an apk needs to load.
Instead of requiring those .apks to specify this again in code, instead
generate a .java file containing a list of the libraries to load.
This is done using a pattern similar to resources, content_java is built
with a placeholder NativeLibraries.java (i.e. without an actual value
for its libraries list). The corresponding .class file is not included
in content_java.jar. Then, when building an apk we generate the "real"
NativeLibraries.java (with the real String[]) and include that in the
.apk.
This is designed to also support the component build, where, we will
have to calculate the list of libraries at build time, and sort them in
dependency order (because Android's linker, for some reason, doesn't do
that itself).
BUG=158821
TBR=brettw@chromium.org
Review URL: https://chromiumcodereview.appspot.com/12939021
git-svn-id: http://src.chromium.org/svn/trunk/src/build@191695 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Proguard should only be run in Release mode (in gyp, proguard_enabled is
not set based on the configuration). This is the way that we had
been determining whether or not to run proguard before recent Ant
refactoring.
Also, proguard needs the path to the android.jar
BUG=224079
Review URL: https://chromiumcodereview.appspot.com/12922004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190876 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In preparation for rewriting these actions in python, split apk-build.xml into smaller ant scripts. This should not change the functionality and mostly is just splitting the file and identifying the properties and defines required for each of the new files.
Some of the configuration is moved out of ant and into gyp (i.e. the android_manifest_path is now gyp-configurable).
Also, the ant scripts now use the correct basedir! That is, these ant scripts actually understand relative paths. To go along with this, resource_dir is the relative path to the resource directory (rather than a path relative to java_in_dir).
BUG=158821
TBR=torne@chromium.org, brettw@chromium.org
NOTRY=true
Review URL: https://chromiumcodereview.appspot.com/12963009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@190712 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
First check in a copy of
third_party/android_tools/sdk/tools/ant/build.xml as
build/android/ant/apk-build.xml
Previously we were overriding targets from this build.xml
in build/android/ant/sdk-targets.xml. Instead of doing this
override, just replace the actual targets in apk-build.xml.
Do the same for properties that we were overriding in
build/android/ant/chromium-apk.xml.
Both of these have no logical change on these build scripts.
Ant's targets and properties are immutable and so Ant was
doing this exact thing already.
BUG=158821
Review URL: https://chromiumcodereview.appspot.com/12599005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@187483 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
Failed to rename package name in buildbot scripts. Broke buildbots.
> Add apk for running content_browsertests
>
> Split off org.chromium.content_shell into:
> org.chromium.content_shell - content shell java code, builds a jar, directory structure similar to other jar targets
> org.chromium.content_shell_apk - application code to build content_shell_apk, directory structure similar to that of android application
> org.chromium.content_browsertests_apk - application code to build content_browsertests_apk
>
> Also splitting content/shell/android/res into:
> - content/shell/android/java/res
> - content/shell/android/shell_apk/res
>
> Both content_shell_apk and content_browsertests_apk will depend on content_shell_java target to include java/res needed to show a shell based browser.
>
> I will do another CL to move The java files for content_shell_tests_apk to content_shell_apk package.
>
> BUG=138275
>
>
> Review URL: https://chromiumcodereview.appspot.com/12047068TBR=nileshagrawal@chromium.org
Review URL: https://codereview.chromium.org/12088031
git-svn-id: http://src.chromium.org/svn/trunk/src/build@179211 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Split off org.chromium.content_shell into:
org.chromium.content_shell - content shell java code, builds a jar, directory structure similar to other jar targets
org.chromium.content_shell_apk - application code to build content_shell_apk, directory structure similar to that of android application
org.chromium.content_browsertests_apk - application code to build content_browsertests_apk
Also splitting content/shell/android/res into:
- content/shell/android/java/res
- content/shell/android/shell_apk/res
Both content_shell_apk and content_browsertests_apk will depend on content_shell_java target to include java/res needed to show a shell based browser.
I will do another CL to move The java files for content_shell_tests_apk to content_shell_apk package.
BUG=138275
Review URL: https://chromiumcodereview.appspot.com/12047068
git-svn-id: http://src.chromium.org/svn/trunk/src/build@179189 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
cjhopman@chromium.org
yfriedman@chromium.org
viettrungluu@chromium.org
jayjang@chromium.org
mkosiba@chromium.org
newt@chromium.org
nileshagrawal@chromium.org
smckay@chromium.org