編譯cts

⑴ linux中cts6.0 執行了24條其他都是未執行，為什麼

一、android的CTS測試，英文為Compatibility Test Suite，意為兼容性測試。只有通過CTS測試的設備才有可能獲得Android的商標和享受Android Market的許可權；Android的CTS目的與意義：用戶在android系統中有更好的用戶體驗，並且展示android應用的優越性，使得android開發者更容易編寫高質量的andorid程序。
二、CTS是兼容性測試,Google為了防止廠商對Android的改動影響其SDKAPI的兼容性,即第三方應用程序安裝到該廠商的機器上都能正常運行；這個差不多是自動跑的，會測試硬
件（比如GPS,WIFI），還有其他一系列的東西，跑完之後會出一份詳細的報告，告訴你哪些地方沒通過。
三、我們實際使用CTS的過程中，很可能需要根據特定的要求，來定製自己的TestPlan。這時就需要自己編譯CTS

⑵ 如何進行android兼容性測試cts

二、運行CTS的方法，步驟如下：
（1）進入目錄android-cts，該目錄是通過上面那兩種方法獲得的。在android-cts目錄下會有3個文件夾，其中一個是tools。
（2）進入tools目錄，輸入./startcts來啟動CTS。
（3）如果運行成功會出現Android CTS version 2.3_r1的字樣（我的android的版本是2.3的）。如果有連接設備到PC上還會出現Device(設備ID)connected的字樣。這里設備可以是連接PC的android的機器，也可以是模擬器。
三、CTS測試的方法：
（1）在cts_host>下敲入help，會顯示cts下的許多命令。ls –plan命令顯示google自帶的測試方案，如：java、Signature、Android、CTS、VM、RefApp、Performance、AppSecurity。其中Performance這個方案是google暫不要求的。Java、Signature、Android、VM、RefApp、Appsecurity方案都是CTS方案的子集。
（2）用命令ls -d來查看已連接的設備，CTS測試之前我們必須保證至少有一個設備連接上。
（3）輸入命令start –plan CTS來執行CTS測試方案，該方案有兩萬多條測試項目，需要很長時間，因此除了第一次測試之外，不建議這么做。我做的都是針對某些包的測試。如果連接了多個設備的話需加上-d參數，後面跟上設備id來告訴CTS需要測試的設備。
（4）對單獨一個包進行測試的方法：start –plan CTS –p 包名；推薦用這種方法來進行針對性的測試。需要知道有哪些包名，可以輸入命令：ls –plan CTS
（5）也可以針對單獨一個case進行測試：start –plan CTS –test 類名#方法名
四、查看測試的結果：
測試生成的log在\android-cts\repository目錄下以log+測試時間.txt命名。測試報告在android-cts\repository\results目錄下，也是以測試時間命名。
五、注意事項：
（1）測試前需要安裝一個apk：adb install -r android-cts/repository/testcases/.apk 然後在設置裡面

⑶ 如何判斷 cts android

CTS是什麼？
資料：CDD、CTS官網、android-cts-manual-r4；
CTS是什麼我就不多費話了，看上面官方的說法就行了。不過有一點需要明確，你的設備只有滿足CDD的規定並且通過CTS，才有可能獲得Android的商標和享受Android Market的許可權。這里有可能指的是需要你自己去向google申請的，不是說兼容了，這些東西就自然而然有了。

怎麼用：
資料： android-cts-manual-r4、宋立新_Android CTS測試研究；
安裝與配置：
下載或自己編譯；修改startcts中SDK_ROOT；在板子或emulator上裝一個apk；設置setting；
各種命令的用法：
注意：start --plan –p以及start --plan –t的用法，-t要指定一個具體的測試方法
方法1：一般使用的方法
$ ./startcts 注意如果用手機設備調試，用root許可權執行
cts_host > ls --plan 列出所有plan
out/host/linux-x86/cts/android-cts/repository/plans中有plan的具體內容
cts_host > start --plan VM 運行某個plan
測試結果在out/host/linux-x86/cts/android-cts/repository/results目錄下，用瀏覽器看時間目錄下的xml文件即可
注意在改動cts後，還要make cts重新編譯，若只在cts目錄中編譯不能生效
cts_host > ls -p 看當前可用的用例包
cts_host > start --plan Android -p android.app 只運行某個用例包，節約時間
cts_host > start --plan Android -p android.app -t android.app.cts.AlertDialogTest#testAlertDialog
只運行某個用例包中的某個用例
方法2：遇到問題時方便調試的方法
$ adb install out/target/proct/xxxx/data/app/SginatureTest.apk 安裝某個用例包
$ adb shell pm list instrumentation pm用於管理package，看當前機器安裝了什麼用例
$ adb shell am instrument -w android.tests.sigtest/.InstrumentationRunner am用於管理activity 運行某一用例
$ adb shell am instrument -e class android.app.cts.AlertDialogTest#testAlertDialog -w com.android.cts.app/android.test/InstrumentationCtsTestRunner 單獨運行一個小case
如果在一個時間很長的plan（如Android）中，某處錯了，而錯誤信息又不全，需要單獨跑一個小case，用-e指明class明就可以節約很多時間

