1. 03 Dec, 2012 1 commit
    • Brett Chabot's avatar
      Add UiAutomator test skeleton to CTS. (manual merge from jb-dev) · 87f4451c
      Brett Chabot authored
      This change adds a new uiautomator test type to CTS. Includes makefile changes
      to generate the package XML, as well as a skeleton test app and test.
      
      Bug 7510316
      
      Change-Id: I32472f737537ff7f5ebe08cd85121793b29a9680
      
      Conflicts:
      
      	tools/cts-java-scanner/src/com/android/cts/javascanner/DocletRunner.java
      	tools/tradefed-host/src/com/android/cts/tradefed/testtype/TestPackageDef.java
      87f4451c
  2. 26 Nov, 2012 1 commit
    • Brett Chabot's avatar
      Add UiAutomator test skeleton to CTS. · 27f0ee2f
      Brett Chabot authored
      This change adds a new uiautomator test type to CTS. Includes makefile changes
      to generate the package XML, as well as a skeleton test app and test.
      
      Bug 7510316
      
      Change-Id: I32472f737537ff7f5ebe08cd85121793b29a9680
      27f0ee2f
  3. 02 Mar, 2012 1 commit
    • Brian Muramatsu's avatar
      Move CTS Build Definitions for mmm · e89e9740
      Brian Muramatsu authored
      Doing mmm cts/tests/tests/hardware woudn't work, because make
      didn't have BUILD_CTS_PACKAGE defined. Thus, move these core
      CTS rules to a separate file called cts/build/config.mk, so it
      can be included in the core build system. Finally, move the
      other CTS build rule files into the build directory for
      consistency as well.
      
      This should make everybody happy I think...
      
      Change-Id: I0792d0ba957ae31f79be0acbc9de8fc78e9374dc
      e89e9740
  4. 05 Jan, 2012 1 commit
    • Brian Muramatsu's avatar
      Move Test XML Generation from buildCts.py · 5df641c2
      Brian Muramatsu authored
      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
      5df641c2