tree c4e6b68da3b1a37109e1523d2cd76ee76183122a
parent 46c9ffe1ea86fb69a11c9a72ae406286b074acac
author Brian Muramatsu <btmura@google.com> 1325116017 -0800
committer Brian Muramatsu <btmura@google.com> 1325792580 -0800

Move Test XML Generation from buildCts.py

buildCts.py was the central script that generated all the
test package XMLs each time CTS was built. This had a
couple problems:

1. All the XML files for ~40 packages needed to be made
   every time CTS was made. Even if those packages were
   not touched at all.

2. Couldn't shard the XML generation process across the
   available cores on a machine. A pool was added to the
   python script, but it was set to a fixed number.

This change moves the test XML generation into a
smaller Java program called "cts-java-scanner" and
the doclet it relies upon to scan the Java files
into "cts-java-scanner-doclet.jar". The output of
the scanner like "cts-native-scanner" for native EXEs
is piped to the existing cts-xml-generator to
produce the test XMLs.

New CTS specific rules replace the standard
BUILD_PACKAGE and BUILD_HOST_JAVA_LIBRARY. They just
add extra rules for the package XML. The BUILD_CTS_PACKAGE
rule also adds a rule for copying the "package.apk"
to something more like "CtsFooTestCases.apk" to the
test case out directory. All the apks, exes, and xmls
are now thrown into a "cts-testcases" directory, before
they are copied to the final CTS distribution.

This change should prevent rebuilding the XMLs
unnecessarily and make rebuilding CTS quicker while
writing tests.

There are still the libcore tests that are always rebuilt,
but they can be adapted to fit into this model someday...

Change-Id: I52a916aa37fd679057e2709bb0ccec694c9fca01