用完後結果的分析：
結果在repository/results中，放在一個文件夾里，名字是你測試開始的時間。
分析的方法有兩種：
1、可以直接從Failure Details找原因；（個人感覺應該難度較大）
2、結合源代碼以及Failure Details的信息找原因
第二種方法牽扯到找測試源代碼的問題，這就要對CTS源碼目錄以及相應生成物的命名有一定的了解。

了解CTS這個工程：
資料：宋立新同學的Android CTS測試研究二、android build system、CTS源碼、makefile以及shell基本知識
了解Linux工程最好的入手點，就是從它的編譯系統入手。
這個涉及到Linux的makefile以及android的編譯系統的基本知識，具體內容還是挺多的，不過看懂了android編譯系統，以後看其他Android工程應該都會得心應手。

在android CTS上增加自己的test package
資料：CTS命令的用法、Erin Yueh的兩篇文章
有兩種方法：
1、完美利用自帶命令(已驗證)
2、用Erin Yueh的方法
用這個方法的前提也是要徹底弄懂CTS的內部結構，不然也只能照貓畫虎

如何寫test case
資料：JUnit、SDK/docs下面的五篇文章、android open source官網/porting/Instrumentation Testing
這又是另外一門學問了
這個test case 可以涉及各個層次，Android 平台相關的測試的寫法可以參考官方的那五篇文章，如何運行可參考上面資料三，其他的可能會涉及到JUnit以及其他一些知識，目前還沒實地考察。

接下來要弄明白的
1、android的編譯系統（學習下makefile以及shell基本知識）
2、CTS這個工程（看看測試包XML生成器的假設成不成立，能不能提取出來）
3、眾多層次test case 的寫法

⑷ 編譯android2.2時出現內存溢出！main javac dalvik-cts-builtil build step failed

因為沒有指針操作，java裡面的溢出一般是數組訪問越界。
沒有代碼，沒法幫你找。
最好在每次用index訪問數組時，判斷一下index不要大於數組的size-1

⑸ 計算機術語"CTS伺服器"是什麼意思

