Android 4.0 CTS Debug

CTS簡介

      CTS是Android爲了確保眾多設備對軟件兼容性而進行的自動化測試，對設備無害。每個測試樣例都是用java語言以Junit測試規範寫的Android .apk文件。

 

CTS功用

對用戶來說，通過CTS的設備可以保證其對Android生態圈的軟件的兼容

對開發者來說，在開發前期CTS測試可以讓你最早發現開發板的不足與漏洞。另外通過CTS是廠商確定自己產品和軟件兼容性的保證

 

CTS 配置

1）.在 Android 官網上已經有執行 CTS 所需的操作。

http://source.android.com/compatibility/cts-intro.html

2） 除了官網外還要進行一些小設置

1. Erase SD card

2.factory reset ，沒有 recovery 的機器可以用 fastboot 重新刷 userdata.img cache.img 镜像達到 reset 目的。

3.Enable Adb 。

4.Wi-Fi 、 BT 打開，確保 WIFI 可以正常聯網，并能訪問 youtube.com 視頻

5.屏幕超時設置為 Never 或最長時間

6.Security---unknown resources 不选中

7.Screen Lock, 设置为 ‘None’

8.使用 usermode build 版本測試

 

CTS執行命令

cts配置完畢後，在CTS tools目錄下執行cts-tradefed脚本进入cts命令行

# ./cts-tradefed

Cts-tf >

Cts-tf >

执行命令run cts –- plan CTS即可運行CTS所有包測試。

常用的命令

單個包測試：run cts –p xxx[包]

單個testcase測試：runcts –c xxx[類]

單個測試項：run cts –c xxx[類]-m xxx [方法]

 

CTS常见bug

1.Android.app.cts.SystemFeaturesTest#testLocationFeatures

該項是測試設備利用無線網絡信號進行粗略定位的功能

Root Cause: 缺少 google 网络定位的服务包 NetworkLocation.apk ，但是机器用 getSystemFeature 依然有这项功能。

Solution ：要么移植服务包 , 要么 disable systemFeature 。我暂时选择后者。将 /framework/base/data/etc/ 目录下 xml 文件里面的所有 .” android.hardware.location.network ” 注释掉即通 过

 

2.Android.holo.cts.HoloTest 包

該項是測試設備显示的 widget view 是否跟他提供的图片相一致，精确到像素点。

Root Cause: 分辨率设置问题

Solution ：将修改 build.prop

ro.sf.lcd_density=160可以通过测试，但是Blaze Launcher菜单显示不能全屏，考虑修改api

 

3.Android.mediastress 包

該項是測試設備能否正常播放 google 提供的视频文件

Root Cause: 确定是否将 cts -media 包 copy 到 sdcard 目录、确定是否正常播放视频文件。 不能正常扫描播放，可能是视频驱动 问题

Solution ：将 cts -media 文件放到 sdcard , 检文件能正常扫描播放，测试通过。

 

4.Android.permissin.cts.DebugableTest#testNoDebuggable

该項是測試相应的 app 是否有 debugable 的标志

Root Cause:AndroidManifest 文件里面 android:debuggable =“true”

Solution ：将 android:debuggable =“true” 改为 false

 

5.Android.security.cts.PackageSignatureTest#testPackageSignatures

該項是測試应用包是否使用 google 默认的签名文件

Root Cause: 使用默认的签名编译 code

Solution ： build/target/product/security/ 下面的签名换成自己做的。做法在该目录下 README 有详细说明

 

Libcore cts部分

Libcore cts 部分主要测试的是设备里面 java api 是否正常工作。当某部分异常的时候， cts 对该项测试就会失败。

根据实际的工作成果，得出一般 libcore 测试失败大部分都跟你 cts 配置是否正确有关，而不是 java api 存在问题，比如测试之前是否 factory reset 就会影响其部分测试结果。所以在尝试各种方法无果后，进行一下 reset 可能它就能过。以下是我做过的一些 cts debug 项。

1.Libcore.java.text.dataFormateSymbolsTest

# test_getInstance_invalid_locale

Root Cause:

Solution ：执行 factory reset 后， pass

 

2.Libcore.java.text.SimpleDateFormateTest#testNonDstZoneNameWithDstTimestamp

Root Cause: 该测试失败原因是因为 java 的 SimpleDateFormate 类无法解析 Daylight time 夏令时区造成的

Solution ：追 api 无果下， factory reset 。 Daylight 时区正常解析， pass

 

3.Libcore.java.util.OldTimeZoneTest 包

Root Cause:java 无法解析 daylight 夏令时区造成

Solution ： factory reset

 

4.Org.apache.harmony.luny.tests.java.net.URLConnectionTest#test_getAllowUserInteraction

Root Cause:java 无法连接 onearth.jpl.nasa.gov 网站造成， nexus 机器同样无法通过该测试

Solution ：无解。 Google 在新版本的 cts 测试中已经去掉连接该网站的逻辑部分。

 

CTS推荐网站：http://code.google.com/p/android/issues/list，里面有全球的Android开发者在共同探讨问题，也有google Android项目成员出来解决问题。