画面設定「画面の明るさ」の違いを確認する

ダミー電池の動作と安定化電源による起動が確認できたので、
早速、簡単な動作を計測してみました。

条件：
・壁紙設定：壁紙
・Wifi設定：OFF
・bluetooth設定：OFF
・GPS設定：OFF
・バックグラウンドシンク設定：OFF

「画面の明るさ」の変更方法：
・電源管理ウィジェットによる変更

1.「画面の明るさ」設定：レベル1

電源管理ウィジェットにて一番暗い設定にしました。

2.「画面の明るさ」設定：レベル2

電源管理ウィジェットにて1段階目の明るさ。

3.「画面の明るさ」設定：レベル3

電源管理ウィジェットにて2段階目の明るさ。

まとめ

各レベルと電流値を表にしました。

画面の明るさ	電流値
レベル1	0.11A
レベル2	0.15A
レベル3	0.26A

画面を明るくする程、電流の値が大きくなるのがわかります。
次回はオシロスコープを接続して波形から計測します。

消費電力計測用のダミー電池作成 part3

3.配線

電池と端末本体と接する箇所に金具があたるように配線を行いました。

本体に嵌め込むと以下のような感じ。

安定化電源と接続して、電気を流してみました。
みごと、起動に成功！！

ようやく、計測の準備が整いました。

ADKとArduinoの使いかた

先月の記事に続きについてADK-demoボードの使いかたとAndroidAccessoryデモアプリのビルド方法についてレポートいたします。

☆ Android Accessoryとは

今年５月にgoogleから発表されたAndroidハードウェア拡張規格のことです。

詳しい情報はこちらを参照してください。

　http://developer.android.com/guide/topics/usb/adk.html

今回はgoogleで公開されているソースコードを使用しました。

　https://dl-ssl.google.com/android/adk/adk_release_0512.zip

☆ Android Accessoryの面白いところ

一般的にハードウェアの拡張といえばUSBに周辺機器を接続するというイメージがありますが

Android Accessoryは、なんと外部装置がUSBホストでAndroid端末が周辺機器として振舞います。

この方式を取るメリットとしてはスマートフォンのように電力的に非力なデバイスから

外部へ電力供給させることなく、外部から電力供給を受けながら半永久的に動作させることが

できることです。またフレームワーク層でハードウェア/ドライバを隠蔽してくれていることから

難しいドライバなどを書かなくても外部機器を接続できるメリットもあります。

１．Android Accessoryを実現するためのハードウェア

当初Android AccessoryはArduinoをベースとした実装として発表されましたが

最近になってArduinoを用いないADK対応ボードもいくつか出てきているようです。

今回はADKの基本を知るためにもArduinoをベースにしたものを用いることにしました。

Arduinoを用いたADKを実現するアプローチとして次のようなものがあります。

　a) RT-ADKボード

　b) Arduino ADKボード

　c) Arduino MEGA 256 + USB HOST Shield 2.0

d) Arduino uno + SparkFun USB HOST Shield

RT-ADKボードとサブボード

RT-ADKボードはGoogleのロゴも付いていて、持っていて嬉しい基板ではありますが

ちょっと入手が大変なこともあり、今回は本家Arduinoが出しているArduino ADKボードでの

使用方法も併せて記載いたします。

☆Arduino USBシールドとADKボードの違いについて

オリジナルのUSB HOSTはシールドという形で拡張されるようになっていますが

RT-ADKボードとArduino ADKではシールド接続用の信号を温存するために

USB回路の接続にArduino非互換の信号を使っています。

そのため本家 USB HOSTシールドのライブラリをそのまま使うことができません

ちょっと古いですが最初のうちはADK Package配布に含まれているライブラリを使うようにしてください。

どうしても新しいものを使いたい方は次のピン割り当てを書き換えれば使えるようになるはずです。

　INT GPIO_9 -> ATMEGA2560(PE6)

　RST GPIO_8 -> ATMEGA2560(PJ2)

　GPX GPIO_7 -> ATMEGA2560(PJ3)

1-1．ツールとライブラリの準備

ADKで必要となるArduinoの開発環境は次のようにインストールを行う必要があります。

・Arduinoソフトウェア

Arduinoを動かすための基本ツールは次の場所から入手することができます。

　http://arduino.cc/en/Main/Software

ここでは9/20時点で最新版であるArduino 0022 を使用しています。

arduino-0022.zipをダウンロードし、任意のフォルダに展開します。

このツールは任意のフォルダから起動できるので外部ドライブに展開しても使用することができます。

今回はG:\に展開したものとして記載しています。

・Arduino ADK追加ファイル

Arduino ADKを使うために必要な追加ファイルは次の場所に公開されています。

なおこの追加ファイルはRT-ADKやunoには必要ありません。

http://www.arduino.cc/en/Main/ArduinoBoardADK

一番下にWindowsドライバのinfファイルが入ったzipファイルがありますのでダウンロードして

Arduino MEGA ADK.infをG:\arduino-0022\driversにコピーしておきます。

・Android Accessoryライブラリ

Android Accessoryで使用するライブラリをインストールします。

adk_release_0512.zipを展開しADK_release_0512\firmware\arduino_libs以下にある

