Add APK targets for content_unittests and net_unittests.

build/apk_test.gypi

+# Copyright (c) 2012 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.
+
+# This file is meant to be included into a target to provide a rule
+# to build APK based test suites.
+#
+# To use this, create a gyp target with the following form:
+# {
+#   'target_name': 'test_suite_name_apk',
+#   'type': 'none',
+#   'variables': {
+#     'test_suite_name': 'test_suite_name',
+#     'jar_name': 'test_suite.jar',
+#   },
+#   'includes': ['path/to/this/gypi/file'],
+# }
+#
+# Note: This assumes that there is a shlib named lib${test_suite_name}.so
+# in ${PRODUCT_DIR}/lib.target/
+#
+# TODO(nileshagrawal): Add support for including multiple jars. The underlying
+# python native test generator does not support it yet.
+#
+
+{
+  'actions': [

[Ryan Sleevi, 2012/05/23 01:00:45]

I feel like you should be checking 

'target_conditions': [
  ['_toolset == "target"', {
    'conditions': [
      ['OS == "android" and _component == "shared_library"', {
        'actions': [ ... ],
      }],
    ],  # conditions
  }],
],  # target_conditions

[nilesh, 2012/05/23 22:45:20]

Done.

+    {
+      'action_name': 'apk_<(test_suite_name)',
+      'message': 'Building <(test_suite_name) test apk.',
+      'inputs': [
+         '../testing/android/AndroidManifest.xml',
+         '../testing/android/generate_native_test.py',

[Ryan Sleevi, 2012/05/23 01:00:45]

I'm pretty sure these two (line 32, 33) should be using <(DEPTH). That's
because, IIRC, file relativization happens post-GYPI merging, which means the
'../' will be relative to the including .gyp.

Might want to double check the GYP sources.

[nilesh, 2012/05/23 22:45:20]

Done.

+         '<(PRODUCT_DIR)/lib.target/lib<(test_suite_name).so',
+         '<(PRODUCT_DIR)/lib.java/<(jar_name)',

[Ryan Sleevi, 2012/05/23 01:00:45]

I think I'd feel better if the caller was required to fully qualify the path to
the inputs, rather than making this .gypi do it.

That way, it's clear at the 'include' time what the input/output dependencies
are.

[nilesh, 2012/05/23 22:45:20]

Done.

+      ],
+      'outputs': [
+        '<(PRODUCT_DIR)/<(test_suite_name)_apk/<(test_suite_name)-debug.apk',

[Ryan Sleevi, 2012/05/23 01:00:45]

Should this be "->(_configuration).apk" instead of hardcoding "-debug" here?

Note, >() because this is a target-expansion that needs to happen after this has
been merged (see
http://code.google.com/p/gyp/wiki/InputFormatReference#Variable_Expansions_(<...
)

[nilesh, 2012/05/23 22:45:20]

Currently, we always generate *-debug.apk (even for BUILDTYPE=Release). There
are some issues (for e.g. signing the apk) with trying to generate non-debug APK
using ant.

+      ],
+      'action': [
+        '../testing/android/generate_native_test.py',
+        '--native_library',
+        '<(PRODUCT_DIR)/lib.target/lib<(test_suite_name).so',

[Ryan Sleevi, 2012/05/23 01:00:45]

'/lib.target/<(SHARED_LIB_PREFIX)<(test_suite_name)<(SHARED_LIB_SUFFIX)'

[nilesh, 2012/05/23 22:45:20]

Done.

+        '--jar',
+        '<(PRODUCT_DIR)/lib.java/chromium_base.jar',

[Ryan Sleevi, 2012/05/23 01:00:45]

Is this right?

Did you mean to do '<(PRODUCT_DIR)/lib.java/<(jar_name)' instead?

If not, I'm of the opinion that the caller should explicitly specify their
dependencies as arguments. You should also be ensuring those dependencies are
added to the list of 'inputs' on line 31.

You should define the instances (line 34, 35, 43, 45) as variables, so that it's
clear what was intended.

For that matter, I think lines 38/47 would also be served as variables.

Note, the variables should be suffixed appropriately (_file/_path - see
http://code.google.com/p/gyp/wiki/InputFormatReference#Pathname_Relativization )


Note, for specifying dependencies, you could use list expansion (
http://code.google.com/p/gyp/wiki/InputFormatReference#Variable_Expansions_(<...
), such like

'--jar', '<@(required_jar_paths)'

becomes

--jar foo1.jar foo2.jar foo3.jar [etc]

I'm guessing this would require updating the generate_native_test.py script
first

[nilesh, 2012/05/23 22:45:20]

Yes. Thanks for catching.
Done
The output-dir and output filename are hardcodeded. We don't want the caller to
modify these. Out test runner scripts rely on these APKs to be present here.
Done

+        '--output',
+        '<(PRODUCT_DIR)/<(test_suite_name)_apk',
+        '--ant-args',
+        '-DPRODUCT_DIR=<(PRODUCT_DIR)',
+        '--ant-compile'
+      ],
+    },
+  ],
+}