RTS和CTS用於硬體流控 很久很久以前，計算機還沒有出現，那時就已經存在了(計算機)史前的串口設備(電傳打字機，工控測量設備，通信數據機)，為了連接這些串口， EIA制定了RS232標准，採用DB25接插件，支持同步和非同步串口，D型的介面可以有效防止插反。標准化給使用帶來了便利。 時光荏苒，個人計算機出現了，這些已有的串口設備毫無疑問地成為了最初的外設，自然而然地RS232標准被個人計算機採納。但是設備製造商傾向於體積更小，成本更低的介面，因此，將DB25中未使用的和支持同步模式的引腳去掉，形成DB9。最初的情況相當混亂，因為DB9隻定義了信號，卻沒有指定信號和引腳的對應關系，各個製造商只能自行定義。幸運的是，IBM的PC成了工業標准，DB9逐漸統一到IBM的定義上來。 DB9隻有9根線，遵循RS232標准。定義如下： DTR,DSR------DTE設備准備好/DCE設備准備好。主流控信號。 RTS,CTS------請求發送/清除發送。用於半雙工時，收發切換。屬於輔助流控信號。半雙工的意思是說，發的時候不收，收的時候不發。那麼怎麼區分收發呢？預設時是DCE向DTE發送數據，當DTE決定向DCE發數據時，先有效RTS，表示DTE希望向DCE發送，一般DCE不能馬上轉換收發狀態，DTE就通過監測CTS是否有效來判斷可否發送，這樣避免了DTE在DCE未准備好時發送所導致的數據丟失。 全雙工時，這兩個信號一直有效即可。 隨著計算機的日益普及，很多非RS232的串口也要接入PC機，如果為每一種新出現的串口都增加一個新的I/O口顯然不現實，因為PC後面板位置有限，因此，將RS232串口和非RS232串口都通過RS232口接入是最佳方案。UART的U(通用)指的就是這個意思。早期ROM BIOS和DOS里的通信軟體都是為RS232設計的，在沒有檢測到DCD有效前不會發送數據，因此，就連發送一個字元這樣樸素的應用也要給出DCD、DTR、DSR等控制信號。因此，串口接頭上要將一些控制線短接，或者乾脆繞過系統軟體自己寫通信程序。 到此，UART的涵義就總結為：通用的 非同步 (串列) I/O口。 就在UART冠以通用二字，准備一統江湖的時候，製造商們不滿於它的速度、體積和靈活性(軟體可配置)，推出了USB和1394串口。目前，筆記本上的 UART串口有被取消的趨勢，因而有網友發出了「沒有串口，吾誰與歸」的慨嘆，古今多少事，都付笑談中，USB取代UART是後話，暫且不表。 話說自從賀氏(Hayes)公司推出了聰明貓(SmartModem)，他們制定的MODEM介面就成了業界標准，自此以後，所有公司製造的兼容貓都符合賀氏標准(連AT指令也兼容，大家一起抄他唄)。 細觀賀氏制定的MODEM串口，與RS232標准大不相同。DTR在整個通信過程中一直保持有效，DSR在MODEM上電後/可以撥號前有效(取決於軟體對DSR的理解)，在通信過程的任意時刻，只要DTR/DSR無效，通信過程立即終止。在某種意義上，這也可以算是流控，但肯定不是RS232所指的那種主流控。如果拘泥於RS232，你是不會理解DTR和DSR的用途的。 賀氏不但改了DTR和DSR，竟然連RTS和CTS的涵義也重新定義了。因此，RTS和CTS已經不具有最開始的意義了。從字面理解RTS和CTS，是用於半雙工通信的，當DTE想從收模式改為發模式時，就有效RTS請求發送，DCE收到RTS請求後不能立即完成轉換，需要一段時間，然後有效CTS通知DTE：DCE已經轉到發模式，DTE可以開始發送了。在全雙工時，RTS和CTS都預設置為有效即可。然而，在賀氏的MODEM串口定義中，RTS和CTS用於硬體流控，和什麼勞什子的全雙工/半雙工一點關系也沒有。 注意，硬體流控是靠軟體實現的，之所以強調「硬體」二字，僅僅是因為硬體流控提供了用於流量情況指示的硬體連線，並不是說，你只要把線連上，硬體就能自己流控。如果軟體不支持，光連上RTS和CTS是沒有用的。 RTS和CTS硬體流控的軟體演算法如下：(RTS有效表示PC機可以收，CTS有效表示MODEM可以收，這兩個信號互相獨立，分別指示一個方向的流量情況。) dengm 發表於 2005-1-14 07:52 侃單片機 PC端處理： 發. 當 發現（不一定及時發現） CTS (-3v to -15v)無效時，停止發送, 當 發現（不一定及時發現） CTS (3v to 15v)有效時，恢復發送； 收. 0<M<N<LEN_OF_RX_BUFFERS 當接收buffers中的bytes<M 時，給 RTS 有效信號（+3v to +15v), 當接收buffers中的bytes>N 時，給 RTS 無效信號（-3v to -15v); MODEM端處理： 同上，但RTS與CTS交換。 你迷惑的原因是因為你學習的是RS232標准，卻使用賀氏標準的貓，兩個標准風馬牛不相及。
編輯本段公共類型系統
CTS：公共類型系統（又叫通用系統類型） Common Type System .net framework 類似於COM定義的標准二進制格式，.NET定義了一個稱為通用類型系統Common Type System(CTS)的類型標准。這個類型系統不但實現了COM的變數兼容類型，而且還定義了通過用戶自定義類型的方式來進行類型擴展。任何以.NET平台作為目標的語言必須建立它的數據類型與CTS的類型間的映射。所有.NET語言共享這一類型系統，實現它們之間無縫的互操作。該方案還提供了語言之間的繼承性。所有CTS對象的類型都最終都從System.Object類派生，這些類型分為 值類型和引用類型。 換句話說，CTS定義了可以在中間語言中使用的預定義數據類型，所有面向.NET Framework的語言都可以生產最終基於這些類型的編譯代碼。CTS不僅定義了基本數據類型，還定義了一個內容豐富的類型層次結構，在這些位置上，代碼允許定義他自己的類型。CTS的層次結構反應了中間語言的單一繼承的面向對象的方法。 很顯然，編程語言的區別不僅僅在於類型。例如，一些語言支持多繼承性，一些語言支持無符號數據類型，一些語言支持運算符重載。