次の２つのフォルダをG:\arduino-0022\librariesにコピーします。

・Capacitive Sensingライブラリ

RT-ADKボードに載っているタッチセンサーのライブラリもインストールします。

　http://www.arduino.cc/playground/Main/CapSense

ここに公開されている CapacitiveSense003.zip をダウンロードし

展開されたCapacitiveSense003フォルダをG:\arduino-0022\librariesにコピーします。

1-2. スケッチのビルド

Arduinoの世界ではソースコードをスケッチと呼びます。

ADKで配布されているコードにはスケッチも含まれていますので、これをビルドして使用します。

まずADK_release_0512\firmwareにあるdemokitフォルダをG:\arduino-0022にコピーしておきます。

arduino.exeを起動後にFile -> Openを実行し 上記コピーしたフォルダにあるdemokit.pdeを開きます。

次にTools -> Board にて "Arduino Mega 2560"を選択します。

Sketch -> Verify Compileを実行することによりビルドが開始されます。

正常にビルドされればステータス部分に"Done compiling"と表示されます。

☆Arduino ADKのみを使う場合は

Arduino ADKには RT-ADKの付属サブボードのようなものがありませんのでブレッドボードで代用します。

今回はフルカラーLED３個とスイッチ２個を載せてみました。

RT-ADKのサブボードに比べブレッドボードに載せた回路はなかり簡素なものとなっていることから

ADKオリジナルソースから次のコードをコメントアウトする必要があります。

　JoyStick

　Temp/Light Sensor

　Relay

　ServoMoter

　CapacitiveSenser

修正済みのスケッチを次の場所に置きましたので、こちらを参考にして下さい。

https://sites.google.com/a/brilliantservice.co.jp/beagleboard/adk/demokit_ADK.pde?attredirects=0&d=1

1-3. スケッチのアップロード

ビルドが終わったスケッチをアップロードする前に、予めPCとAdruinoを接続しておきます。

Arduinoボードを最初に接続した時にはドライバを要求されますので次のドライバをインストールして下さい。

RT-ADK -> G:\arduino-0022\drivers\FTDI USB Drivers\

　Arduino ADK -> G:\arduino-0022\drivers\Arduino MEGA ADK.inf

次に Tools -> Serial Portでボードに接続しているポートを指定します。

File -> Upload to I/O board を実行すればビルドされたスケッチがボードへ転送され

ADKボードとして使用することができます。

２．AndroidAccessoryデモアプリ(DemoKit)

AndroidAccessoryを動作させるためのデモアプリはAndroid Open Accessory Development Kit

(adk_release_0512.zip)に含まれています。

今回はこのデモアプリを使って動作確認するところまで記載いたします。

なお、とりあえず動作だけという方のためにビルド済みのapkファイルも準備しました。

https://sites.google.com/a/brilliantservice.co.jp/beagleboard/adk/DemoKit_singed.apk?attredirects=0&d=1

署名付きにしましたので、そのまま adb install等でインストールできます。

☆ ネットワーク越しのデバッグ

ADKはadbで使われるUSBポートを塞いでしまうため、USB接続によるデバッグができなくなります。

そこで有線LAN経由でadbを使えるようにします。

ここではBeagleBoardのIPアドレスを192.168.1.23として記載ています。

IPアドレスは使用する環境に合わせて読み替えてください。

・BeagleBoard側の設定

adbデーモンを停止したのちにadbの設定切り替えます。

シリアルコンソールから次のように入力します。

# stop adbd
# ifconfig usb0 192.168.1.23 up
# setprop service.adb.tcp.port 5555
# start adbd

adbdはAndroid起動時にUSB接続となってしまいますので

起動ごとに上記の操作を行うようにしてください。

・ホスト側の設定

いったんadbサーバを停止してからネットワーク経由で接続を行います。

adb kill-server
adb start-server
adb connect 192.168.1.23:5555

正常に接続できれば、USB接続と同じように"adb"や"ddms"を使ってデバッグを行うことができます。

2-1. ソースコードの準備

今回は Android Open Accessory Development Kitで公開しているソースコードを用いました。

ここで配布されているADK Package(adk_release_0512.zip)をD:\workspaceに展開します。

2-2. Eclipseプロジェクトの作成

配布されているソースコードはそのままビルドすることができないことから

新規プロジェクトを作成しつつインポートさせます。

Eclipseを起動後 File -> New -> Android Projectで新規プロジェクトを作成します。

新規プロジェクトのダイアログが出ますので次の項目を入力してFinishボタンを押します。

Project nameは任意の名前でかまいません

　"Create project from existing source"を選択し

　"D:\workspace\adk_release_0512\ADK_rlease_0512\app"を指定

Build Targetは"Google APIs(2.3.3)"を選択

※Android 2.3.4の項目が無いのは2.3.4発表時に3.0のためにAPI Level 11が定義されていたため

適切なAPI Levelが割り当てられなかったためのようです。

そのため2.3.4は2.3.3＋αとして扱われています。

2-3. ビルド、デバッグ

ADBの接続ができていればそのまま動作させることができます。

Targetバージョンが一致していないため警告マークが出ますが問題ありません。

