2011年9月9日金曜日

CTSでFailが出たときの調査方法(その1)



 今回は、CTS failについての調査方法に関して、記載いたします。


技術部 藤井洋祐 (twitterID:@i_m_yosuke)


なお、本内容を実施し、何らかの問題、損害などが発生した場合、当社は一切の責任を負いません。
あくまで自己責任で実施してください。
これらのことを認識頂いた上で、ご利用、参考にしてください。



1. CTSでFailがでたら


CTS実施中にfailが発生する場合があります。


  主な原因としては、


  ・ターゲットデバイスの設定ミス


  ・Framework層の変更による影響


  ・ハードウェア不良


  ・CTS自身の不具合


  があげられます。






 1.1 fail内容を確認


  failが出た場合、最初に行うことは、testResult.xmlを確認することから始めます。


  result fail項目にFailure Details(英語のみ)が表示されます。


  (下図のように表示されます。)


f:id:bs-android:20110907093249p:image


    (図1.1)




  1.1.1 fail要因調査(瞬殺編)


   図1.1のFailure Detailesを確認したところ、内容から、このfailは、WiFiセッティングでアクセスポイント設定がされていないことが原因(ターゲットデバイスの設定ミス)と考えられます。






  1.1.2 fail除去(瞬殺編)


  このケースでのfailはすぐに除去できます。


  WiFiアクセスポイント設定後、メソッド単位で再実施します。


f:id:bs-android:20110907093836p:image:w640




   passしました。testResult.xmlのfail情報は、この時点でpassとして、上書きされます。


   確認のため、ブラウザでtestResult.xmlを読み込んでみました。


f:id:bs-android:20110907094745p:image




  Note.


  メソッド単位実行した場合、testResult.xmlの結果を上書きします。設定ミスなどで、少数のfail項目再確認


  するには、メソッド単位でCTSを実行することをお勧めします。


  クラス単位、パッケージ単位の実施は、未実行(No Executed)項目に関しては、実行しますが、fail項目は、


  実行しません。




  Note.


  このように設定ミスでCTS failは、すぐに発生します。特にWiFi設定などは気をつけたほうがいいでしょう。


  また、必要なAPKがデバイスにインストールされていない場合も、当然ながらfailになります。






2. fail要因調査(中級編)


  前項のように、設定ミス等であった場合、即原因判明 → 即対応可能です。


  しかし、そうでない場合もあります。最悪の場合、kernelまで調査することがあるとかないとか。




f:id:bs-android:20110907095341p:image


 少し見にくいですが、上図を見ください。これは、たまたま出たのですが。。


 「-1を期待しているところに。-16777216が返却されてきた」ということでしょうが、この段階で、筆者には何のことかわかりません。






2.1 fail発生箇所特定


 まず、testResult.xmlをTextEditerで開き、stacktraceを見ます。


f:id:bs-android:20110907095342p:image


  (図2.1)




  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で取得することを前提とします。 






2.2 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


f:id:bs-android:20110907100748p:image






  もう少し、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を出しているパッケージから、どこにあるかがわかります。






 2.3 解析




  テストシナリオ(処理内容)の解析結果:


   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 (黒色))


   であったためです。


  ※リソースでは白色である部分が、作成したデータでは黒色であったということになります。






 2.4 対応方法




 当事例に関してまして、当方の対応方法を時系列で記載します。


 あくまで例となりますが、参考にしてください。




   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側の


   ソースコード入手も不可能です。


   よってこれ以上の深追いはしません。。。(出来ません)






以上です。







140 180 Android , CTS

記載されている会社名、および商品名等は、各社の商標または登録商標です。

0 コメント:

コメントを投稿

Related Posts Plugin for WordPress, Blogger...