【转】CTS tests 4.2_r4

时间:2024-12-24 08:35:32

原文网址:http://www.xuebuyuan.com/1722006.html

Precondition:

1.Get android sdk

2.Set adb to environment variable.

3.Download cts tool from google source

4.Download android-cts-media-1.0 to pc

Phone settings:

1. Open "USB debugging", "Stay awake" and "Allow mock locations"

2.Be sure adb devices connect successfully

3.Terminal execute

"adb install -r <cts_path>/android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk" and

"adb install -r <cts_path>/android-cts/repository/testcases/CtsDeviceAdmin.apk"

4.Open Wi-Fi and connect to a network, make sure you can access us network

5.Open Bluetooth

6.Open NFC(If your device not support NFC, skip this step)

7.Open “Google's location service”, “GPS satellites” and “Location & Google search

8.Settings → Security → Device administrators → Activate all options

9.Set language to English(United States), if your phone is not boot with english, please reboot phone after set language.

10.Set date and time correctly

11.OpenDelegating Accessibility Service in Accessibility

12.Terminal execute "cd <cts_media_path>/android-cts-media-1.0" -> execute ". copy_media.sh all"

Start to run:

1.Terminal execute "cd <cts_path>/android-cts/tools" -> execute "./cts-tradefed"

2.execute "run cts --plan CTS -s <serial_number>", finished

Fail的一些修改:

 

1、直接设置问题

estUnknownSourcesOffByDefault

fail

junit.framework.AssertionFailedError: Device should not ship with 'Unknown Sources' enabled by default. expected:<0> but
was:<1> at android.provider.cts.Settings_SecureTest.testUnknownSourcesOffByDefault(Settings_SecureTest.java:183)

这种fail最好解决,直接按照字面理解就OK,UnKnownSource没有点掉。

2、permission

-- testSensorFeatures

fail

junit.framework.AssertionFailedError: PackageManager#hasSystemFeature(android.hardware.sensor.accelerometer) returns true
but SensorManager#getSensorList(1) shows sensors [] expected:<true> but was:<false> at android.app.cts.SystemFeaturesTest.assertFeatureForSensor(SystemFeaturesTest.java:300)

一般情况修改 - >  frameworks/base/data/etc/*.xml 文件,例如
android.hardware.camera.xml,platform.xml等文件,这边的文件定义了设备具有的一些权限。

3、由测试而引起的非测试项出错

-- testRecordingHint

fail

java.lang.RuntimeException: start failed. at android.media.MediaRecorder.start(Native Method)

这种情况要根据Logcat去查看RuntimeException的具体错误。通常可以先不改,因为很难查错。

4、网络问题

-- test_isReachable

fail

java.net.UnknownHostException: Unable to resolve host "www.google.com": No address associated with hostname at java.net.InetAddress.lookupHostByName(InetAddress.java:426)

这类问题是由于国内的网络无法访问国外网站导致的,最好的办法就在公司搭建一个VPN,链接出去。

5、系统文件权限

-- testAllFilesInSysAreNotWritable

fail

junit.framework.AssertionFailedError: Found writable:

[/sys/devices/platform/malata_ts.0/tsclass/tsclass0/ts_power, /sys/devices/platform/malata_ts.0/tsclass/tsclass0/ts_en_file,
/sys/devices/platform/malata_ts.0/tsclass/tsclass0/ts_Calibrate] at android.permission.cts.FileSystemPermissionTest.

testAllFilesInSysAreNotWritable(FileSystemPermissionTest.java:364)

-- testNoSetuidTcpdump

fail

junit.framework.AssertionFailedError at

android.security.cts.BannedFilesTest.

assertNotSetugid(BannedFilesTest.java:59)

Rootcause: "OTHERS" users does not have "WRITE" permissions on any files under "/dev/" folder

这些问题是系统文件权限的问题,解决方法比较土,就是全局搜索该文件,查看那些对该文件操作的脚本,然后修改即可。

上面两个fail的解决方法是:

a.    修改kernel/drivers/input/touchscreen/malata_ts.c

__ATTR(ts_power, 0777, NULL, ts_set_point),

__ATTR(ts_en_file, 0777, NULL, ts_set_point),

__ATTR(ts_ Calibrate, 0777, NULL, ts_set_point),

b.    修改system/core/include/private/android-filesystem-config.h

{ 06755, ADD_ROOT, ADD_ROOT, “system/xbin/tcpdump”}

6、这种情况最多的。

-- testFocusDistances

fail

junit.framework.ComparisonFailure: expected:<infinity> but was:<auto> at

android.hardware.cts.CameraTest.testFocusDistancesByCamera

(CameraTest.java:1386)

对于这个fail的原因是CTS对摄像头测试时,对摄像头进行参数设置,然后在读取参数后,参数出错。

这种情况要找到CameraTest源码,通常在source/cts/...下面,我们编译时没有编译到这里,仅查看代码,例如找到CameraTest.java,打开后找到1386行,行数一般情况下不会有出入,除非source下面的cts版本和下载的cts版本不一致才会找不到,找到testFocusDistancesByCamera,然后根据代码查看具体的测试,然后在找camera的源代码,使用Log跟踪,当然这个测试一定要结合做该模块的人一起改才行,不然很容易引起其他问题。

其中camera CTS测试代码在:

source/cts/tests/tests/hardware/src/android/hardware/cts/CameraTest.java

摄像头设置的相关代码在:Source/device/Samsung/exynos4/libcamera/下面,有SecCameraHWInterface_zoom.cpp、SecCameraHWInterface_zoom.h、SecCamera_zoom.cpp、SecCamera_zoom.h

找到之后通过修改后测试再修改后再测试直到CTS PASS。

(对于摄像头,应注意是几个摄像头,不然测试可能会对两个一起测试,这样就算一个摄像头调好了,能PASS了,另外一个过不了也是FAIL的。)

7. [CTS]
2 cases failed by android.theme.cts.DeviceDefaultTest

这个cts测试的是Theme_DeviceDefault_dialogWhenLarge这个theme. 这个theme在large/xlarge screen时,显示为dialog; 在normal, small screen时,显示为full screen. 那个它是如何做到的呢?秘诀就是在values-large/xlarge中,把Theme_DeviceDefault_dialogWhenLarge定义为有固定尺寸的dialog
style. 而在values中,它确实普通的theme.holo style.

屏幕的大小是由screen的分辨率决定的:

longsize < 470dp  small screen

longsize >=960 && shortsize >=720   xlarge screen

longsize >=640
&& shortsize >=480   large screen

else normal screen.

那么又如何确定xlarge/large, 或者说指定类型的资源被编译到资源包中呢?

在*.mk中的PRODUCT_AAPT_CONFIG := mdpi【ldpi, hdpi, xhdpi, nodpi, tvdpi】 xlarge【large, normal, small】

ldpi= 120dpi

mdpi=160dpi

hdpi=240dpi

xhdpi=320

tvdpi=213

nodpi=all&noScale

Theme_DeviceDefault_DialogWhenLarge

8. 1 case failed by android.security.cts.ListeningPortsTest#testNoRemotelyAccessibleListeningTcpPorts

这个cts测试的是在user-release时的/proc/net/tcp/监听的端口。在user-release版本下,/proc/net/tcp/下的端口不应该被监听。

cat /proc/net/tcp/显示 监听的端口(16进制) 和inode 数

通过adb shell,  ls -l /proc/*/fd/ | grep -inr inode_number 来找到那个进程的fd在监听这个端口就可以解决了。

