Allow the build to install apks

Allow the build to install apks

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
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=191840

[Yaron, 2013-03-29 00:30:29]

Rename "android_managed_apk_install"?

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py
File build/android/apk_install.py (right):

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:22: install_cmd = [
This only supports one device. Why not re-use build/android/adb_install_apk.py?

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:27: subprocess.check_call(install_cmd)
Nit: use your fancy CheckCallDie

[cjhopman, 2013-03-29 01:12:39]

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py
File build/android/apk_install.py (right):

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:22: install_cmd = [
On 2013/03/29 00:30:29, Yaron wrote:
> This only supports one device. Why not re-use
build/android/adb_install_apk.py?

I am hesitant to share a top level script with testing code. The things that we
care about are rather different, for example what we want in our options is
different (and the testing scripts typically use test_options_parser to keep
consistency with each other). 

Sharing at a lower level might make sense, though. I.e. have scripts with
different options but share the logic for installing apks across multiple
devices.

The main reason that I didn't do this was that android_commands.py (and
adb_interface.py that it depends on) assume that you have sourced envsetup.sh,
which the build does not currently require. I think that can be worked around,
but I thought this approach would keep the logic simpler.

Also, as we start to use other scripts in these actions, it becomes more likely
that an incremental build will be incorrect. I.e. if we fail to list a
transitive python dependency in an action's inputs (there are ~6-7 such files
throughout the tree for adb_install_apk.py), then one of those files could
change and silently break the build (because it didn't retrigger an action that
it should).

I think soon we will be forced to use android_commands.py (for PushIfNeeded),
and so maybe using that here would be ok.

wdyt?

[Yaron, 2013-03-29 17:18:22]

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py
File build/android/apk_install.py (right):

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:22: install_cmd = [
On 2013/03/29 01:12:39, cjhopman wrote:
> On 2013/03/29 00:30:29, Yaron wrote:
> > This only supports one device. Why not re-use
> build/android/adb_install_apk.py?
> 
> I am hesitant to share a top level script with testing code. The things that
we
> care about are rather different, for example what we want in our options is
> different (and the testing scripts typically use test_options_parser to keep
> consistency with each other). 
> 
> Sharing at a lower level might make sense, though. I.e. have scripts with
> different options but share the logic for installing apks across multiple
> devices.
> 
> The main reason that I didn't do this was that android_commands.py (and
> adb_interface.py that it depends on) assume that you have sourced envsetup.sh,
> which the build does not currently require. I think that can be worked around,
> but I thought this approach would keep the logic simpler.
> 
> Also, as we start to use other scripts in these actions, it becomes more
likely
> that an incremental build will be incorrect. I.e. if we fail to list a
> transitive python dependency in an action's inputs (there are ~6-7 such files
> throughout the tree for adb_install_apk.py), then one of those files could
> change and silently break the build (because it didn't retrigger an action
that
> it should).
> 
> I think soon we will be forced to use android_commands.py (for PushIfNeeded),
> and so maybe using that here would be ok.
> 
> wdyt?

Sounds reasonable. I think you raise a good point about incremental builds
though and it would be nice to be enforceable. I.e.. build/android should't
contain both scripts for gyp and for user-initiated actions. Otherwise, someone
down the line is going to refactor this and break it. Perhaps we could augment
checkdeps to enforce this? A simpler solution might be to move the gyp-related
python scripts to build/android/gyp/. Sharing at a lower-level sounds reasonable
to me too

[cjhopman, 2013-04-01 21:42:09]

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py
File build/android/apk_install.py (right):

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:22: install_cmd = [
On 2013/03/29 17:18:22, Yaron wrote:
> On 2013/03/29 01:12:39, cjhopman wrote:
> > On 2013/03/29 00:30:29, Yaron wrote:
> > > This only supports one device. Why not re-use
> > build/android/adb_install_apk.py?
> > 
> > I am hesitant to share a top level script with testing code. The things that
> we
> > care about are rather different, for example what we want in our options is
> > different (and the testing scripts typically use test_options_parser to keep
> > consistency with each other). 
> > 
> > Sharing at a lower level might make sense, though. I.e. have scripts with
> > different options but share the logic for installing apks across multiple
> > devices.
> > 
> > The main reason that I didn't do this was that android_commands.py (and
> > adb_interface.py that it depends on) assume that you have sourced
envsetup.sh,
> > which the build does not currently require. I think that can be worked
around,
> > but I thought this approach would keep the logic simpler.
> > 
> > Also, as we start to use other scripts in these actions, it becomes more
> likely
> > that an incremental build will be incorrect. I.e. if we fail to list a
> > transitive python dependency in an action's inputs (there are ~6-7 such
files
> > throughout the tree for adb_install_apk.py), then one of those files could
> > change and silently break the build (because it didn't retrigger an action
> that
> > it should).
> > 
> > I think soon we will be forced to use android_commands.py (for
PushIfNeeded),
> > and so maybe using that here would be ok.
> > 
> > wdyt?
> 
> Sounds reasonable. I think you raise a good point about incremental builds
> though and it would be nice to be enforceable. I.e.. build/android should't
> contain both scripts for gyp and for user-initiated actions. Otherwise,
someone
> down the line is going to refactor this and break it. Perhaps we could augment
> checkdeps to enforce this? A simpler solution might be to move the gyp-related
> python scripts to build/android/gyp/. Sharing at a lower-level sounds
reasonable
> to me too

Done.

https://codereview.chromium.org/13269002/diff/1/build/android/apk_install.py#...
build/android/apk_install.py:27: subprocess.check_call(install_cmd)
On 2013/03/29 00:30:29, Yaron wrote:
> Nit: use your fancy CheckCallDie

Done.

[Yaron, 2013-04-01 21:55:38]

lgtm

[commit-bot: I haz the power, 2013-04-02 15:00:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/cjhopman@chromium.org/13269002/28001

[commit-bot: I haz the power, 2013-04-02 16:55:48]

Change committed as 191840