a20bb011c2
the 2.3 CDD, and that needs to be filled in before launch, but the CDD isn't done yet. The link will be filled in before this is pushed to live, when the CDD is done. I want to get this submitted now so we can test & stage it. Change-Id: I80e36a5b37627583ce09c02be4ae6762005782a3
131 lines
5.1 KiB
Plaintext
131 lines
5.1 KiB
Plaintext
page.title=CTS Development
|
|
doc.type=compatibility
|
|
@jd:body
|
|
|
|
<h3>Initializing Your Repo Client</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/download.html">instructions</a>
|
|
to get and build the Android source code but specify "-b froyo"
|
|
when issuing the "repo init" command. This assures that your CTS
|
|
changes will be included in the next CTS release and beyond.</p>
|
|
|
|
<h3>Setting Up Eclipse</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/using-eclipse.html">instructions</a>
|
|
to setup Eclipse but execute the following command to generate the
|
|
.classpath file rather than copying the one from the development
|
|
project:</p>
|
|
|
|
<pre>
|
|
cd /path/to/android/root
|
|
./cts/development/ide/eclipse/genclasspath.sh > .classpath
|
|
chmod u+w .classpath
|
|
</pre>
|
|
|
|
<p>This .classpath file will contain both the Android framework
|
|
packages and the CTS packages.</p>
|
|
|
|
<h3>Building and Running CTS</h3>
|
|
|
|
<p>Execute the following commands to build CTS and start the interactive
|
|
CTS console:</p>
|
|
|
|
<pre>
|
|
cd /path/to/android/root
|
|
make cts
|
|
cts
|
|
</pre>
|
|
|
|
<p>Provide arguments to CTS to immediately start executing a test:</p>
|
|
|
|
<pre>
|
|
cts start --plan CTS -p android.os.cts.BuildVersionTest
|
|
</pre>
|
|
|
|
<h3>Writing CTS Tests</h3>
|
|
|
|
<p>CTS tests use JUnit and the Android testing APIs. Review the
|
|
<a href="http://d.android.com/guide/topics/testing/testing_android.html">Testing
|
|
and Instrumentation</a> tutorial while perusing the existing tests under the
|
|
"cts/tests/tests" directory. You will see that CTS tests mostly follow the same
|
|
conventions used in other Android tests.</p>
|
|
|
|
<p>Since CTS runs across many production devices, the tests must follow
|
|
these rules:</p>
|
|
|
|
<ul>
|
|
<li>Must take into account varying screen sizes, orientations, and
|
|
keyboard layouts.</li>
|
|
<li>Only use public API methods. In other words, avoid all classes,
|
|
methods, and fields that are annotated with the "hide" annotation.</li>
|
|
<li>Avoid relying upon particular view layouts or depend on the
|
|
dimensions of assets that may not be on some device.</li>
|
|
<li>Don't rely upon root privileges.</li>
|
|
</ul>
|
|
|
|
<h4>Test Naming and Location</h4>
|
|
|
|
<p>Most CTS test cases target a specific class in the Android API. These tests
|
|
have Java package names with a "cts" suffix like "android.view.cts" and class
|
|
names with the "Test" suffix like "ViewTest." Each test case consists of
|
|
multiple tests, where each test usually exercises a particular API method of
|
|
the API class being tested. Each test is annotated with a @TestTargetNew
|
|
annotation to indicate what API method is being exercised. These tests are
|
|
arranged in a directory structure where tests are grouped into different
|
|
categories like "widgets" and "views."</p>
|
|
|
|
<p>For example, the CTS test for "android.widget.TextView" is
|
|
"android.widget.cts.TextVietTest" found under the
|
|
"cts/tests/tests/widget/src/android/widget/cts" directory with its
|
|
Java package name as "android.widget.cts" and its class name as
|
|
"TextViewTest." The "TextViewTest" class has a test called "testSetText"
|
|
that exercises the "setText" method and a test named "testSetSingleLine" that
|
|
calls the "setSingleLine" method. Each of those tests have @TestTargetNew
|
|
annotations indicating what they cover.</p>
|
|
|
|
<p>Some CTS tests do not directly correspond to an API class but are placed in
|
|
the most related package possible. For instance, the CTS test,
|
|
"android.net.cts.ListeningPortsTest," is in the "android.net.cts," because it
|
|
is network related even though there is no "android.net.ListeningPorts" class.
|
|
Thus, use your best judgement when adding new tests and refer to other tests
|
|
as examples.</p>
|
|
|
|
<h4>New Test Packages</h4>
|
|
|
|
<p>When adding new tests, there may not be an existing directory to place your
|
|
test. In that case, refer to the example under "cts/tests/tests/example" and
|
|
create a new directory. Furthermore, make sure to add your new package's
|
|
module name from its Android.mk to "CTS_COVERAGE_TEST_CASE_LIST" in
|
|
"cts/CtsTestCaseList.mk." This Makefile is used by "build/core/tasks/cts.mk"
|
|
to glue all the tests together to create the final CTS package.</p>
|
|
|
|
<h4>Test Stubs and Utilities</h4>
|
|
|
|
<p>Some tests use additional infrastructure like separate activities
|
|
and various utilities to perform tests. These are located under the
|
|
"cts/tests/src" directory. These stubs aren't separated into separate test
|
|
APKs like the tests, so the "cts/tests/src" directory does not have additional
|
|
top level directories like "widget" or "view." Follow the same principle of
|
|
putting new classes into a package with a name that correlates to the purpose
|
|
of your new class. For instance, a stub activity used for testing OpenGL like
|
|
"GLSurfaceViewStubActivity" belongs in the "android.opengl.cts" package under
|
|
the "cts/tests/src/android/opengl" directory.</p>
|
|
|
|
<h3>Other Tasks</h3>
|
|
|
|
<p>Besides adding new tests there are other ways to contribute to CTS:</p>
|
|
|
|
<ul>
|
|
<li>Fix or remove tests annotated with BrokenTest and KnownFailure.</li>
|
|
</ul>
|
|
|
|
<h3>Submitting Your Changes</h3>
|
|
|
|
<p>Follow the
|
|
<a href="{@docRoot}source/submit-patches.html">Android
|
|
contributors' workflow</a> to contribute changes to CTS. A reviewer
|
|
will be assigned to your change, and your change should be reviewed shortly!</p>
|
|
|