デモアプリをインストール後にADK ボードを接続すると次のような画面が出ます。

ここでOKのボタンを押すとデモアプリが動き出します。

ボタンやジョイスティック操作に合わせて画面が変化したり、R,G,Bのスライダを

動かすとLEDが点灯すれば正常に動作しています。

今回は早足ではありましたがAndroidに独自ハードウェアを付ける方法について解説いたしました。

AndroidといえばJavaアプリというイメージがありますが、Adruinoが繋がるようになれば

簡単にハードウェアを触れるようになります。

これを機にハードウェアに興味を持ってくださる方が増えれば幸いです。

次回はADKの応用編としてFarmboxのプラットフォームとそれに必要になる機能

(無線LANとWebカメラなど)の追加方法についてレポートする予定です。

消費電力計測用のダミー電池作成 part2

2.パテの流し込みと整形

流し込みもできる超低粘度のポリパテ、パテ革命「ドロドロ」を使用しました。


型取りした台に流し込み。

乾燥させること二日間、無事に固まりました。

荒々しい電池のようなモノが出来上がりました。

でこぼこしている箇所を削り取った後。

Nexus Sにぴったり嵌るようになりました。

消費電力計測用のダミー電池作成 part1

消費電力の測定用にダミー電池の作成を行いました。
工作が苦手なため、かなり四苦八苦しました。
でも、楽しかったので記事として残します。

0.はじめに

今回、使用する端末はNexus S。

新品のNexus Sです。
まだオリジナルの保護シートが張られた状態です。

1.型取りを行う

まずは電池の型取りを行います。

型取り用の粘土をコネコネ開始。
手際が悪く、なかなか上手に混ざらなかったのですが、
慣れてきたころにいきなり固まり始め、慌てて電池を押し込みました。

数10分放置して電池を取り出すと、型ができました。
(※はじめての型取りで汚くてすみません)

ＣＴＳで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側の

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

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

以上です。

Tweet

BeagleBoard-xMとADK(Android Open Accessory Development Kit)

今年５月にgoogleから発表されたAndroid Open Accessoryについて

面白い試みであったことから話題になっておりましたが、

しかし発表当初はNexusシリーズしか使用できず対応ボードも少ないことから

用途も限定されておりました。

最近になって組み込みの定番のBeagleBoardやADK互換ボードも潤沢に手に入るように

なってきましたのでGingerBreadとADKを載せる方法についてレポートいたします。

なお必要な作業全部を一気にやろうとすると息切れしてしまいそうな量になりますことから

これから３回に分けてBeagleBoardへのADK移植方法とFarmboxでの事例について記載して

いきたいと思います。

１回目 BeagleBoard-xMにGingerBread(2.3.4)とADKを移植

２回目 ADK-demoボードの使用方法

３回目 無線LANとWebカメラを追加しFarmboxのプラットフォームとする

○１回目 BeagleBoard-xMにGingerBreadとADKを移植

　まず１回目としてBeagleBoardでGingerBreadが動作させられるようにします。

☆ADKには2.6.35以降のカーネルと2.3.4r1のGingerBreadが必要

　既にいくつかのコミュニティにてGingerBreadを動作させている事例が出ておりますが

　ADKを使用するためには次の要件を満たす必要があることから2.6.35以降のカーネルと

　GingerBread(2.3.4r1)以降のコードが必要となります。

　　1) USB compositeデバイスドライバ

　　2) Android Accessory Service

　ちょうど７月にTIからこれらの要件を満たした新しいBSPがリリースされましたことから

　今回はこのBSPのオープンソース版を利用することにしました。

１．開発マシンのセッティング

　今回こちらでは次の環境で作業を行いました。

　 Ubuntu 10.10 (32bit版)

　 Oracle VirtualBox 4.0.10

　なお GingerBreadでは64bitビルド環境が必要とされていますが、今回使用するソースコードでは

　32bit版でもビルド可能なようになっておりますことから、作業は32bit版で行っています。

　また作業の都合で仮想環境を用いておりますが、こちらは必須ではありません。

　

　1-1. 必要なパッケージのインストール

　Android開発で必要なパッケージをインストールします。

　$ sudo apt-get install git-core flex bison gperf libesd0-dev libwxgtk2.6-dev zlib1g-dev build-essential libstdc++5 tofrodos
　$ sudo apt-get install x-dev libx11-dev libncurses5-dev

　Ubuntu 10.10においてJAVA-JDKがインストールすることができない場合は

　手動でrepositoryを追加してからインストールします

　$ sudo add-apt-repository ppa:sun-java-community-team/sun-java6
　$ sudo apt-get update
　$ sudo apt-get install sun-java6-jdk
　$ sudo update-java-alternative -s java-6-sun

　次にソースコード取得に必要なrepoを ~/bin以下にダウンロードします。

　$ mkdir ~/bin
　$ curl http://android.git.kernel.org/repo >~/bin/repo
　$ chmod a+x ~/bin/repo

２．作業ディレクトリの作成と環境設定

　今回は作業ディレクトリとして ~/rowboat-gingerbread を使用するようにします。

　ディレクトリ名は自由に変更してもかまいません。

　また作成したディレクトリを環境変数MYWORKに設定します。

