Android CTS All pass Detailed

Android CTS! Goodbye fails! Goodbye Timeout!

Why the CTS test

The Android Compatibility Test (CTS) and the associated Compatibility definition document (CDD) are a self management program that ensures that terminal devices are compatible with specific versions of Android. The CTS test suite contains about 24,000 test cases that run on Android devices, which are designed for phones, graphics, cameras, GPS, touch screens, wireless networks, and so on. Google publishes the CDD documentation for each major Android version, which identifies specific requirements for each type of test in the CTS. Testing through CTS is one of the prerequisites for accessing the Android software market. The use of the Android logo on the device after the CTS test allows the device to be well compatible with the hundreds of thousands of applications in the software market.

FAQ and Solutions

I'm not here to write how to execute cts,-p. What does t mean, what I'm summing up is that after executing cts_host > Start--plan cts, I want all of those nutritious things.

TestCase Timeout

When testing a certain testcase "...", the delay did not pass or fail, and so long appeared a bloody timeout, very sad. A lot of people grinning to think timeout is very good, at least it is not fail. It seems to me that timeout is scarier than fail because it does not have the right to test whether it is pass or fail. Do not want to be hardware device manufacturers jokes, must be 0 timeout, and then fight for 0 fail.

Most of the timeout are caused by this error:

Exception in Thread "THREAD-XX" com.android.ddmlib.ShellCommandUnresponsiveException

At Com.android.ddmlib.AdbHelper.executeRemoteCommand (adbhelper.java:408)

At Com.android.ddmlib.Device.executeShellCommand (device.java:276)

At Com.android.cts.testdevice$1.run (testdevice.java:1718)

Solution:

This error is caused by a mismatch between the CTS and the SDK versions. If you use the android2.2 SDK and android2.2 CTS-R6 still have this problem, then compile their own engineering SDK (in the overall m, then make SDK), supporting the official CTS together, you can solve the problem hundred percent.

It is important to note that the CTS (make CTS), which is not compiled with your own engineering code, may not be compiled with the latest (usually R1 versions). While Google offers the latest, hardware vendors will trust the latest version of the CTS test results.

Restarting device ... Restarting ADB ...

The board performs several test items to stop and it's depressing.

Cts_info >>> Max ADB operations reached. Restarting ADB ...

Cts_info >>> Restarting device ...

Device (xxxxxxxxxxxxxxxxxxxxxx) disconnected

Test stopped.

Device (XXXXXXXXXXXXXXXXXXXXXX) connected

Solution:

In fact, restarting the ADB and the board is a normal phenomenon, if not restarted will affect their normal work. But this frequent restart, it is very affecting the efficiency.

We can control the frequency of reboots in the test:

To modify the reboots value in Android-cts/repository/host_config.xml:

<!--number of tests executed between reboots. A value <= 0 disables reboots. -->

<intvalue name= "Maxtestcount" value= "/>"

5000 is my test more reasonable number, if not run all the CTS 23,700 test, the number can be modified to-1, prohibit restart.

If the number is too large, it is good to reboot, otherwise the ADB will stop dead test. Automated testing, you're not going to keep staring at it, are you?

Java.io.IOException:sad result from adb:closed

If the midway appears:

Java.io.IOException:sad result from adb:closed

00:47 e/ddms:adb rejected Shell command (AM instrument-w-E bundle true Android.tests.devicesetup/android.tests.getinfo. deviceinfoinstrument): Closed

Cts_error >>> Failed to execute shell command am instrument-w-e bundle True android.tests.devicesetup/android.t Ests.getinfo.DeviceInfoInstrument on Device 0xxxxxxxxxxxx

Java.io.IOException:sad result from adb:closed

Solution:

Don't worry, just reboot the board.

Other fail

Because of the differences in each project, the fail item is different, the fail that is decided by the hardware difference, and the CTS fail bug that the system engineer has added to cover up the other bugs, we also need to note:

1.Net related testcase, remember to open WiFi 3G, maintain network Unicom

2.SMS related testcase, remember to insert SIM card

3. When the I2C of a device on the testcase did not, try to ban the I2C of other sensor services, a single test, there may be unexpected gains

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/