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:要麼移植服務包,要麼disablesystemFeature。我暫時選擇後者。將/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部分主要測試的是設備裏面javaapi是否正常工作。當某部分異常的時候,cts對該項測試就會失敗。
根據實際的工作成果,得出一般libcore測試失敗大部分都跟你cts配置是否正確有關,而不是javaapi存在問題,比如測試之前是否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測試中已經去掉連接該網站的邏輯部分。