Support Native Tests in CTS

Bug 4970300

CTS uses XML files to determine what tests to run. The buildCts.py
script runs JavaDoc over Java files to create these listings. However,
this doesn't work for native tests which are executables written in
C++. This adds a Java tool called cts-native-xml-generator that
scans the C++ source files to find tests and then generates a
XML file that buildCts.py can pull in to form the CTS test plans.

The generate XMLs don't use a lot of the existing attributes
were intended for Java. I have also added a new "testType" attribute,
because each new test has so far added another boolean like
"vmHostTest=true" or "isHosttest=true"...

New build rules call cts-native-xml-generator in test_executable.mk.
Replace calls to include BUILD_EXECUTABLE with BUILD_CTS_EXECUTABLE
to not only create the executable like usual but to define a rule
that will call upon cts-native-xml-generator to create the test
package XML. An additional variable called LOCAL_CTS_TEST_PACKAGE
is required to give the native tests a parent test package which
is required by CTS.

CtsNativeTestCase.mk is a Makefile that defines a temporary location
to store the generated XMLs that are then copied to the final
location by build/core/cts.mk. This Makefile is included by the main
CTS Android.mk so that BUILD_CTS_EXECUTABLE can be used throughout
the project.

CtsTestCaseList also includes CtsNativeTestCase.mk to convert the
simple test executable names like "CtsNativeTestcases" to its
full path and the corresponding generated XML's path. These paths
are then passed to build/core/cts.mk. Both end up in the testcases
directory. We define two new variables, CTS_TEST_CASES and
CTS_TEST_XMLS. This is for future planning as discussed later.

Finally, GeeTest and GeeTestResultParser are added to handle
running the native tests. While TradeFed already has similar
classes, these two get around the limitations to work on user
builds and append the package name defined back as
LOCAL_CTS_TEST_PACKAGE. Integrating these changes back to the
TradeFed project will need to be done in a separate change.

A lot of this could have been done by adding more to buildCts.py,
but I didn't want to add to what is a single serial monolithic
step in the CTS build process. By having a separate rule to
handle each XML, make can take advantage of the cores on the
command line rather than sitting there on one core waiting
for the buildCts.py script to finish.

The CTS_TEST_CASES and CTS_TEST_XMLS are made more general to
handle copying any file type whether executable or APK to
the testcases directory. The XMLs could also be for native
packages or they could be for Java tests too. They are made
general on purpose so we do not need to modify
build/core/tasks/cts.mk everytime we add a new test type.
We just need to update CtsTestCaseList.mk without ever
having to do a multiproject change. Furthermore, this
generality allows us to easily convert over the existing
Java test cases.

Change-Id: I68f784bfedda5182b9795de2e6b2a5b7ed49626e

1 files changed, 1 insertions, 0 deletions

diff --git a/development/ide/eclipse/.classpath b/development/ide/eclipse/.classpath
index a38f53af1bd..30c63d82e14 100644
--- a/development/ide/eclipse/.classpath
+++ b/development/ide/eclipse/.classpath
@@ -58,6 +58,7 @@
     <classpathentry kind="src" path="cts/tests/tests/webkit/src"/>
     <classpathentry kind="src" path="cts/tests/tests/widget/src"/>
     <classpathentry kind="src" path="cts/tools/cts-api-coverage/src"/>
+    <classpathentry kind="src" path="cts/tools/cts-native-xml-generator/src"/>
     <classpathentry kind="src" path="cts/tools/cts-reference-app-lib/src"/>
     <classpathentry kind="src" path="cts/tools/dasm/src"/>
     <classpathentry kind="src" path="cts/tools/device-setup/TestDeviceSetup/src"/>