Full introduction to Android CTS all pass

Document directory

• Solution:
• Solution:
• Solution:

Android CTS! Goodbye fails! Goodbye timeout!

 

Why does the CTS test be performed on slave?

The android compatibility test (CTS) and the associated compatibility definition document (CDD) are self-management programs that ensure the compatibility of terminal devices with specific Android versions. The CTS test set contains about 24,000 test cases running on Android devices. These test cases are applicable to telephone, graphics, cameras, GPS, touch screen, wireless network, and other functions. Google released the CDD document for each major Android version, which specifies the specific requirements for each type of test in CTS. Using CTS testing is one of the prerequisites for accessing the Android software market. After the CTS test, the android trademark is allowed on the device, marking that the device is well compatible with hundreds of thousands of applications in the software market.

✓ FAQs and Solutions

I will not explain how to execute CTS here. What does-P mean? What does-t mean? I sum up that after executing cts_host> start -- Plan CTS, all those nutritious items that you want to pass.

 

❀ Testcase timeout

During the test of a testcase, "..." appears all the time. It is sad to see a bloody timeout for a long time. Many people think that timeout is good, at least it is not fail. In my opinion, timeout is worse than fail because it has no right to test whether it is pass or fail. If you want to avoid being laughed at by hardware equipment manufacturers, you must get 0 timeout and try again for 0 fail.

Most timeouts are caused by this error:

Exception in thread "thread-xx" com. Android. ddmlib. shellcommandunresponsiveexception

At com.android.ddmlib.adbhelper.exe cuteremotecommand (adbhelper. Java: 408)

At com.android.ddmlib.device.exe cuteshellcommand (device. Java: 276)

At com. Android. CTS. testdevice $ 1.run( testdevice. Java: 1718)

 

Solution:

This error is caused by inconsistent CTS and SDK versions. If this problem still persists when you use the Android 2.2 SDK and android2.2 Cts-R6, compile the SDK of your own project (after the overall m, then make the SDK) and associate it with the official CTS, you can solve this problem.

Note that do not use your project code to compile the CTS (make CTS), because it may not be the latest (usually the R1 version ). Google provides the latest version, and hardware equipment manufacturers trust the test results of the latest version of CTS.

 

 

Using restarting device... restarting ADB...

It is depressing to stop when the Board executes several tests.

 

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

Cts_info >>> restarting device...
Device (xxxxxxxxxxxxxxxxxxxxxx) disconnected
Test stopped.
Device (xxxxxxxxxxxxxxxxxxxxxx) connected

Solution:

In fact, restarting ADB and boards is normal. If you do not restart them, it will affect their normal operation. However, frequent restart affects productivity.

We can control the restart frequency during the test:

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 = "200" type = "codeph" text = "codeph"/>

5000 is a reasonable number for my test. If you do not run all the CTS items, if the number of test items is not large, you can change it to-1 to disable restart.

If the number is too large, restart the service. Otherwise, the ADB stops the test. Automated Testing, you won't keep staring at it, right?

 

Except java. Io. ioexception: sad result from ADB: Closed

If:

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. Tests. getinfo. deviceinfoinstrument on device 0 xxxxxxxxxxxx

Java. Io. ioexception: sad result from ADB: Closed

 

 

Solution:

Don't worry. Just restart the board.

 

 

Other fail

Because of the differences between various projects, fail items are different. Aside from the Fail determined by the hardware differences, there are also CTS fail bugs added by System Engineers to conceal other bugs. We also need to note that:

1. Net-related testcase. Remember to enable WiFi \ 3G to maintain network connectivity.

2. for SMS-related testcase, remember to insert SIM card

3. When the testcase of a device on I2C does not exist, try to disable other sensor services on I2C. A single test may lead to unexpected gains.

 

 

If you are still suffering from CTS fails, please contact us.

 

Author: yiyaaixuexi published on 1:56:07 Original article link reading: 1910 comments: 29 Views comments