Allow the build to install apks

build/android/apk_install.py

Index: build/android/apk_install.py
diff --git a/build/android/apk_install.py b/build/android/apk_install.py
new file mode 100755
index 0000000000000000000000000000000000000000..3955eabda1dc2e7e30b78accecc2d173e5ef619d
--- /dev/null
+++ b/build/android/apk_install.py
@@ -0,0 +1,34 @@
+#!/usr/bin/env python
+#
+# Copyright 2013 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+import optparse
+import os
+import subprocess
+import sys
+
+from pylib import build_utils
+
+
+def main(argv):
+  parser = optparse.OptionParser()
+  parser.add_option('--android-sdk-tools', action='store')
+  parser.add_option('--apk-path', action='store')
+  parser.add_option('--stamp', action='store')
+  options, _ = parser.parse_args()
+
+  install_cmd = [

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

This only supports one device. Why not re-use build/android/adb_install_apk.py?

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

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]

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]

Done.

+      os.path.join(options.android_sdk_tools, 'adb'),
+      'install', '-r',
+      options.apk_path]
+
+  subprocess.check_call(install_cmd)

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

Nit: use your fancy CheckCallDie

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

Done.

+
+  if options.stamp:
+    build_utils.Touch(options.stamp)
+
+
+if __name__ == '__main__':
+  sys.exit(main(sys.argv))