apkbuilder only uses sourcefolder to package non-java files (see
addSourceFolder() and checkFileForPackaging() in
e162064a7b/sdkmanager/libs/sdklib/src/com/android/sdklib/build/ApkBuilder.java ),
and our java/src folders only contain .java (and OWNERS) files.
(Determined via `find . -type f -a -path '*/src/*' -a -not -name '*.java'` and
manually ignoring everything not looking like a java folder.)
No intended behavior change; Chrome.apk looks identical with and without
this change (except for timestamps).
BUG=none
NOTRY=true
Review URL: https://codereview.chromium.org/212173003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@260047 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
After r256667, the list of java files for javac is written into a gyp
filelist, which gets rewritten if a java file is removed. (If a generated
java file is removed, that still doesn't cause a rebuild, but that didn't
happen before this CL either, http://crbug.com/) This allows removing the
md5sum call for javac in java_apk.gypi.
java.gypi also has additional_input_paths as input, but that's only used
for stamp files, for ordering purposes, so it's not necessary to re-run
the javac action if a stamp file disappears from additional_input_paths.
With the same reasoning, the md5sum call in 'ant package resources' is not
needed: additional_input_paths is the only non-stamp input that isn't also
on the command line. ('ant package resources' is missing some inputs, but
that's independent of this change: http://crbug.com/351928)
No behavior change.
BUG=177552
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/198283003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256746 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Before this CL, the javac action rules called `find javadir -name "*.java"` to
compute the action's inputs, and passed javadir to javac.py. The script then
again looked for all .java files in that directory. One issue with that approach
is that if a java file gets removed, the javac.py action didn't get executed again
since actions are only run if their commandline changes or an input file is newer
than an output file – a disappearing input doesn't mark an action dirty. (As
workaround, the md5 hash of all .java files is currently passed in an
--ignore parameter, so removal of a java file will lead to a changing
commandline, which _will_ cause a rebuild.)
After this CL, the result of `find javadir -name "*.java"` is written to a gyp
filelist (see https://codereview.chromium.org/27418008/), and the filelist
is passed to javac.py. gyp writes filelists exactly if their contents would
change, so removal of java file will change the mtime of the filelist, which will
cause a rebuild. Another advantage is that the list of java files is computed in
only one place.
This CL doesn't yet remove the md5 hack, but it makes it possible to do so
in a follow-up change.
(This approach doesn't work for generated java files, because these might
not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
use for generated files. The dependency handling of generated java files is
done through stamp files, so the md5 hack isn't needed for them.)
No intended behavior change.
BUG=177552
R=cjhopman@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=256097
Review URL: https://codereview.chromium.org/193693002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256667 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Breaks target device_extras_apk on the upstream bot, due to the src/ issue
mentioned on the review: A java target contains another java target in a
subdirectory, and due to the missing src/ the java files in the subtarget
get picked up twice.
> android: Pass (non-generated) .java files via a gyp filelist to javac.py
>
> Before this CL, the javac action rules called `find javadir -name "*.java"` to
> compute the action's inputs, and passed javadir to javac.py. The script then
> again looked for all .java files in that directory. One issue with that approach
> is that if a java file gets removed, the javac.py action didn't get executed again
> since actions are only run if their commandline changes or an input file is newer
> than an output file – a disappearing input doesn't mark an action dirty. (As
> workaround, the md5 hash of all .java files is currently passed in an
> --ignore parameter, so removal of a java file will lead to a changing
> commandline, which _will_ cause a rebuild.)
>
> After this CL, the result of `find javadir -name "*.java"` is written to a gyp
> filelist (see https://codereview.chromium.org/27418008/), and the filelist
> is passed to javac.py. gyp writes filelists exactly if their contents would
> change, so removal of java file will change the mtime of the filelist, which will
> cause a rebuild. Another advantage is that the list of java files is computed in
> only one place.
>
> This CL doesn't yet remove the md5 hack, but it makes it possible to do so
> in a follow-up change.
>
> (This approach doesn't work for generated java files, because these might
> not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
> use for generated files. The dependency handling of generated java files is
> done through stamp files, so the md5 hack isn't needed for them.)
>
> No intended behavior change.
>
> BUG=177552
> R=cjhopman@chromium.org
>
> Review URL: https://codereview.chromium.org/193693002TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/194293002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256127 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Before this CL, the javac action rules called `find javadir -name "*.java"` to
compute the action's inputs, and passed javadir to javac.py. The script then
again looked for all .java files in that directory. One issue with that approach
is that if a java file gets removed, the javac.py action didn't get executed again
since actions are only run if their commandline changes or an input file is newer
than an output file – a disappearing input doesn't mark an action dirty. (As
workaround, the md5 hash of all .java files is currently passed in an
--ignore parameter, so removal of a java file will lead to a changing
commandline, which _will_ cause a rebuild.)
After this CL, the result of `find javadir -name "*.java"` is written to a gyp
filelist (see https://codereview.chromium.org/27418008/), and the filelist
is passed to javac.py. gyp writes filelists exactly if their contents would
change, so removal of java file will change the mtime of the filelist, which will
cause a rebuild. Another advantage is that the list of java files is computed in
only one place.
This CL doesn't yet remove the md5 hack, but it makes it possible to do so
in a follow-up change.
(This approach doesn't work for generated java files, because these might
not yet exist at gyp time. Rename --src-dirs to --src-gendirs and keep it in
use for generated files. The dependency handling of generated java files is
done through stamp files, so the md5 hack isn't needed for them.)
No intended behavior change.
BUG=177552
R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/193693002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256097 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
No intended behavior change.
dex_action.gypi didn't pass its input_paths variable to dex.py,
but that was only set in a single place, and only to a single file there.
It was only used in java_apk.gypi which does manual threading of
stamp files to order actions (since it's a gypi, it can't easily use type
none targets with dependencies). Since dex.py doesn't look at this
stamp file at all, it doesn't need to rerun when the stamp file disappears.
To make this a bit more obvious, remove dex_action.gypi's input_paths
variable and set 'inputs' directly in the one place with the stamp file.
(dex.py will still rerun if the name of the stamp file changes, due to
regular timestamp handling.)
java_apk.gypi used to set input_paths to two files in proguard-enabled
files – change it to depend only on obfuscate_stamp in proguard builds,
as the step that writes that already depends on instr_stamp. (This isn't
necessary as the proguard state is part of the dex.py commandline, so
toggling between proguard and no proguard would rebuild correctly
anyways, but it's conceptually a bit nicer.)
Also set proguard_enabled_input_path unconditionally. Again, no behavior
change, but keeps the gyp a bit shorter.
BUG=177552
NOTRY=true
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255325R=cjhopman@chromium.org
Review URL: https://codereview.chromium.org/183883024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255403 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Reason for revert:
Experimentally reverting because it is possible that this CL broke the android build http://build.chromium.org/p/chromium/builders/Android/builds/21418/steps/compile/logs/stdio
Will undo the revert if this CL is innocent
Original issue's description:
> android: Make dex_action.gypi not call md5sum.
>
> No intended behavior change.
>
> dex_action.gypi didn't pass its input_paths variable to dex.py,
> but that was only set in a single place, and only to a single file there.
> It was only used in java_apk.gypi which does manual threading of
> stamp files to order actions (since it's a gypi, it can't easily use type
> none targets with dependencies). Since dex.py doesn't look at this
> stamp file at all, the it doesn't need to rerun when the stamp file disappears.
>
> To make this a bit more obvious, remove dex_action.gypi's input_paths
> variable and set 'inputs' directly in the one place with the stamp file.
> (dex.py will still rerun if the name of the stamp file changes, due to
> regular timestamp handling.)
>
> BUG=177552
> NOTRY=true
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=255325TBR=cjhopman@chromium.org,thakis@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=177552
Review URL: https://codereview.chromium.org/185563012
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255356 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
No intended behavior change.
dex_action.gypi didn't pass its input_paths variable to dex.py,
but that was only set in a single place, and only to a single file there.
It was only used in java_apk.gypi which does manual threading of
stamp files to order actions (since it's a gypi, it can't easily use type
none targets with dependencies). Since dex.py doesn't look at this
stamp file at all, the it doesn't need to rerun when the stamp file disappears.
To make this a bit more obvious, remove dex_action.gypi's input_paths
variable and set 'inputs' directly in the one place with the stamp file.
(dex.py will still rerun if the name of the stamp file changes, due to
regular timestamp handling.)
BUG=177552
NOTRY=true
Review URL: https://codereview.chromium.org/183883024
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255325 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
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
mkosiba@chromium.org
qsr@chromium.org
rmcilroy@chromium.org
gunsch@chromium.org
thakis@chromium.org
pkotwicz@chromium.org
aberent@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