　$ mkdir ~/rowboat-gingerbread
　$ export MYWORK=~/rowboat-gingerbread
　$ export PATH=~/bin:$PATH

３．ソースコードの取得

　BeagleBoard用のGingerBreadはrowboatプロジェクトにて公開されているものを利用します。

　OMAP3対応のkernel-2.6.37とGingerBread-2.3.4r1が既にマージされていることから

　Android本体とカーネルはこれをそのまま使用することができます。

3-1.まずダウンロードの前に次のrepo設定を行います

　$ cd $MYWORK
　$ repo init -u git://gitorious.org/rowboat/manifest.git -m TI-Android-GingerBread-2.3.4-DevKit-2.1.xml

　途中メールアドレス入力を要求されますが適当なメアドでもかまいません。

3-2.ソースコードのダウンロード

　repo設定が成功したらソースコードのダウンロードを行います。

　次のコマンドラインを実行するとダウンロードが開始されます、接続先のサーバー速度の関係で数時間ぐらい

　待たされることがあります。

　$ repo sync

　またごくまれですが接続先サーバーがダウンしていてダウンロードが失敗することがあります、

　この場合は再実行するようにしてください。

４．各種パッチの適用

　ソースコードの取得が終わったらADK関連のパッチを当てます。

4-1. MSM-Accessoryパッチ

　ADKのコードはMSM(Qualcomチップ)向けに作られて公開されています。

　　http://android.git.kernel.org/?p=kernel/msm.git;a=shortlog

　今回は上記サイトから取得した差分を利用するようにしています。

　こちらにアーカイブしてありますので ~/ 以下に展開しておいてください。

　次のように kernel以下に移動してパッチを適用します。

　MSM向けパッチをそのまま利用することから、実行中にいくつか Hunkとエラーが出でますが

　次項のパッチにて補填していますので気にせず進めてください。

　$ cd $MYWORK/kernel
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-d7784832481a3d13e8f919db7eabc402696998e1.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-ead002dbe5a670536874d4cf2b4c73cbbc426157.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-5d9d8625e39f815673dedea353f39edccabb1fac.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-4aaac2e5495f5bde877c0221fb3a8afacbf5d3d3.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-9cf8b58077c7bfaeb91d3cd111775ca556879c8c.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-6f992b5fa6b9e20a406df75c52e212927b51e868.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-64bef932a63b68eb5a64d07364150ffdfba133c8.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-148b63e6082d35d9a5ec0f156d76ca40a4278044.patch
　$ patch -p1 < ~/ADK_Patches/msm_patches/msm.git-3cb34390dbf3d219c823638a9ff835ae555cce48.patch

　なお同パッチのうち次のパッチは使用しません

　msm.git-768b24639b4dfd527928ea7ff5ce5b7cabb15a80.patch

　 usb: gadget: Fixed Android gadget function discovery & product matching

　<これはすでに適用済み>

　msm.git-3ac4a31f2d603d6dabc50fe9e2fa4ebd4e7a4e59.patch

　msm.git-52630a39c5c9348381cec1b623def97f948f4df9.patch

　これはMSM固有であるため次項4-2のパッチを使用します。

4.2. BeagleBoardパッチ

前項のMSM-Accessoryパッチで不足しているパッチを適用します。

　$ cd $MYWORK/kernel
　$ patch -p1 < ~/ADK_Patches/beagleboard/beagleboard_kernel.patch
　$ cd $MYWORK/device
　$ patch -p1 < ~/ADK_Patches/beagleboard/beaglebard_device.patch

　このパッチでは次の内容を修正しています

　 a) accessory gadgetドライバをビルド対象にするための Makefile設定

　　b) usb compositeドライバで使用される USBディスクリプタテーブルの追加

　　c) rowboatカーネルでは USBインターフェイスが１つしか登録できないことから

　　　複数のインターフェイスが登録できるように修正

　d) カーネルのコンフィグレーションファイルに accessory gadgetを追加

　　e) Android Accessoryサービスが有効になるようxmlファイルを修正

　f) Android Accessory関連ファイルがAndroid FSにインストールされるよう設定ファイルを追加

５．ビルド

　ビルド作業はMLO,u-boot,AndroidFSの順に進めていきます。

5.1 x-loader

　OMAP3の１次ローダであるMLO(x-loader)は次のようにビルドします

　$ cd $MYWORK/x-loader
　$ export CROSS_COMPILE=$MYWORK/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
　$ make distclean
　$ make omap3beagle_config
　$ make

　なお出来上がったx-loader.binは”SecureOMAPの署名が付いていません

　BeagleBoardはSecureOMAPの署名は必要ありませんが念のため付加しておきます。

　署名に必要なsignGP コマンドは次のように入手します

　$ wget http://beagleboard.googlecode.com/files/signGP
　$ chmod +x signGP

　signGPコマンドが入手できたら次のコマンドで署名付きにします

　$ ./signGP x-load.bin
　$ mv x-load.bin.ift MLO

5.2 u-boot

　OMAP3の２次ローダーであるubootは次のようにビルドします

　$ cd $MYWORK/u-boot
　$ export CROSS_COMPILE=$MYWORK/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
　$ make distclean
　$ make omap3_beagle_config
　$ make