⑹ c#中CLS和CTS的關聯，作用和概念怎麼理解

CTS是一個大規則, CLS是大規則下一個小規則:

CTS(Common type system)
就是CLR能夠支持所有的功能!用集合說是一個全集.
每種託管語言只能實現其中的一部分
比如
CLR中能夠定義 "Family 與 Assembly" 的限定和 "Family 或 Assembly"的限定,
但是C#卻不行,只能定義"或"關系 (Protected internal 這樣定義是兩者"或"關系)

CLS(Common Language Specification)
是所有語言都可以遵守的規則!用集合來說是多個語言規則的交集!
每個語言都能夠做到,但是可以不遵守.
比如說CLS中說方法名是不分大小寫的,Abc(),ABC是一樣的
VB中是這樣,但是C#中卻認為這兩個方法不一樣.
如果用VB去調用C#中Abc()方法可能就會出項混亂(不知道是Abc還是ABC)
因此如果大家都遵守CLS,那麼多語言間的交互成為可能.
在C#中,我們可以通過[assembly:CLSCompliant(true)]特性來檢驗程序語言對CLS的兼容性

⑺ android產品上市必須通過CTS認證測試嗎

是的，一定要通過CTS認證測試

Android的CTS測試，英文為Compatibility Test Suite，意為兼容性測試。只有通過CTS測試的設備才有可能獲得Android的商標和享受Android Market的許可權。以下分享我對Android CTS的認識。
一、取得Compatibility Test Suite的兩種方法：
（1）可以從http://source.android.com/compatibility/downloads.html下載最新版本的Compatibility Test Suit；
（2）也可以通過編譯Android源代碼的方式獲得。在android源代碼目錄下輸入make cts命令來編譯CTS，之後會在out/host/linux-x86/cts/下生成android-cts文件夾。這個文件夾就是Compatibility Test Suit。
==========================================
1、Error occurred ring initialization of VM
Could not reserve enough space for object heap
從字面上看是在初始化java Vm的時候不能獲取足夠的堆空間，於是修改了build/core/definition.mk文件中的編譯core.jar和framework.jar時需要的-JXmx為1024m，此參數代表編譯上述兩個包時需要的最大內存，此初始值為2048M，由於我的PC電腦總的內存才2G，系統運行會占據一部分內存，故編譯android的時候肯定不會分配2G內存，
解決：
把build/core/definitions.mk 文件
第1528行:$(if $(findstring windows,$(HOST_OS)),,-JXms16M -JXmx2048M) \
改成： $(if $(findstring windows,$(HOST_OS)),,-JXms16M -JXmx1024M) \
http://blog.csdn.net/leerobin83/article/details/7873229
==========================================
二、運行CTS的方法，步驟如下：
（1）進入目錄android-cts，該目錄是通過上面那兩種方法獲得的。在android-cts目錄下會有3個文件夾，其中一個是tools。
（2）進入tools目錄，輸入./startcts來啟動CTS。
（3）如果運行成功會出現Android CTS version 2.3_r1的字樣（我的android的版本是2.3的）。如果有連接設備到PC上還會出現Device(設備ID)connected的字樣。這里設備可以是連接PC的android的機器，也可以是模擬器。
三、CTS測試的方法：
（1）在cts_host>下敲入help，會顯示cts下的許多命令。ls –plan命令顯示google自帶的測試方案，如：Java、Signature、Android、CTS、VM、RefApp、Performance、AppSecurity。其中Performance這個方案是google暫不要求的。Java、Signature、Android、VM、RefApp、Appsecurity方案都是CTS方案的子集。
（2）用命令ls -d來查看已連接的設備，CTS測試之前我們必須保證至少有一個設備連接上。
（3）輸入命令start –plan CTS來執行CTS測試方案，該方案有兩萬多條測試項目，需要很長時間，因此除了第一次測試之外，不建議這么做。我做的都是針對某些包的測試。如果連接了多個設備的話需加上-d參數，後面跟上設備id來告訴CTS需要測試的設備。
（4）對單獨一個包進行測試的方法：start –plan CTS –p 包名；推薦用這種方法來進行針對性的測試。需要知道有哪些包名，可以輸入命令：ls –plan CTS
（5）也可以針對單獨一個case進行測試：start –plan CTS –test 類名#方法名
四、查看測試的結果：
測試生成的log在\android-cts\repository目錄下以log+測試時間.txt命名。測試報告在android-cts\repository\results目錄下，也是以測試時間命名。
五、注意事項：
（1）測試前需要安裝一個apk：adb install -r android-cts/repository/testcases/.apk 然後在設置裡面的輔助功能中會多一個Delegating Accessibility Service選項，將這個選項勾起。
（2）在android設備設置中：顯示->屏幕超時->選取30分鍾
（3）在android設備設置中：應用程序->開發->勾選保持喚醒狀態。
（4）保證測試前，android設備在主界面狀態。
（5）將android設備的語言設置為英文

