ＣＴＳでFailが出たときの調査方法（その１）
今回は、CTS failについての調査方法に関して、記載いたします。
技術部 藤井洋祐 (twitterID:@i_m_yosuke)
なお、本内容を実施し、何らかの問題、損害などが発生した場合、当社は一切の責任を負いません。
あくまで自己責任で実施してください。
これらのことを認識頂いた上で、ご利用、参考にしてください。
１. CTSでFailがでたら
CTS実施中にfailが発生する場合があります。
主な原因としては、
・ターゲットデバイスの設定ミス
・Framework層の変更による影響
・ハードウェア不良
・CTS自身の不具合
があげられます。
1.1 fail内容を確認
failが出た場合、最初に行うことは、testResult.xmlを確認することから始めます。
result fail項目にFailure Details（英語のみ）が表示されます。
（下図のように表示されます。）
（図１．１）
1.1.1 fail要因調査(瞬殺編）
図1.1のFailure Detailesを確認したところ、内容から、このfailは、WiFiセッティングでアクセスポイント設定がされていないことが原因（ターゲットデバイスの設定ミス）と考えられます。
1.1.2 fail除去(瞬殺編）
このケースでのfailはすぐに除去できます。
WiFiアクセスポイント設定後、メソッド単位で再実施します。
passしました。testResult.xmlのfail情報は、この時点でpassとして、上書きされます。
確認のため、ブラウザでtestResult.xmlを読み込んでみました。
Note.
メソッド単位実行した場合、testResult.xmlの結果を上書きします。設定ミスなどで、少数のfail項目再確認
するには、メソッド単位でCTSを実行することをお勧めします。
クラス単位、パッケージ単位の実施は、未実行(No Executed)項目に関しては、実行しますが、fail項目は、
実行しません。
Note.
このように設定ミスでCTS failは、すぐに発生します。特にWiFi設定などは気をつけたほうがいいでしょう。
また、必要なAPKがデバイスにインストールされていない場合も、当然ながらfailになります。
２． fail要因調査(中級編）
前項のように、設定ミス等であった場合、即原因判明 → 即対応可能です。
しかし、そうでない場合もあります。最悪の場合、kernelまで調査することがあるとかないとか。
少し見にくいですが、上図を見ください。これは、たまたま出たのですが。。
「-1を期待しているところに。-16777216が返却されてきた」ということでしょうが、この段階で、筆者には何のことかわかりません。
２．１ fail発生箇所特定
まず、testResult.xmlをTextEditerで開き、stacktraceを見ます。
（図２．１）
TypefaceTest.java:208 というのが見えます。これは、「TypefaceTest.javaファイル208行目でfail検知しました。」ということです。 TypefaceTest.javaを見る必要があります。
使用しているCTSがAndroid 2.3 R5 ですので、Android Open Source Projectで、android-cts-2.3_r5
のタグから、repo syncでソースを取得します。
Note.
git cloneでcts.gitを取得しても特に問題はありません。Framework側のソースも必要になる事態を考慮し
ここではあえてrepo syncで取得することを前提とします。
２．２ fail発生箇所調査
下はTypefaceTest.java 208行目付近のソースです。
202 Bitmap expected = BitmapFactory.decodeResource( 203 getContext().getResources(), R.drawable.typeface_test, opt); 204 assertEquals(expected.getWidth(), bitmap.getWidth()); 205 assertEquals(expected.getHeight(), bitmap.getHeight()); 206 for (int y = 0; y < bitmap.getHeight(); y++) { 207 for (int x = 0; x < bitmap.getWidth(); x++) { 208 assertEquals(expected.getPixel(x, y), bitmap.getPixel(x, y)); 209 } 210 }リソースtypeface_testと何らかの方法で作成したbitmapとをpixel毎に等しいかチェックしています。
比較元データ（リソース）を見てみます。
framework/cts/tests/res/drawable/typeface_test.png
もう少し、TypefaceTest.javaを見てみます。（bitmap作成処理）
Typeface typeface = Typeface.createFromAsset(getContext().getAssets(), "samplefont.ttf"); assertNotNull(typeface); Bitmap bitmap = Bitmap.createBitmap(100, 100, Config.ARGB_8888); bitmap.eraseColor(Color.BLACK); Canvas canvas = new Canvas(bitmap); Paint p = new Paint(); p.setTypeface(typeface); p.setColor(Color.WHITE); p.setTextAlign(Paint.Align.CENTER); p.setTextSize(50); p.setFlags(0); // clear all flags (not sure what defaults flags are set) canvas.drawText("test", bitmap.getWidth() / 2, 3 * bitmap.getHeight() / 4 , p);
Note.
CTSソースは、framework/cts/tests/testsの下にパッケージ単位（当然ですが）で存在します。
failを検知（発生）させているソースは、failを出しているパッケージから、どこにあるかがわかります。
２．３ 解析
テストシナリオ（処理内容）の解析結果：
ARGB32bit作成した画像データとtypeface_test.pngをpixel単位で同一であるかをチェックしています。
参考： 作成したデータはサイズ100x100、背景黒、文字色白、ttf-font、
中央揃え、FontSize 50、文字列”test”で作られます。
エラー要因の解析結果：
期待値 -1（ARGB32bit Alpha 255, R 255, G 255,B 255 （白色））
に対して、
返却値 -16777216（ARGB32bit Alpha 255, R 0, G 0,B 0 （黒色））
であったためです。
※リソースでは白色である部分が、作成したデータでは黒色であったということになります。
２．４ 対応方法
当事例に関してまして、当方の対応方法を時系列で記載します。
あくまで例となりますが、参考にしてください。
1) AOSPで TypefaceTest.javaの最新コードをチェックします。
failを出している該当箇所に変更があれば、使用中のCTSコードに未反映ではありますが、
次回リリースのCTSに反映される可能性が高いということになり、
Google社が、そのfailは互換性という観点で問題は無いと、現在考えているということです。
よって、それ以上の調査は必要ないと判断可能です。
2) https://review.source.android.com/ にTypefaceTest.javaのsubmitがされていないか確認します。
verifyまでされていれば、merge待ちとなりますので、AOSPにいずれ反映される見込みです。
判断内容としては、1)と同じになります。
※rejectされていれば、framework側の調査が必要となります。
3) 1)、2)のどちらにも当てはまら無ければ、framework側の調査が必要となります。
当テストシナリオにおいては、Bitmapクラス、Colorクラスなどが使用されていますので、
使用されているクラスについても、1)、2)のように変更がされていないかの調査が必要です。
Note.
調査した結果、failがでた項目を削除したpatchがbranch gingerbreadに対してsubmitされ、
verify、mergedとなっておりました。（なぜか、CTS2.3R5には未反映ですが）
つまり、対応方法1)にあたります。
また、今回使用したターゲットデバイスは、Nexusシリーズでは無いためframework側の
ソースコード入手も不可能です。
よってこれ以上の深追いはしません。。。（出来ません）
以上です。
