CTS4.0 fail

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測試：run cts –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部分  

Libcorects部分主要测试的是设备里面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测试中已经去掉连接该网站的逻辑部分。