⑻ android cts如何到另一台電腦繼續測試

Android 4.0 CTS 測試方法
這段時間公司做CTS測試，下面是一些總結，以android4.0.3為例，希望對大家有所幫助！
一 CTS測試簡介
The Android compatibility program makes it easy for mobile device manufacturers to develop compatible Android devices
CTS具體的介紹，大家可以參考google的官方網站，大家可以詳細的了解CTS測試的目的和環境，我們一般的疑惑都能在該網站上找到答案。

1.1為什麼需要兼容性測試（以下稱CTS）？
1.1.1、讓APP提供更好的用戶體驗。用戶可以選擇更多的適合自己設備的APP。讓APP更穩定。
1.1.2、讓開發者設計更高質量的APP。
1.1.3、通過CTS的設備可以運行Android market。
1.2怎麼樣才能讓我的設備變成兼容的。

1.2.1、與Android Compatibility Definition文檔（以下簡稱ACD）匹配
先看一下與你的系統版本相匹配的ACD，文檔中描述了你需要具備的軟體和硬體參數。
1.2.2、通過CTS測試
CTS是開源的測試框架，使用它來測試你的設備是否具備兼容性。
1.2.3、提交報告
你可以把測試結果發送給[email protected]。當你提交了一個CTS報告時，你還可以要求訪問Android Market。
如果是google的合作夥伴，需要將CTS測試報告、機器、以及軟體一共寄給google進行測試，取得google的approval以後，手機才能上市，這是後話，相信好多人都是用不到的。
1.3 CTS測試原理

CTS主要包含兩個組件：
運行在PC上的測試框架組件。主要用來管理測試用例（test case）的執行。
運行在設備或模擬器上的測試用例。這些用例用JAVA寫成的APK文件。
1.4工作流程
1）可以從源碼編譯CTS，也可以從網站下載編譯好的CTS

2）安裝配置CTS。
3）把設備連接到PC上。
4）運行CTS。CTS會把相應的測試用例（也就是一個APK文件）傳送到設備上並通過instrumentation運行，然後記錄運行結果，最後刪除測試用例。
所有的測試用例執行完畢後，可以參照測試結果重新調整或優化系統。然後繼續運行CTS測試。
1.5、測試通過以後，你可以把CTS生成的結果（就是result下面那個以測一、取得Compatibility Test Suite的兩種方法：
（1）可以從 下載最新版本的Compatibility Test Suit；
（2）也可以通過編譯Android源代碼的方式獲得。在android源代碼目錄下輸入make cts命令來編譯CTS，之後會在out/host/linux-x86/cts/下生成android-cts文件夾。這個文件夾就是Compatibility Test Suit。
注意：但是源碼中的代碼可能不是最新的，所以建議沖網站上下載最新的，需要用git在google的網站上下載，網上有好多例子，這里就不再重復了。
二 測試用例的范圍
1、Signature
對每個Android產品，都有一些XML文件來描述所有的公開API。CTS包含了一個工具來檢測這些API簽名中包含的API是否都在系統中被支持。
2、Platform
測試SDK文檔中描述的平台API，比如core libraries,Android Application Framework等。要求這些API可以提供：
正確的類、屬性、方法簽名、方法行為、錯誤參數處理方式
3、Dalvik VM
專門針對Dalvik Vm的測試。
4、Platform Data Model
平台通過ContentProvider提供給開發者使用的數據，比如：Contacts,Browser,Settings等。
5、Platform Intents
平台提供的用於核心功能的Intent。
6、Platform permission
平台提供的一些重要APP許可權
7、Platform Resources
simple values,drawables,nine-patch,animations,layouts,styles and themes，loading alternate resources等

