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
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
Previously, we had to keep this name in sync in multiple places, the
"fake" xxx_java target and in sdk-targets.xml. Instead, it should be set
only in java_apk.gypi and then passed along to each of the places that
we were specifying it before.
Also, delete unused 'output' block and unneeded xxx_java dependencies.
BUG=
Review URL: https://chromiumcodereview.appspot.com/11363131
git-svn-id: http://src.chromium.org/svn/trunk/src/build@168148 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
cjhopman@chromium.org
viettrungluu@chromium.org
yfriedman@chromium.org
jayjang@chromium.org
mkosiba@chromium.org
newt@chromium.org
nileshagrawal@chromium.org
smckay@chromium.org
shashishekhar@chromium.org