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機器同樣無法通過該測試
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測試中已經去掉連接該網站的邏輯部分。