三 如何搭配環境
目前cts沒有提供windows版本，只能在Linux下測試。
1 PC機配置環境
PC端網上有好多資料可以供參考，這里就省略了。
2 手機設置
1) 進入settings->Privacy->Factorydata reset，對平台進行reset一次
2) 平台插入一張空的TF卡
3) 平台安裝兩個APK：.apk，CtsDeviceAdmin.apk
4) 進入settings打開Wi-Fi並連接AP (AP需要連外網)
5) 進入settings->Security->Screenlock設為None
6) 進入settings->Security->EnableUnknown sources
7) 進入settings->Security->Deviceadministrators->Enable兩個選項
8) 進入Language&input->language設為English(UnitedStates)
9) 進入settings->Display->Sleep設為30minutes或None
10) 進入settings->Accessibility->EnableDelegating Accessibility Service
11) 進入settings->Developeroptions->Enable USB debugging、Stay awake、Allowmock locations
12) PC上「android-cts-media-1.0」，在android-cts-media-1.0文件下輸入./__media.sh運行腳本，將media文件進平台。成功後會在平台的內存中看到test文件夾。(此條適用於CTS4.0 R2和R3，R1上無需使用）

四 測試方法
1.平台用USB線連接LinuxPC （連通後平台左上方會顯示usb和debug icon）
2.打開終端
3.輸入sudosu -
輸入root密碼
4.輸入cd ../..
輸入 cd /home/linux/cts/android-cts-4.0.3_r1-linux_x86-arm/android-cts/tools (這個是cts-tradefed文件所在路徑，各位需要輸入實際路徑)
輸入 ./cts-tradefed
終端顯示 01-16 15:44:05 I/DeviceManager: Detected newdevice 0123456789ABCDEF(如果沒有這行，說明設備沒有和PC聯通）
Android CTS 4.0.3_r1
cts-tf >

5.輸入run cts --plan CTS
終端顯示 cts-tf > run cts --plan CTS

cts-tf> 01-16 15:45:34 I/TestInvocation: Starting invocation for 'cts' on build'4.0.3_r1' on device 0123456789ABCDEF
01-16 15:45:35I/0123456789ABCDEF: Created result dir 2012.01.16_15.45.34

開始測試CTS
五 關於CTS4.0測試報告

1.CTS測試報告是自動生成一個xml報表，並自動填寫的，不需要測試人員干預

2.當一個CTS測試任務開始時，會在android-cts-4.0.3_r1-linux_x86-arm/android-cts/repository/results中，為這個任務建立一個存放測試報告的文件夾，文件名以任務開始的日期和時間命名。

例如：2012.01.12_13.00.03

3.CTS4.0生成測試報告的速度比CTS2.3/2.2要慢不少，特別是在測試過程中中斷測試，CTS4.0需要70秒才會開始生成報告。如果你在此過程中按ctrl+c終止CTS進程，測試報告就無法生成，以後也無法繼續測試未完成的計劃。

下方是中途斷開後生成報告的例子：

01-1813:50:19I/0123456789ABCDEF: android.accounts.cts.AccountManagerTest#testHasFeature FAIL

Testfailed to run to completion. Reason: 'Test run failed to complete. Expected 1tests, received 0'. Check device logcat for details

01-1813:51:29I/0123456789ABCDEF: android.accounts package complete: Passed 20, Failed 2, NotExecuted 6

01-1813:51:29 I/0123456789ABCDEF: -----------------------------------------

01-1813:51:29 I/0123456789ABCDEF: Test package android.admin started

01-1813:51:29 I/0123456789ABCDEF: -----------------------------------------

……

01-1813:51:30 I/0123456789ABCDEF: -----------------------------------------

01-1813:51:30 I/0123456789ABCDEF: Test package android.widget started

01-1813:51:30 I/0123456789ABCDEF: -----------------------------------------

01-1813:51:30 I/0123456789ABCDEF: Saved log device_logcat_8558243668624894128.zip

01-1813:51:30 I/0123456789ABCDEF: Saved log host_log_6087775957743010530.zip

⑼ C#中IL/MSIL,CTS,CLS,CLR,JIT分別是什麼!

IL/MSIL (Microsoft Intermediate Language) 微軟中間語言 （IL是MSIL的縮寫，譯為中間語言）CTS (Common Type System)通用類型系統CLS (Common Language Specification)公共語言規范CLR (Common Language Runtime)公共語言運行時（也有的叫公共語言運行庫）JIT (Just in time)即時編譯器

⑽ 如何編譯出ctsverifier.apk

Android 4.0 CTS 測試方法 這段時間公司做CTS測試，下面是一些總結，以android4.0.3為例，希望對大家有所幫助！ 一 CTS測試簡介 The Android compatibility program makes it easy for mobile device manufacturers to develop compatible Andro.