CPDD is gps issue.

cts_host > start --plan CTS -t android.net.cts.ListeningPortsTest#testNoListeningUdpPorts
start test android.net.cts.ListeningPortsTest#testNoListeningUdpPorts
==============================================================
Test package: android.net
android.net.cts.ListeningPortsTest#testNoListeningUdpPorts.............(fail)
android.net.cts.ListeningPortsTest$ListeningPortsAssertionError: Found port listening on 00000000:1C6B in /proc/net/udp at android.net.cts.ListeningPortsTest.assertNoListeningPorts(ListeningPortsTest.java:126)
at android.net.cts.ListeningPortsTest.assertNoListeningPorts(ListeningPortsTest.java:126)
at android.net.cts.ListeningPortsTest.assertNoListeningUdpPorts(ListeningPortsTest.java:78)
at android.net.cts.ListeningPortsTest.testNoListeningUdpPorts(ListeningPortsTest.java:63)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:529)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1448)
at android.net.cts.ListeningPortsTest.assertNoListeningPorts(ListeningPortsTest.java:126)
at android.net.cts.ListeningPortsTest.assertNoListeningUdpPorts(ListeningPortsTest.java:78)
at android.net.cts.ListeningPortsTest.testNoListeningUdpPorts(ListeningPortsTest.java:63)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:529)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1448) ==============================================================
and /proc/net/udp,  adb shell output is :
* daemon started successfully *
/# cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
107: 00000000:1C6B 00000000:0000 07 00000000:00000000 00:00000000 00000000 1000 0 4102 2 e0078000 0
#
and
# cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:13AD 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2981 1 dfa58000 300 0 0 2 -1
Converting the hex values to decimal, you get:

0x1C6B = 7275
0x13AD = 5037 The first CTS failure is because there is a remotely accessible UDP port listening on port 7275. This is a security risk. Remotely accessible ports are often used by attackers to gain unauthorized access to computers systems without user knowledge or awareness. Minimizing the number of open ports is considered a security best practice and required by CTS. Per the /proc/net/udp output above, this port is owned by UID=1000 (the "system" user). What do you have running under the system server that opens port 7275? The second /proc/net/tcp output is also problematic. In: # cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:13AD 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 2981 1 dfa58000 300 0 0 2 -1 There's a process, RUNNING AS ROOT, which is listening on the loopback (127.0.0.1) interface on port 5037. This process is thankfully NOT remotely accessible, but it is accessible to any program installed on the phone. In ICS, this listening port will be considered a CTS failure. Locally accessible ports are often targeted by malicious locally installed programs to gain unauthorized access to program data or cause system corruption. In all cases, a local listening IP port can be replaced by a UNIX domain socket. Unix domain sockets can be protected with unix filesystem permission. Alternatively, you can use getsockopt(SO_PEERCRED) to determine if a program is authorized to connect to your socket. While this isn't a failure today, I'd recommend switching to a UNIX domain socket as soon as practical.

7 [cts version]
android-cts_4.2_r4_x86.zip

[cts command]
1. run cts -c android.app.cts.SystemFeaturesTest -m testLocationFeatures

[Failure Details]
junit.framework.AssertionFailedError: PackageManager#hasSystemFeature should NOT return true for android.hardware.location.network at android.app.cts.SystemFeaturesTest.assertNotAvailable(SystemFeaturesTest.java:375)

8 cts
version]
android-cts_4.2_r4_x86.zip

[cts command]
1. run cts -c android.provider.cts.ContactsContract_ContactsTest -m testContentUri