This CL modifies the build to incorporate the expected C++ library version
in the Java code. This is then checked when the library is loaded, to
make sure that the C++ and Java builds match.
This CL also implements error handling when library loads fail or the
loaded version doesn't match the expected version.
BUG=311644
Review URL: https://codereview.chromium.org/59533009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@237779 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This patch adds a new Chrome-specific dynamic linker for Android,
that implements RELRO section sharing in order to save about 1.3 MB
of RAM per renderer process in content-based programs (ContentShell,
ChromiumTestShell, Chrome, etc...)
The linker is disabled by default. For more details, see the corresponding bug entry.
This introduces a new test package (content_linker_test_apk) as well as a new test category. To build and test this feature, do the following:
ninja -C out/Debug content_linker_test_apk
build/android/test_runner.py linker
BUG=287739
R=qsr@chromium.org
Review URL: https://codereview.chromium.org/23717023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@229921 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This patch adds a dependency on entire android_tools target that contains
forwarder2 and md5sum to java_apk.gypi for all test apks, so that individual
test apk targets do not need to explicitly depend on the tools required to run
them.
BUG=271482
Review URL: https://chromiumcodereview.appspot.com/22865003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@217386 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When doing a gyp_managed_install, we install APKs to the attached
device. Currently this can fail in many ways (no device attached,
multiple devices attached, device offline, device doesn't have root,
etc.). In addition, we need to detect changes to the attached device
(particularly when the device is switched, when an APK is
uninstalled/updated).
The current approach is to check all this information in the action
interacting with the device. This means that when there is some
problem we print the same warning messages for every APK that is built,
and, in some cases, multiple times for each APK. Also, we have to run
every install/push action every build because we detect changes to the
attached device in that action.
This change creates a new build action, "get device configurations".
This action inspects the attached devices, filters out offline devices,
filters out devices without root, and then writes a configuration
file with the id+metadata for the first non-filtered device. This
configuration is then used by each of the build steps that interacts
with the device. This consolidates all the device checking to a single
place, and the build actions don't need to do any checking. In
addition, to detect changes in the attached device, we only need to run
this single action every build and the install/push actions will only
change when the device/metadata changes.
Also, with this change we can now gracefully handle the case where
multiple devices are attached (currently just write the configuration
for the first valid device and install to that one).
Review URL: https://chromiumcodereview.appspot.com/16831013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@209582 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@208529 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This breaks the Android component build.
This reverts commit 125e64a9eb6406446fb864aea9fa887521f19616.
>> [Android] Support building standalone APK in component build
>>
>> Many people's workflows assume that they can install the APK created in
>> out/Debug/apks. With the component build that APK is actually an
>> "incomplete" APK that cannot be manually installed (or rather causes
>> obscure errors when manually installed).
>>
>> This change does two things. First, it moves the "incomplete" APK
>> output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
>> accidental installs of the "incomplete" APK. Second, it introduces an
>> option (create_standalone_apk) that when doing a component build, if
>> set, will merge the shared libraries into the "incomplete" APK to
>> create a standalone APK. This standalone APK will be created in
>> out/Debug/apks/.
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
>>
>> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207516
BUG=
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/17291013
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207587 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207345
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207516 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Many people's workflows assume that they can install the APK created in
out/Debug/apks. With the component build that APK is actually an
"incomplete" APK that cannot be manually installed (or rather causes
obscure errors when manually installed).
This change does two things. First, it moves the "incomplete" APK
output to out/Debug/<package_name>/<ApkName>.apk. This should prevent
accidental installs of the "incomplete" APK. Second, it introduces an
option (create_standalone_apk) that when doing a component build, if
set, will merge the shared libraries into the "incomplete" APK to
create a standalone APK. This standalone APK will be created in
out/Debug/apks/.
Review URL: https://chromiumcodereview.appspot.com/14843017
git-svn-id: http://src.chromium.org/svn/trunk/src/build@207345 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
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
aberent@chromium.org
thakis@chromium.org
frankf@chromium.org
digit@chromium.org
peter@chromium.org
bulach@chromium.org
dtrainor@chromium.org
gkanwar@chromium.org
ppi@chromium.org
navabi@google.com
cjhopman@chromium.org
dfalcantara@chromium.org
skyostil@google.com
yfriedman@chromium.org
viettrungluu@chromium.org
jayjang@chromium.org