　次項のカーネルのビルド時に本項でビルド生成したmkimageが必要となりますので

　~/binにコピーしておきます

　$ cp tools/mkimage ~/bin

5.3 Andorid FS

　今回使用しているコードではLinuxカーネル、Andorid、SGXをまとめてビルドすることができます

　BeagleBoard-xMはAM37xxを搭載しているので環境変数 "OMAPES"に "5.x"を使用します。

　なお、本来GingerBreadは６４ビット環境でしかビルドすることができませんが

　rowboat版では６４ビットコンパイルオプションを設定をコメントアウトしてあることから

　３２ビット環境でもビルドすることができます。

　$ cd $MYWORK
　$ make TARGET_PRODUCT=beagleboard -j8 OMAPES=5.x

　Installation complete! と表示されればビルド完了です。

　5.3-1 カーネル再コンパイル

　 カーネルだけ再ビルドしたいときには次のコマンドを使用します

　$ cd $MYWORK
　$ export ARCH=arm
　$ export CROSS_COMPILE=$MYWORK/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
　$ make -C kernel uImage

６．SDカードイメージを作成

　生成されたバイナリをインストール用にアーカイブします

　$ cd $MYWORK/out/target/product/beagleboard
　$ mkdir android_rootfs
　$ cp -r root/* android_rootfs
　$ cp -r system android_rootfs
　$ sudo ../../../../build/tools/mktarball.sh ../../../host/linux-x86/bin/fs_get_stats android_rootfs \
. rootfs rootfs.tar.bz2

７．SDカードへのインストール

　7.1 ブートスクリプトの作成

　BeagleBoard-xMではカーネルに起動パラメータを渡すためにブートスクリプトが必要となります

　ブートスクリプトは次の方法にて生成することができます

　$ cd $MYWORK
　$ cp ~/ADK_Patches/beagleboard/boot.script .
　$ $MYWORK/u-boot/tools/mkimage -A arm -O Linux -T script -C none -a 0 -e 0 -n ./boot.script -d ./boot.script ./boot.scr &> /dev/null

　ここで使用しているテンプレートではDVI出力に 1280x720で表示するように設定しています

　これ以外の表示設定をしたい場合はパラメータを書き換えてスクリプトを再生成してください

7.2 SDカードのフォーマット

　SDカードから起動するためにはSDカードをパーテション分割しフォーマットする必要があります

　次のコマンドでSDカードをフォーマットを行います

　ここではUSB接続されたSDカードリーダが「/dev/sdb」として認識されているものとして記述しています

　もし別のデバイス名として認識されている場合は、この部分を読み替えて実行するようにしてください。

　$ sudo ~/ADK_Patches/omap3-mkcard.sh /dev/sdb

　このomap3-mkcard.shでは SDカードを２分割し第１パーテーションをvfat、第２パーテションをext3で

　フォーマットしています

7.3 バイナリのインストール

　SDカードの第１領域にブートローダ、カーネルをインストール、第２領域にAndorid FSをインストールします。

　インストールは MLO, uboot.bin, boot.scr, uImageの順にコピーする必要があります

　$ sudo mount /dev/sdb1 /mnt
　$ sudo cp $MYWORK/x-loader/MLO /mnt/
　$ sudo cp $MYWORK/u-boot/u-boot.bin /mnt/
　$ sudo cp $MYWORK/boot.scr /mnt/
　$ sudo cp $MYWORK/kernel/arch/arm/boot/uImage /mnt/
　$ sudo umount /mnt
　$ sudo mount /dev/sdb2 /mnt
　$ cd /mnt
　$ sudo tar xvjf $MYWORK/out/target/product/beagleboard/rootfs.tar.bz2
　$ cd /
　$ sudo umount /mnt

８．BeagleBoard-xMでの起動

　SDカードをBeagleBoard-xMに装着し、電源を投入します

　なおAndroidが起動するまで数分かかります

　また初回起動の際にはホーム画面が出てもしばらくの間はバックグランドでインストールが

　続いていることから多少動作レスポンスが遅くなりますが、次回起動時には通常となります。

９．ADKボードの接続

　もしDemoKitが書き込まれたADKボードがあれば、USBポート(ADB用の小さいほう)に接続すると

　次のような画面が出るはずです。

　ADKボードの使い方については次回解説する予定です。

技術部 中村和貴

ＣＴＳ応用編（覚えておいたら得する操作方法）

今回は、ＣＴＳで覚えておいたら楽、得、自慢（？）できる操作について記載いたします。

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

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

1.　CTSの操作（応用編）

　1.1　テスト中の操作

　　1.1.1　中断

　　　プランCTS実施中に、中断せざるを得ない事態（ターゲットデバイスフリーズ、microSD入れ忘れに気づくなど）が発生することがあります。

　　　その場合、”Ctrl+C”（下図　青丸部分）で中断が可能です。

　　Note.

　　　CTSは、随時 /android-cts/repository/results/[日付フォルダ]/testResult.xml へ実行結果の書き込みを行ってます。中断のタイミングによっては、testResult.xmlが破損する可能性もあります。

　　　よって、この方法によっての中断は、リスクがあることを承知した上で、実行してください。

　　　書き込みを行っていないと思われるタイミング、たとえば、ターゲットデバイスReboot中などが狙い目です。

　　1.1.2　再開

　　　1.1.1で中断させたプランCTSを再開させる場合は、通常のCTS起動と同じです。

　　再開させずに新規で開始したい場合：

　　　”0” → エンター

　　再開させたい場合：

　　　”1” → エンター

　　選択した内容で、プランCTSが実行されます。

　　Note.

　　　中断しているプランが複数ある場合は、cts_hostプロンプトで、”ls -r”によって、実行プラン一覧が

　　表示することが出来ます。

　　　ここでSession Id毎に表示される情報を確認し、再開させたいプランを確認します。

　　　Session ID 5（プランCTS）を再開させる場合は、”1” → エンター → ”1” → エンターとなります。

　1.2　プランCTSのピンポイント実施

　　1.2.1　クラス単位で実施する

　　　ときには、パッケージ単位より、細かい単位で実施したい場合もあります。

　　　例えば、android.textパッケージのEditable_FactoryTestクラスだけを実行したい場合があったとします。

　　　cts_hostプロンプトで”start --plan CTS -p android.text.cts.Editable_FactoryTest”を入力します。

　　　書式：start --plan test_plan_name -p java_package_name.class_name

　　　Note.

　　　　パッケージに含まれるtest suite単位で実施したい場合です。

　　　　図1.2.1の例からいきますと、

　　　　”start --plan CTS -p android.text.cts”と入力することで、

　　　　”android.text.cts”Test Suiteが全て実行されます。

　　　　※但し、Not Executedの項目のみです。

　　1.2.2　メソッド単位で実施する

　　　CTS実施の最小単位です。

　　　android.textパッケージのStaticLayoutTestクラスのtestGetLineForVerticalメソッドだけを実行したい場合cts_hostプロンプトで

　　　”start --plan CTS -p android.text.cts.StaticLayoutTest#testGetLineForVertical”

　　　と入力します。

　　　書式：start --plan test_plan_name -p java_package_name.class_name#method_name

　　　Note.

　　　メソッド単位実行した場合、対象メソッドが既に実行済み（pass/failのどちらか）であっても、結果（testResult.xml）を上書きします。

以上です。

当記事内容をPDF化してます。

下記LinkからDownloadできます。

BS_CTS_Doc04（応用編）.pdf

Tweet

Google TV add-onを試してみた（Preview版）。

2011/08/22（米国日時）にGoogleからAndroid SDKにGoogle TV add-onのプレビュー版がリリースされました

今回のリリースはプレビュー版なので全ての機能を使うことはできませんが、Google TV向けのアプリケーション開発／テストを

行うことができます。また、Marketへの登録も行うことができます。

まだプレビュー版とのことで、現時点では、実行環境はLinux+KVMしかサポートされていませんが、

他のOS（WindowsやMac OS）のサポートも準備中とのことです。

それではさっそく環境を構築してGoogle TV add-onをダウンロードして動かしてみたいと思います。

※既にAndroidの環境が構築されている前提で進めていきます。

動作確認したPCの環境は、「Ubuntu 11.04」です。

■1. ターミナルまたはEclipseのADTから、「AVD Manager」を起動します。

■2. 左側の「Available packages」を選択し、「Packages available for download」欄の「Third party Add-on」を選択します。

すると、以下画像のように【Google TV by Google Inc., Android API 12, revision1】がリスト表示されます。

チェックボックにチェックし、右下の「Install Selected」ボタンを押します。

■3. 「Choose Packages to Install」画面に遷移しますので、必要なパッケージを全てインストールします。

※Google TV add-onは、Android SDK内に保存されます。 android-sdk-linux_x86/add-ons/addon_google_tv_google_inc_12

■4. インストールが完了したらGoogle TVのAVDを作成します。

「AVD Manager」の「Virtual devices」から「New」のボタンを押して、「Create new Android Virtual Device（AVD）」を表示させます。

Nameには任意の名前を記入し、Targetには「Google TV Addon」を選択します。右下の「Create AVD」ボタンを押してAVDを作成します。

※今回スキンは、720pと1080pが用意されています。

■5. ここでさっそくAVDを起動したいところですが、Google TVのエミュレータは、KVM上で動作させることができます。

KVMなしでも動作しますが、非常に動作が重たいため、KVM上で動作させることをオススメします。　

また、KVMはGoogleが正式にサポートしており、インストールするのみとなっています。

・KVMのインストール

$ sudo apt-get install kvm qemu

※これで、/dev配下に「kvm」が格納されます。

・KVMに実行権限を付ける

$ sudo chmod a+rw /dev/kvm

※KVMのインストール／設定は以上です。

■6. Google TVエミュレータを起動する。

KVMが正常に動作しているかも兼ねて起動してみます。

「AVD Manager」からでも起動できますが、ターミナルから、以下コマンドを実行します。（-verboseフラグを付けます）

$ emulator -avd <AVD Name> -verbose

ターミナル上に、以下の出力がされていればKVMは正常に動作しています。

emulator: KVM mode auto-enabled!

また、KVMを使わないように起動することも可能です。

$ emulator -avd <AVD Name> -qemu -disable-kvm

※一目瞭然でKVM上で動作させたほうがいいことがわかると思います。

通常KVM上で動かす場合は「-verbose」は必要ありません。また「AVD Manager」からの起動もKVM上で動くようになっています。

環境構築は以上です。

次にGoogle TVエミュレータを動かしてみます。

起動は思いのほか早いです。おそらくアプリケーションが少ないからでしょう。

右下にハードキーもついていて、左から「HOME」「MENU」「BACK」「SERCH」となっています。

ランチャー画面です。API demosやLive TVなどが入っています。

SettingsアプリのAbout画面です。Firmwareは3.1となっています。

Live TVアプリの画面です。ロケーションに応じてチャンネル設定ができます。

今回のリリースでUIガイドラインも一緒に公開されています。

UI guidelines

画面が大きい分、それなりのデザインをすることができそうですね。

技術部 藤田竜史

Tweet

ＣＴＳ概要、環境、基本操作

今回は、ＣＴＳ概要、環境、基本操作について記載いたします。

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

０.はじめに

　昨今、注目を浴びているAndroidですが、CTSというのは、みなさんご存知でしょうか？

　名前は聞いたことあっても、実際、使ったこと無い人がほとんどだと思います。

　なぜなら、アプリベンダーにはあまり関係ないことですから。しかし、Androidを利用して、世に

　何らかのハードを出そうという人たち（メーカ、個人含む）、またはframeworkを改変（Bug対応など)し、

　Android Open Source Projectsにsubmitしようとする人にとっては、実は避けては通れない道です。

　本記事は、そんな人たちのために捧げます。

　株式会社ブリリアントサービス　　　　

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

　(校正)　

　技術部　藤田竜史(twitterID:@ryuuuji)　

　※藤田くん、チェックありがとう。

　

1.CTS概要

　1.1　CTSの目的

　　CTS（正式にはCompatibility Test Suite。以下、CTS)は、Google社が

　　Android Platform採用端末に実施を義務付けているTest群です。Google社は、

　　今までOEM、もしくはキャリア依存であったPlatformをAndroidで汎用化しました。

　　CTSは、Android Marketで配布されるアプリケーションが、

　　どのOEMのAndroid端末でもスムーズに利用可能なよう（OEMによって、特化されすぎないよう）に、

　　主要な公開APIを実行し、チェックします。

　　世の中にAndroidPlatform採用端末を配布する場合、これらTest群を全てpassすることが

　　互換性を保つという証になり、そういうプロセスを経て初めて「Android端末」を

　　名乗ることが出来るのではないでしょうか。

　　蛇足ですが、Android 2.3 Compatibility Definition Document(CDD)という、

　　Android Platform使用するためのRequirementがあります。

　　こちらもあわせて、目を通されることをお勧めします。

　　参照：　http://source.android.com/compatibility/2.3/android-2.3.3-cdd.pdf

　　注．本内容は、2011年8月22日現在、Google社が提供する環境を元に作成しております。

　1.2　CTSの動作

　　CTSは、自動化されたハーネスです。以下の二つを含みます。

　　・テスト実行の管理

　　・ターゲットデバイス上で実行されるテストケースのAPKファイル

　　大まかな手順としては、以下のようになります。

　　1.CTSをDownload

　　2.ターゲットデバイスの接続

　　3.アクセスビリティテスト実行準備

　　　a）android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk をインストール

　　　b）以下の手順でインストールしたアクセスビリティサービスを有効にします。

　　　　　Settings > Accessibility > Accessibility > Delegating Accessibility Service

　　４．アドミニストレータテスト実行準備

　　　ａ）android-cts/repository/testcases/CtsDeviceAdmin.apk をインストール

　　　ｂ）Settings > Location & security 以下にあるandroid.deviceadmin.cts .* を全て有効にします。

　　５．ＣＴＳを起動します。

　　６．ＣＴＳレポートが作成されます。

　　参照：　http://source.android.com/compatibility/cts-intro.html

　1.3　CTSのテスト範囲

　　テスト範囲は以下の通りです。（現在、大きく分けて７つになります）

　　参照：http://source.android.com/compatibility/cts-intro.html　

２.　CTSの環境作り

　2.1　必要なもの

　　（ハード）

　　・PC　-　DownloadしたCTSを実施します。

　　・ターゲットデバイス　－　Android Platformを採用したデバイスです。

　　（ソフト）

　　PCに必要なもの

　　・Android Developersから、SDKをDownloadしてください。（PC OSに適合したもの）

　　　※Build環境が整っているということが前提となります。

　　　参照：　http://developer.android.com/sdk/index.html

　　Note.

　　CTS実施環境について、PC側のOSは、こちら側で確認取れているのは、Linux（Ubuntu）、MacOSです。

　　Windowsに関しましては、CTS側環境がWindowsに適合していない部分があり、実行Errorとなります。

　　CTS側環境を改変+Cygwinで、動作は確認しています。機会があれば別途紹介いたします。

　　・Android Open source project から、ターゲットデバイスのFirmware versionにあわせたCTSを

　　　PCの任意の場所にDownloadしてください。

　　　参照：　http://source.android.com/compatibility/downloads.html

　Note.

　　CTSは、ターゲットデバイスで採用されているFirmware versionにあわせて、選択する必要があります。

　　Android2.3(Gingerbread)採用の場合、CTS2.3R5が実施すべきCTS versionとなります。（図2.1-2参照）

　2.2　実施準備

　　2.1.1　 CTS実施フォルダ作成

　　　2.1章でDownloadしたCTS 2.3R5(android-cts-2.3_r5-x86.zip)を任意の場所で解凍します。

　解凍後、図2.2-2のようなフォルダが作成されます。

　 2.2.2　環境変数の設定

　　　CTSは、/android-cts/tools/startctsを実行することで起動します。startctsは、

　　　スクリプトで書かれており、CTS2.3R5では、そのスクリプト中で環境変数を

　　　２つ使用しています。

　　環境変数その１　CTS_ROOT

if [ -z "${CTS_ROOT}" ]; then
# CONFIGURATION
# Set this variable to the root of unzipped CTS directory
# This only needs to be changed if this script has been moved
CTS_ROOT="$(dirname $0)/.."
fi;

　　通常使用の場合、特に意識、変更、設定する必要は、ありません。

　　環境変数その2　SDK_ROOT

# Add SDK_ROOT to the PATH for backwards compatibility with prior startcts
# commands that required SDK_ROOT to find adb.
if [ -n "${SDK_ROOT}" ]; then
PATH=${SDK_ROOT}/platform-tools:${SDK_ROOT}/tools:${PATH}
fi

　　~/.bashrcに、exportを追加します。

export SDK_ROOT=~/android-sdk-linux_x86

Note.

.bashrcを変更せずに、下記のようにSDK_ROOTの初期値を直接与えても構いません。

# Add SDK_ROOT to the PATH for backwards compatibility with prior startcts
# commands that required SDK_ROOT to find adb.
SDK_ROOT=”~/android-sdk-linux_x86”
if [ -n "${SDK_ROOT}" ]; then
PATH=${SDK_ROOT}/platform-tools:${SDK_ROOT}/tools:${PATH}
fi

　2.2.3　CTS実行

　　　CTS実行するには、前述のようにstartctsを実行します。

上記のようにcts_hostプロンプトが表示されれば正常に起動されています。

３.　CTSの操作（基本編）

　3.1　プランCTSの確認

　　CTSのプランは、”ls –plan”で確認することが出来ます。

　　現在は、計8種類提供されています。プランCTSは、そのうちのひとつです。

　　Note.

　　Google社へは、プランCTS（図3.1-1の赤丸）実施、作成されたレポートを提出します。

　　本記事では、プランCTS以外の説明は割愛いたしますが、プランCTSで実施される各種テストが

　　目的別に小分けされたようなものだと考えてください。

　プランCTSが提供する項目を”ls --plan CTS”で確認することが可能です。

　現在は、計42項目のテストパッケージが提供されております。

　3.2　プランCTSの実施

　　3.2.1　プランCTS実施方法その１

　　　プランCTSは、“start –plan CTS”で実行されます。

　　　書式：start --plan test_plan_name

Note.

　　自動で、端末Rebootを繰り返しながら、プランCTSの項目を順に実施していきます。

　　3.2.2　プランCTS実施方法その２

　　　プランCTSを図3.1-2で表示したテストパッケージ単位で実施することが可能です。

　　　”-p”オプションにて、テストパッケージ名を指定します。

　　　書式：start --plan test_plan_name -p java_package_name

　　　下記の例では、”android.apidemos.cts”を実施させています。

　　Note.

　　指定されたテストパッケージに含まれるテストシナリオが全部実行された後、

　　cts_hostプロンプトが表示されコマンド入力待ちとなります。

　　3.2.3　プランCTS結果確認

　　　CTS実施結果は、android-cts/repository/results 直下に、CTS開始日付フォルダが作成され、そこに格納されます。

　　Note.

　　resultsフォルダの下に、zipファイルが作成されます。

　　これは、前述のCTS実施結果が格納されるCTS開始日付フォルダをcompressしたものです。

　　Google社へは、このzipファイルを提出します。

　CTS実施結果フォルダには、図3.2.3-2で示すようなファイル群が存在します。

　　testResult.xmlに実行毎に結果が反映されていきます。その結果は、ブラウザで確認可能です。

　　testResult.xmlをブラウザでOpenすると下記、図3.2.3-3のように表示されます。

　　他の情報もブラウザスクロールによって表示されます。

　　CTSがエラーを検知した場合、下記のように、Result列が赤くなり、エラー詳細が表示されます。

　　Note.

　　Failure Detailsに表示されるエラー内容では、

　　どのようなAPIを使用した結果エラーとなったのかが判別しにくい場合があります。

　　その場合、CTSソースコード（AOSPから取得可能）を解析し、エラー要因、

　　APIを特定する必要があります。

以上です。

当記事内容をPDF化してます。

下記LinkからDownloadできます。

BS_CTS_Doc01（概要）.pdf

BS_CTS_Doc02（環境）.pdf

BS_CTS_Doc03（基本操作）.pdf

Tweet