D4 de Android
元々かなり利用シーンが限られていたWILLCOM D4ですが、IS03が来てからますますいらない子になってしまって。WILLCOMのつなぎ放題のオプションも外しちゃったし。ただSSDに載せ代えまでしたのにこのまま置物ではもったいない。ということで、Androidを載せてみることにしました。とは言ってもバッテリーのこともあって実用になるとは思えないので、これも検証端末になればって程度ですが。
x86のAndroidは、元々は体験という名目だったようですが、Atomの載った製品も登場してきたりと、今では実用に足るものになっているようですね。検索してみたところ、ここにAndroid x86 2.2のCDイメージがありましたので、android-x86-2.2-generic.isoをダウンロードしてCDに焼いてみました。
SDカードからインストールする方法もあるようですが、D4のSDカードスロットはかなりクセがあって、ドライバを入れるまで見えませんのでブートはできません。なので今回はクレードルにCD-ROMドライブを外付けして、そこからブートします。

起動時にF2キーを押してBIOSメニューに入り、BOOT DEVICE PRIORITYでUSB CD-ROMからブートするように設定します。焼いたCDを入れてブートすると、ブートメニューが表示されました。

とりあえずHDDにはインストールせずに、CDから立ち上げてみます。D4の液晶は5インチ1024x600ですので、計算してみるとほぼ240dpiになります。なのでHDPIでいいはずです。
CDからなのでしばらくウインウインと時間はかかりますが、やがてAndroidのロック画面が表示されました。

あっさり立ち上がりはしましたが…なんか横に伸びてますね。ネイティブ解像度になってないようです。とりあえずロックを解除してみます。


タッチパネルは動きます。ただ少しずれていますが、キャリブレーションする方法がありません。タッチパッドも動きます。マウス扱いなので、マウスカーソルが表示され、左クリックが決定(アプリ的にはタッチイベント)、右クリックが戻るです。
そしてなんとなく予想はしていましたが、無線LANが認識できません。ただクレードルの有線LANは認識しました。

D4の無線LANはどうもSDIOで繋がっているらしく、on/offはWindowsのドライバがやっていたようなんですよね。Windowsでonにしてインジケータを点灯しても、Windowsが終了すると消えてしまい、onにできません。とりあえずどうしようもなさそうです。
さらに、やっぱりSDカードスロットも認識できません。

これもどうしようもないんでしょうね。仕方がないのでUSBカードリーダーに16GBのSDカードを挿してつないでみたら、認識しました。

ちなみにこの時点(CDから起動時?)では、Androidが起動する前にカードリーダーをつなぐと認識しませんでした。起動時につながっていると何か別のものと認識されてしまうのでしょうか?
Android system infoを見てみたところ…


通常とは逆向きに画面が回転しました(ちなみに画面回転のハードウェアキーは当然のように効きませんし、加速度センサ類も載っていないので、何らかの画面回転アプリを入れないことには、ユーザーは画面の向きを制御できません)。CPUはAtom 1.33GHzと認識されていますが、なぜか800MHzしか出ていません。そしてスクリーンは800x600と認識されていました。横方向が引き伸ばされて表示されてるんですね。
やはり無線LANは使えないとということで、USBのモジュールを挿してみたのですが、全く認識できませんでした。代わりに有線のモジュールを挿してみたところ、こちらは認識しました。

最低限クレードルから外しても、有線LANでネットはできるってことですね。無線はひょっとしたらモノによっては認識するのかもしれませんが。
ここまでの感じとして、いろいろと面倒はあるけど、まあ検証機としてなら使えるかなという感触です。動作は、ページ切り替えのスクロールは割りとするする動くのに、ウィンドウアニメーションとか、特にダイアログが表示されている間はなぜか異様に重くなったりします。重いところはePadより重いです。何でしょうね?
まあそんな感じなので、SSDにインストールしてみることにしました。現在64GB1パーティーションでWindows 7が入っていますので、8GB程空けて突っ込んでみました。CDのブートメニューからInstallationを選択し、インストールしたいパーティーションを選び、マルチブートしたい場合はブートメニューを入れてねとお願いするだけで、非常に簡単です。



おや?なんかさっきと雰囲気違くね?と思ったら、どうやらMDPIの設定になっているようです。
ちなみにブートメニューはこんなん。

インストールしても、起動時にHDPIとMDPIを選べるようになっています。
ところで、USBフラッシュメモリ(SDカードの代わり)と有線LANモジュールはUSBハブ(バスパワード)につないで、それをクレードルにつないでいたのですが、なぜか有線LANが見えなくなっています(そしてメモリがAndroid起動時から挿していても認識するようになっている)。試しにクレードルに直に付けてみたのですが、やっぱり見えません。本体をクレードルから外し、直につなぐと認識しますが、ハブを噛ませると見えません。クレードルの中には(セルフパワードの)ハブが入っているであろうことを考えると、どうもハブを噛ませると認識できなくなってしまったようです。何で?ただ本体にはUSBポートが一つしかありませんので、メモリも同時に挿せないと困ります。こんなことなら仮想SDをSSDの中に作っておけばよかったよ。
カメラは動きませんが、どの道D4のカメラは役に立ちません。W-SIMは試してませんが動くわけないでしょう。あとワンセグも。Bluetoothは興味ないので試してませんが、ひょっとしたら動くかもしれませんね。まあその辺はどうでもいいんですが、一つ大きな問題が。
メニューキーがないんです。
通常PCにAndroidを入れた場合、キーボードのMenuキー、およびマウスのホイールボタンにメニューキーが割り当てられますが、D4にはWindowsキーはあるけどMenuキーもホイールボタンもありません。なので、Menuキーのあるキーボードか、ホイールのあるマウスを外付けしないと、検証用にもなりません。クレードル運用しかないんでしょうかねぇ。別のキーにアサインさせる方法あるのかなぁ。自分でビルドすればいいんだろうけど。
最後に、日本語のIMEは現時点でsimejiのx86版のみじゃないかと思います。作者に感謝です。(マーケットではなく)検索すると出てくると思います。あとESファイルエクスプローラーはインストールできませんでした。それから、ネイティブ解像度にするには、915Resolutionパッチを当ててうんぬんみたいな話を見つけましたが、自分でビルドしないといけないみたいなのでとりあえず今回は見送りです。興味のある方は…やり方教えてください。
x86のAndroidは、元々は体験という名目だったようですが、Atomの載った製品も登場してきたりと、今では実用に足るものになっているようですね。検索してみたところ、ここにAndroid x86 2.2のCDイメージがありましたので、android-x86-2.2-generic.isoをダウンロードしてCDに焼いてみました。
SDカードからインストールする方法もあるようですが、D4のSDカードスロットはかなりクセがあって、ドライバを入れるまで見えませんのでブートはできません。なので今回はクレードルにCD-ROMドライブを外付けして、そこからブートします。

起動時にF2キーを押してBIOSメニューに入り、BOOT DEVICE PRIORITYでUSB CD-ROMからブートするように設定します。焼いたCDを入れてブートすると、ブートメニューが表示されました。

とりあえずHDDにはインストールせずに、CDから立ち上げてみます。D4の液晶は5インチ1024x600ですので、計算してみるとほぼ240dpiになります。なのでHDPIでいいはずです。
CDからなのでしばらくウインウインと時間はかかりますが、やがてAndroidのロック画面が表示されました。

あっさり立ち上がりはしましたが…なんか横に伸びてますね。ネイティブ解像度になってないようです。とりあえずロックを解除してみます。


タッチパネルは動きます。ただ少しずれていますが、キャリブレーションする方法がありません。タッチパッドも動きます。マウス扱いなので、マウスカーソルが表示され、左クリックが決定(アプリ的にはタッチイベント)、右クリックが戻るです。
そしてなんとなく予想はしていましたが、無線LANが認識できません。ただクレードルの有線LANは認識しました。

D4の無線LANはどうもSDIOで繋がっているらしく、on/offはWindowsのドライバがやっていたようなんですよね。Windowsでonにしてインジケータを点灯しても、Windowsが終了すると消えてしまい、onにできません。とりあえずどうしようもなさそうです。
さらに、やっぱりSDカードスロットも認識できません。

これもどうしようもないんでしょうね。仕方がないのでUSBカードリーダーに16GBのSDカードを挿してつないでみたら、認識しました。

ちなみにこの時点(CDから起動時?)では、Androidが起動する前にカードリーダーをつなぐと認識しませんでした。起動時につながっていると何か別のものと認識されてしまうのでしょうか?
Android system infoを見てみたところ…


通常とは逆向きに画面が回転しました(ちなみに画面回転のハードウェアキーは当然のように効きませんし、加速度センサ類も載っていないので、何らかの画面回転アプリを入れないことには、ユーザーは画面の向きを制御できません)。CPUはAtom 1.33GHzと認識されていますが、なぜか800MHzしか出ていません。そしてスクリーンは800x600と認識されていました。横方向が引き伸ばされて表示されてるんですね。
やはり無線LANは使えないとということで、USBのモジュールを挿してみたのですが、全く認識できませんでした。代わりに有線のモジュールを挿してみたところ、こちらは認識しました。

最低限クレードルから外しても、有線LANでネットはできるってことですね。無線はひょっとしたらモノによっては認識するのかもしれませんが。
ここまでの感じとして、いろいろと面倒はあるけど、まあ検証機としてなら使えるかなという感触です。動作は、ページ切り替えのスクロールは割りとするする動くのに、ウィンドウアニメーションとか、特にダイアログが表示されている間はなぜか異様に重くなったりします。重いところはePadより重いです。何でしょうね?
まあそんな感じなので、SSDにインストールしてみることにしました。現在64GB1パーティーションでWindows 7が入っていますので、8GB程空けて突っ込んでみました。CDのブートメニューからInstallationを選択し、インストールしたいパーティーションを選び、マルチブートしたい場合はブートメニューを入れてねとお願いするだけで、非常に簡単です。



おや?なんかさっきと雰囲気違くね?と思ったら、どうやらMDPIの設定になっているようです。
ちなみにブートメニューはこんなん。

インストールしても、起動時にHDPIとMDPIを選べるようになっています。
ところで、USBフラッシュメモリ(SDカードの代わり)と有線LANモジュールはUSBハブ(バスパワード)につないで、それをクレードルにつないでいたのですが、なぜか有線LANが見えなくなっています(そしてメモリがAndroid起動時から挿していても認識するようになっている)。試しにクレードルに直に付けてみたのですが、やっぱり見えません。本体をクレードルから外し、直につなぐと認識しますが、ハブを噛ませると見えません。クレードルの中には(セルフパワードの)ハブが入っているであろうことを考えると、どうもハブを噛ませると認識できなくなってしまったようです。何で?ただ本体にはUSBポートが一つしかありませんので、メモリも同時に挿せないと困ります。こんなことなら仮想SDをSSDの中に作っておけばよかったよ。
カメラは動きませんが、どの道D4のカメラは役に立ちません。W-SIMは試してませんが動くわけないでしょう。あとワンセグも。Bluetoothは興味ないので試してませんが、ひょっとしたら動くかもしれませんね。まあその辺はどうでもいいんですが、一つ大きな問題が。
メニューキーがないんです。
通常PCにAndroidを入れた場合、キーボードのMenuキー、およびマウスのホイールボタンにメニューキーが割り当てられますが、D4にはWindowsキーはあるけどMenuキーもホイールボタンもありません。なので、Menuキーのあるキーボードか、ホイールのあるマウスを外付けしないと、検証用にもなりません。クレードル運用しかないんでしょうかねぇ。別のキーにアサインさせる方法あるのかなぁ。自分でビルドすればいいんだろうけど。
最後に、日本語のIMEは現時点でsimejiのx86版のみじゃないかと思います。作者に感謝です。(マーケットではなく)検索すると出てくると思います。あとESファイルエクスプローラーはインストールできませんでした。それから、ネイティブ解像度にするには、915Resolutionパッチを当ててうんぬんみたいな話を見つけましたが、自分でビルドしないといけないみたいなのでとりあえず今回は見送りです。興味のある方は…やり方教えてください。
スポンサーサイト

ファームアップ
なんかもうイラッときたので、ePadのファームをアップデートしてみました。
まずはこちら
xFlytouch 1.9_88 v0.4 [RUDROID] ROOT, MARKET, 400Mhz KERNEL
ベースなってるのは1.9だと思うので、現在の1.9.1_88と比べると、むしろバージョンダウンってことになるのかしら?







って感じで思いの他簡単にそれはもうあっけなく。ADW Launcherを始め、ホームが何種類かあらかじめ入っていて切り替えられるようになっているので、そういったアプリのインストールいらず。そしてsystem info見てみたら

CPUのクロック取れてました。Current Frequency 350MHzだそうで。これって、50MHzクロックアップされてるってことなのかな?あとFrequency range 50~400MHzとあるけど、特に負荷で変化する様子もない。なんだろう?
なんとなくタッチセンサの感度がよくなって、スライドがスムースになった気がしますね。ただ、無線LANが若干不安定になった気がしないでもないけど。
次はこちら
Flytouch 2.0_88 en rooted market
2.0のファーム(Android 2.0ではない)にrootとマーケットをつけたもの?






これもあっさり。ホームがちょっと変わりましたね。ただそれ以外は、うーん、別段コレといって。
次はコレと思ったのですが…
Slatedroid1.3-flytouch-editionscript-v2
1.7.4ベースと古いためか、再起動したところでブラックアウトしたままフリーズしてしまいました。まあいいか、古いしね。
最後はコレ
Flytouch 256M 1.9.1_fast_(350MHz)_furious: rooted,market,new kernel
オーバークロックがウリみたいですね。




有料なハズのSetCPUがバンドルされてるんですが…これが何かとよく落ちる。結局クロックは350MHzから変えられなかったみたいです。
感触としてはRUDROIDが一番よかったので、戻そうと思ったらアップ後にハングしたり、再度1.9.1_fast入れたらさっきと挙動が違ったり(でも結局クロックアップはできなかった)。三度RUDROID入れたら、今度はちゃんと動きました。一度で入らなくても、しつこく繰り返し入れたら動くようになることがあるみたいですね。Slatedroid1.3もしつこく入れたら動いたのかも。まあ面倒だからもういいや。
そうそう、途中で「データの初期化」をしてみましたが、現在入っているファームのインストール直後の状態にしか戻りませんでした。
まずはこちら
xFlytouch 1.9_88 v0.4 [RUDROID] ROOT, MARKET, 400Mhz KERNEL
ベースなってるのは1.9だと思うので、現在の1.9.1_88と比べると、むしろバージョンダウンってことになるのかしら?







って感じで思いの他簡単にそれはもうあっけなく。ADW Launcherを始め、ホームが何種類かあらかじめ入っていて切り替えられるようになっているので、そういったアプリのインストールいらず。そしてsystem info見てみたら

CPUのクロック取れてました。Current Frequency 350MHzだそうで。これって、50MHzクロックアップされてるってことなのかな?あとFrequency range 50~400MHzとあるけど、特に負荷で変化する様子もない。なんだろう?
なんとなくタッチセンサの感度がよくなって、スライドがスムースになった気がしますね。ただ、無線LANが若干不安定になった気がしないでもないけど。
次はこちら
Flytouch 2.0_88 en rooted market
2.0のファーム(Android 2.0ではない)にrootとマーケットをつけたもの?






これもあっさり。ホームがちょっと変わりましたね。ただそれ以外は、うーん、別段コレといって。
次はコレと思ったのですが…
Slatedroid1.3-flytouch-editionscript-v2
1.7.4ベースと古いためか、再起動したところでブラックアウトしたままフリーズしてしまいました。まあいいか、古いしね。
最後はコレ
Flytouch 256M 1.9.1_fast_(350MHz)_furious: rooted,market,new kernel
オーバークロックがウリみたいですね。




有料なハズのSetCPUがバンドルされてるんですが…これが何かとよく落ちる。結局クロックは350MHzから変えられなかったみたいです。
感触としてはRUDROIDが一番よかったので、戻そうと思ったらアップ後にハングしたり、再度1.9.1_fast入れたらさっきと挙動が違ったり(でも結局クロックアップはできなかった)。三度RUDROID入れたら、今度はちゃんと動きました。一度で入らなくても、しつこく繰り返し入れたら動くようになることがあるみたいですね。Slatedroid1.3もしつこく入れたら動いたのかも。まあ面倒だからもういいや。
そうそう、途中で「データの初期化」をしてみましたが、現在入っているファームのインストール直後の状態にしか戻りませんでした。

USB A-Aケーブル届きました
ePadのUSBコネクタはAコネクタで。PCとつなぐにはUSB A-Aケーブルが必要なワケですが。…まさかUSBケーブルの手持ちがないとか考えてなかったよね。そりゃA-Aケーブルとか普通使わないもん。
ってことでこれまではapkにパッケージして無線LANでアプリをインストールしてたんですが、ようやくA-Aケーブルが届いたので、つないでみることにしました。ドライバのディスクとか当たり前についてませんでしたし、探しても見つかりませんでしたが、MENUキーを押しっぱなしで起動したりしたらどうにかならないかな、と。
結論から言うと、どうにもなりませんでした。ドライバが、ではなく。そもそもPCが認識しません。不明なデバイスとも出ません。無反応です。何かがつながっているという認識がありません。門前払いもいいとこです。
30ピンのモデルならiPodと何かしら互換があるらしく、iPodのケーブルでUSBストレージとしては認識されるみたいな話ですが、うちのは24ピンなんでダメですし。てかダメでした。A-Aケーブル買う前に、iPodのUSBケーブル買ってきて、コネクタが違うことにそこで気づきました。
なので、完全にお手上げです。ムカついたので、腹いせにボックスを開けてみました。


まあコネクタ以外、部品らしい部品は載ってませんでしたが。
ちなみにマウスをつなぐとマウスカーソルが現れて、正常に動作してましたので、ボックスの不良ではないようです。どうもUSBホストとしての機能だけで、USBデバイスとしての機能は殺されてるか、元々持っていないかみたいですね。
ところでFactory Resetって、ファームまで元に戻るの?
ってことでこれまではapkにパッケージして無線LANでアプリをインストールしてたんですが、ようやくA-Aケーブルが届いたので、つないでみることにしました。ドライバのディスクとか当たり前についてませんでしたし、探しても見つかりませんでしたが、MENUキーを押しっぱなしで起動したりしたらどうにかならないかな、と。
結論から言うと、どうにもなりませんでした。ドライバが、ではなく。そもそもPCが認識しません。不明なデバイスとも出ません。無反応です。何かがつながっているという認識がありません。門前払いもいいとこです。
30ピンのモデルならiPodと何かしら互換があるらしく、iPodのケーブルでUSBストレージとしては認識されるみたいな話ですが、うちのは24ピンなんでダメですし。てかダメでした。A-Aケーブル買う前に、iPodのUSBケーブル買ってきて、コネクタが違うことにそこで気づきました。
なので、完全にお手上げです。ムカついたので、腹いせにボックスを開けてみました。


まあコネクタ以外、部品らしい部品は載ってませんでしたが。
ちなみにマウスをつなぐとマウスカーソルが現れて、正常に動作してましたので、ボックスの不良ではないようです。どうもUSBホストとしての機能だけで、USBデバイスとしての機能は殺されてるか、元々持っていないかみたいですね。
ところでFactory Resetって、ファームまで元に戻るの?

中華パッドクオリティ
例のePad、公称は600MHzだけど、どうも実は300MHzだったとかなんとか。ああ、…なんか納得。そんなに堂々とスペック詐称しちゃうんだ。さすが中華クオリティ。
300MHzならあの遅さも納得できるね。もっとも300MHzならあのバッテリの持たなさは異常だけど。やっぱ3000mAhも嘘だよな。たぶん1800mAhくらいじゃね?それとも周辺が食いすぎてんのかな。300MHzといえば、86系で言えばMMX PentiumかPentiumIIの頃か。SVGAのPentiumII搭載機、うん、なんかイメージできる。ちょうどそのくらいな気がする。
まあ検証機なんで多少遅い分には問題ないし、持ち出すことないからACつなぎっぱでいいんだけど、300MHzだと分かってたらさすがに1万円でも買わなかったかもなぁ。検証以外に使い道がなさすぎる。検証に飽きたらファーム入れ替えて遊んでみようと思ってるけど、Slatedroid1.3-flytouch-editionscript-v2とかでいいのかなぁ。

ただうちのってePadには違いないと思うんだけど、真ん中のコネクタの幅が狭い(24ピン?)んで、ちょっと不安なんだよね。今は1.9.1_88のファームが入ってるみたい。
300MHzならあの遅さも納得できるね。もっとも300MHzならあのバッテリの持たなさは異常だけど。やっぱ3000mAhも嘘だよな。たぶん1800mAhくらいじゃね?それとも周辺が食いすぎてんのかな。300MHzといえば、86系で言えばMMX PentiumかPentiumIIの頃か。SVGAのPentiumII搭載機、うん、なんかイメージできる。ちょうどそのくらいな気がする。
まあ検証機なんで多少遅い分には問題ないし、持ち出すことないからACつなぎっぱでいいんだけど、300MHzだと分かってたらさすがに1万円でも買わなかったかもなぁ。検証以外に使い道がなさすぎる。検証に飽きたらファーム入れ替えて遊んでみようと思ってるけど、Slatedroid1.3-flytouch-editionscript-v2とかでいいのかなぁ。

ただうちのってePadには違いないと思うんだけど、真ん中のコネクタの幅が狭い(24ピン?)んで、ちょっと不安なんだよね。今は1.9.1_88のファームが入ってるみたい。

Androidアプリ開発::加速度センサの謎
ePadには傾き(Orientation)センサが載っていません。なので、端末の回転を取るには加速度(Accelerometer)センサを使うことになります。ってか、傾きセンサの使用は非推奨になってしまっているようなので、傾きセンサが載っている端末でも、加速度センサを使うほうがいいみたい。
まずはSensorEventListenerを使って加速度センサからどんな値がやってくるのか調べてみました。3軸なので、配列にx軸、y軸、z軸方向の加速度が入ってくるはず。

…なんだコレ?
Landscapeの状態だとvalues[1](つまりy)に8.49…が、Portrait状態だとvalues[0](つまりx)に同じ固定値が入っているだけで、後は全部ゼロです。ついでに言うなら、Landscapeの逆さにしても、Portraitの逆さにしても、それぞれLandscapeとPortraitと同じ値で、マイナスにはなりません。
なのですが、そういやGravity sensor settingとかいうアプリがプリインストールされてたっけなと思い立ち、Game modeに変更し、再度試してみました。

なんかそれっぽい値が目まぐるしく小刻みに変化してます。写真も目まぐるしく変化しているっぽく撮れました。ではその状態で、端末を回してみましょうか。
まずはほぼLandscape(横向き)

次にほぼPortrait(縦向き)

…なんかおかしくないか?
フツーはPortraitの状態で、右向きがx、上向きがy、手前がzなんだけど

ePadではLandscapeの状態で、右向きがx、上向きがy、奥がzになってるみたいです。

端末情報に軸の向きとかの設定があるのかなと思ったけど、とくに見当たらず。調べたところ、中華パッドの一部は座標系が間違っているとかなんとか…
ありえねー。右手座標系ですらねーじゃんか。
ちなみにこのGame modeでは、自動縦横切り替えではPortrait位置にしてもPortrait表示になりません。その代わりというかなんというか、Portraitとは逆さの位置にすると、Portrait表示になります。もちろん逆さまですが。うん、間違いないね、機器の固有の仕様(笑)だね。ちなみにGravity sensor modeがNormal modeだと、Portrait位置でもその逆さまでもPortrait表示になるし、Landscapeも同様です。うん、マイナス値にならないようになっていたのはそういうワケだね。この座標系を、中華パッド座標系と呼ぶことにしましょう。もちろんIS03は正常なAndroid座標系でした。
とはいえ、市場にそういった製品があるのもまた事実。対応できるもんなら対応したいところです。なんとか判別できないかなと考え、z軸の向きが反対であることに着目しました。つまり画面が上を向いているときは、Android座標系ではzはプラス、中華パッド座標系ではマイナスになるワケです。寝転がって仰向けに操作している場合もあるかもしれませんが、加速度センサを使ったアプリを使おうって時には、なにか特殊なアプリでない限りは普通画面を上に向けますよね。なので、zがプラスのときはAndroid座標系端末、マイナスのときは中華パッド座標系端末という判断でいいんじゃないですかね?ダメですかね?
ということでサンプルを作ってみました。画面をくるくる回しても、常に頭が上になるようにドロイドを回転表示します。Android座標系と中華パッド座標系両方に対応しています。が、前述の中華パッド座標系とは異なる固有座標系を持つ端末は知りません。


ダウンロードはこちらから
しかし適当に買ったこのePad、期待してなかった(したくもなかった)トコで検証端末の実力を遺憾なく発揮してくれますねぇ。実機をこのePadしか持ってない人は絶叫モンですけど。
まずはSensorEventListenerを使って加速度センサからどんな値がやってくるのか調べてみました。3軸なので、配列にx軸、y軸、z軸方向の加速度が入ってくるはず。

…なんだコレ?
Landscapeの状態だとvalues[1](つまりy)に8.49…が、Portrait状態だとvalues[0](つまりx)に同じ固定値が入っているだけで、後は全部ゼロです。ついでに言うなら、Landscapeの逆さにしても、Portraitの逆さにしても、それぞれLandscapeとPortraitと同じ値で、マイナスにはなりません。
なのですが、そういやGravity sensor settingとかいうアプリがプリインストールされてたっけなと思い立ち、Game modeに変更し、再度試してみました。

なんかそれっぽい値が目まぐるしく小刻みに変化してます。写真も目まぐるしく変化しているっぽく撮れました。ではその状態で、端末を回してみましょうか。
まずはほぼLandscape(横向き)

次にほぼPortrait(縦向き)

…なんかおかしくないか?
フツーはPortraitの状態で、右向きがx、上向きがy、手前がzなんだけど

ePadではLandscapeの状態で、右向きがx、上向きがy、奥がzになってるみたいです。

端末情報に軸の向きとかの設定があるのかなと思ったけど、とくに見当たらず。調べたところ、中華パッドの一部は座標系が間違っているとかなんとか…
ありえねー。右手座標系ですらねーじゃんか。
ちなみにこのGame modeでは、自動縦横切り替えではPortrait位置にしてもPortrait表示になりません。その代わりというかなんというか、Portraitとは逆さの位置にすると、Portrait表示になります。もちろん逆さまですが。うん、間違いないね、機器の固有の仕様(笑)だね。ちなみにGravity sensor modeがNormal modeだと、Portrait位置でもその逆さまでもPortrait表示になるし、Landscapeも同様です。うん、マイナス値にならないようになっていたのはそういうワケだね。この座標系を、中華パッド座標系と呼ぶことにしましょう。もちろんIS03は正常なAndroid座標系でした。
とはいえ、市場にそういった製品があるのもまた事実。対応できるもんなら対応したいところです。なんとか判別できないかなと考え、z軸の向きが反対であることに着目しました。つまり画面が上を向いているときは、Android座標系ではzはプラス、中華パッド座標系ではマイナスになるワケです。寝転がって仰向けに操作している場合もあるかもしれませんが、加速度センサを使ったアプリを使おうって時には、なにか特殊なアプリでない限りは普通画面を上に向けますよね。なので、zがプラスのときはAndroid座標系端末、マイナスのときは中華パッド座標系端末という判断でいいんじゃないですかね?ダメですかね?
ということでサンプルを作ってみました。画面をくるくる回しても、常に頭が上になるようにドロイドを回転表示します。Android座標系と中華パッド座標系両方に対応しています。が、前述の中華パッド座標系とは異なる固有座標系を持つ端末は知りません。


ダウンロードはこちらから
しかし適当に買ったこのePad、期待してなかった(したくもなかった)トコで検証端末の実力を遺憾なく発揮してくれますねぇ。実機をこのePadしか持ってない人は絶叫モンですけど。

Androidアプリ開発::Densityの話
前回のエントリで使ったアプリと関連します。なんでIS03では表示したドロイドがePadよりも大きな(ピクセル数的に)表示になってしまったのかってこと。Androidはスケーラブル、って表現が正しいのかわかんないけど、そんな設計になってます。どういうことかって言うと、どんな画面サイズでどんな解像度の端末でも、表示されるモノの物理的な寸法は(ほぼ)同じにしようよってことです。IS03の方が画面が小さく解像度も高いのに、IS03で表示されたドロイドも、ePadで表示されたドロイドも、定規で大きさを測ってみるとほぼ同じになるように表示されてたんです。
その辺の判断の指標になるのが、Density(dpi)です。IS03は320dpi(厳密にはもう少し大きいけど、端末的にそういうことになっているみたい)、ePadは160dpiです。もう少し言うならば、Androidの基準になっているDensityは160dpiです。なので、160dpiの画像しか用意していない場合、もし違うDensityの端末だと、それに合わせて適当に伸縮されてしまいます。つまりIS03だと、縦横二倍に拡大されて読み込まれるんです。
拡大縮小するんではなく、それぞれのDensityに合わせた適切な画像を用意したいって場合は、APIレベル4(Android 1.6)から対応したようです。前述のレベル以上でEclipseプロジェクトを作った場合、resフォルダの中に、
drawable-ldpi
drawable-mdpi
drawable-hdpi
という3つのフォルダができます。それぞれ120dpi、160dpi、240dpiに対応していて、同じ名前でファイルを入れておくと、システムが最適なDensityのファイルを取ってきてくれるという仕組みになってます(単にdrawableという名前のフォルダだと、基準である160dpi扱いになるようです)。ここでもし240dpiの端末で、hdpiのファイルがなかったら、mdpiのファイルを240/160=3/2倍して使われます。
ではIS03ではどうでしょう。320dpiというDensityは該当がありません。試してみたところ、hdpiのものが320/240=4/3倍されていました。hdpiがなければ、mdpiを320/160=2倍して使われます。そこで、適当になんとなく
drawable-xhdpi
というフォルダを作って画像を入れたところ、スケーリングなくドンピシャで表示されました。320dpi端末はxhdpiということのようです。
そこで話は戻りますが、前回のアプリやゲームなどでは、勝手にスケーリングしてくれんなよ、ということは少なくないと思います。全てのフォルダに同じファイルを突っ込んでおくのも手ですが、容量のムダですし、将来的にxhdpiを超えるsxhdpiとかuxhdpiとか、あるいは反対にxldpiとかも出てこないとは限りません。そんな場合には、
drawable-nodpi
というフォルダを作っておくと、その中のファイルは端末Densityによらず、実寸でロードされるようです(API レベル4以上)。
おさらい
API レベル4(Android 1.6)以上では、リソースから画像を読む場合、端末のDensityに合わせて以下のフォルダから画像が選択される。もし該当する画像がない場合は、それ以外のDensityの画像からDensityに合わせて拡大縮小される。
drawable 160dpi
drawable-ldpi 120dpi
drawable-mdpi 160dpi
drawable-hdpi 240dpi
drawable-xhdpi 320dpi
drawable-nodpi Density非依存
ちなみにIS03は、APIレベル3のアプリからだと、HVGA(320x480)のmdpi端末と認識されます。こういう状況であれば、Android 1.5は切り捨てちゃおーぜ、というのは仕方がないかもしれませんね。ePad選択時にAndroid 1.6を基準にしておいて正解だったかな。
その辺の判断の指標になるのが、Density(dpi)です。IS03は320dpi(厳密にはもう少し大きいけど、端末的にそういうことになっているみたい)、ePadは160dpiです。もう少し言うならば、Androidの基準になっているDensityは160dpiです。なので、160dpiの画像しか用意していない場合、もし違うDensityの端末だと、それに合わせて適当に伸縮されてしまいます。つまりIS03だと、縦横二倍に拡大されて読み込まれるんです。
拡大縮小するんではなく、それぞれのDensityに合わせた適切な画像を用意したいって場合は、APIレベル4(Android 1.6)から対応したようです。前述のレベル以上でEclipseプロジェクトを作った場合、resフォルダの中に、
drawable-ldpi
drawable-mdpi
drawable-hdpi
という3つのフォルダができます。それぞれ120dpi、160dpi、240dpiに対応していて、同じ名前でファイルを入れておくと、システムが最適なDensityのファイルを取ってきてくれるという仕組みになってます(単にdrawableという名前のフォルダだと、基準である160dpi扱いになるようです)。ここでもし240dpiの端末で、hdpiのファイルがなかったら、mdpiのファイルを240/160=3/2倍して使われます。
ではIS03ではどうでしょう。320dpiというDensityは該当がありません。試してみたところ、hdpiのものが320/240=4/3倍されていました。hdpiがなければ、mdpiを320/160=2倍して使われます。そこで、適当になんとなく
drawable-xhdpi
というフォルダを作って画像を入れたところ、スケーリングなくドンピシャで表示されました。320dpi端末はxhdpiということのようです。
そこで話は戻りますが、前回のアプリやゲームなどでは、勝手にスケーリングしてくれんなよ、ということは少なくないと思います。全てのフォルダに同じファイルを突っ込んでおくのも手ですが、容量のムダですし、将来的にxhdpiを超えるsxhdpiとかuxhdpiとか、あるいは反対にxldpiとかも出てこないとは限りません。そんな場合には、
drawable-nodpi
というフォルダを作っておくと、その中のファイルは端末Densityによらず、実寸でロードされるようです(API レベル4以上)。
おさらい
API レベル4(Android 1.6)以上では、リソースから画像を読む場合、端末のDensityに合わせて以下のフォルダから画像が選択される。もし該当する画像がない場合は、それ以外のDensityの画像からDensityに合わせて拡大縮小される。
drawable 160dpi
drawable-ldpi 120dpi
drawable-mdpi 160dpi
drawable-hdpi 240dpi
drawable-xhdpi 320dpi
drawable-nodpi Density非依存
ちなみにIS03は、APIレベル3のアプリからだと、HVGA(320x480)のmdpi端末と認識されます。こういう状況であれば、Android 1.5は切り捨てちゃおーぜ、というのは仕方がないかもしれませんね。ePad選択時にAndroid 1.6を基準にしておいて正解だったかな。

Androidアプリ開発::drawBitmap考察
前回のエントリの最後に追記として、ePadはPortraitよりもLandscapeの方が動作が速い、と書きました。より正確には、画面描画が速い、ということだと思います。そこで、描画速度を計測する簡単なアプリを作ってみました。


SurfaceViewを構築し、そこに100回画像を貼り付けて表示する時間を計測し、フレームレートを計算します。SurfaceViewはダブルバッファリングをシステムがやってくれるそうで、二枚のプレーンに交互に描いて表示する関係でちらつきますが、今回の趣旨とは関係ないのでそれは放置します。何を言ってるのか分からない人は、最後に今回のアプリのURLを貼っておきますので、自分で試してみてください。
上の写真の左がLandscapeでの結果、右がPortraitでの結果です。余談ですが、IS03はメモリ液晶に表示されたアイコンの向きで、今端末がLandscape状態なのかPortrait状態なのか分かります。それだけではナンですので、端末はLandscapeなのに画像を反時計回りに90度回転させて貼り付けることでPortraitに見せかけるもの(Portrait Fake)と、その反対にPortraitでLandscapeに見せかけるもの(Landscape Fake)も作ってみました。まずはIS03の結果から。それぞれ2回計測しました。
Landscape


一回目:28.91 fps 二回目:29.73 fps
Portrait


一回目:31.97 fps 二回目:33.15 fps
Portrait Fake


一回目:29.07 fps 二回目:29.43 fps
Landscape Fake


一回目:28.69 fps 二回目:33.03 fps
IS03はLandscapeよりもPortraitの方が、ほんの僅かに速いようですが、ほぼ誤差の範囲です。回転させることによる速度低下も、誤差程度しか見受けられません。
これを踏まえた上で、ePadを試してみましょう。こちらは3回ずつ計測しています。
Landscape



一回目:32.08 fps 二回目:32.89 fps 三回目:31.87 fps
意外なことに、IS03のPortraitとほぼ同じ値を出しています。と言いたいところですが、明らかにIS03よりもドロイドの密度が低い。どうやら画面サイズに対して、ドロイドが小さく表示されているようです。IS03の方が解像度は高いのに。うすうすは気が付いていたのですが、どうもAndroidはそのまま画像を貼ったつもりでも、dpiに合せて適当なサイズに変えられてしまうようですね。まあその辺は後々ということで、今回はIS03とePadの直接比較は参考程度にしておいてください。
Portrait



一回目:7.59 fps 二回目:7.72 fps 三回目:7.51 fps
さて問題のPortraitですが…想像以上にヒドいですね。これでUIをスクロールしようとか、カクカクもいいとこです。想像ですがこの遅さは、ビデオチップだかDACだかが本来ピボットに対応してないところを、OS側が無理やりソフトウェア側でVRAMを横にして描画してるんじゃないかと。この端末はPortraitで使っちゃいけないというのがよく分かります。
そこで、縦長の画面として使いたい場合でも、Landscapeのまま回転させて描いてみればいいじゃんってのが次なんですが…
Portrait Fake



一回目:27.20 fps 二回目:31.93 fps 三回目:30.94 fps
Portraitよりも圧倒的に速く、Landscapeと比べても回転による速度低下はほんの僅かで描画できました。一度にたくさん描画したり、もっと大きな画像を描画した場合は多少変わってくるでしょうが、それでもPortraitよりも、Landscapeで回転させた方が速くなるという状況は少なくないのが分かると思います。
Landscape Fake



一回目:6.86 fps 二回目:6.90 fps 三回目:7.19 fps
こうなってしまっては意味はありませんが一応。なまじ回転による速度低下が僅かなところがますます切なくなります。
まっとうなメーカーが作った製品ならここまでヒドいことはないとは思いますし、あるいはファームによっても違うのかもしれませんが、ここまでLandscapeとPortraitで描画速度の違いがある端末が世にあるってのは事実なワケで。たまたまePadはLandscapeがPortraitよりも圧倒的に速かったけれど、反対の製品もひょっとしたらあるかもしれないんです。現にIS03は誤差程度ですがPortraitの方が速いし。なのでアプリ側としては、初回起動時にLandscapeとPortraitで描画速度を計測して、あまりにも速度差が大きい場合はそれを考慮して速い方の向きと回転で対処させるのが親切かもしれません。面倒だけど。
尚、ePadの激遅状態を除いてフレームレートが30 fps前後に集中しているのは、ダブルバッファリングの切り替えタイミングと液晶のリフレッシュレートの関係じゃないかと思います。なので、あまり細かい数値の違いは参考にならないかもしれません。
ダウンロード
DrawBitmapOrientationTest apk(PCからのダウンロードは拡張子がzipになる場合がありますので、apkに直してください)
DrawBitmapOrientationTest ソース(Eclipseプロジェクト)


SurfaceViewを構築し、そこに100回画像を貼り付けて表示する時間を計測し、フレームレートを計算します。SurfaceViewはダブルバッファリングをシステムがやってくれるそうで、二枚のプレーンに交互に描いて表示する関係でちらつきますが、今回の趣旨とは関係ないのでそれは放置します。何を言ってるのか分からない人は、最後に今回のアプリのURLを貼っておきますので、自分で試してみてください。
上の写真の左がLandscapeでの結果、右がPortraitでの結果です。余談ですが、IS03はメモリ液晶に表示されたアイコンの向きで、今端末がLandscape状態なのかPortrait状態なのか分かります。それだけではナンですので、端末はLandscapeなのに画像を反時計回りに90度回転させて貼り付けることでPortraitに見せかけるもの(Portrait Fake)と、その反対にPortraitでLandscapeに見せかけるもの(Landscape Fake)も作ってみました。まずはIS03の結果から。それぞれ2回計測しました。
Landscape


一回目:28.91 fps 二回目:29.73 fps
Portrait


一回目:31.97 fps 二回目:33.15 fps
Portrait Fake


一回目:29.07 fps 二回目:29.43 fps
Landscape Fake


一回目:28.69 fps 二回目:33.03 fps
IS03はLandscapeよりもPortraitの方が、ほんの僅かに速いようですが、ほぼ誤差の範囲です。回転させることによる速度低下も、誤差程度しか見受けられません。
これを踏まえた上で、ePadを試してみましょう。こちらは3回ずつ計測しています。
Landscape



一回目:32.08 fps 二回目:32.89 fps 三回目:31.87 fps
意外なことに、IS03のPortraitとほぼ同じ値を出しています。と言いたいところですが、明らかにIS03よりもドロイドの密度が低い。どうやら画面サイズに対して、ドロイドが小さく表示されているようです。IS03の方が解像度は高いのに。うすうすは気が付いていたのですが、どうもAndroidはそのまま画像を貼ったつもりでも、dpiに合せて適当なサイズに変えられてしまうようですね。まあその辺は後々ということで、今回はIS03とePadの直接比較は参考程度にしておいてください。
Portrait



一回目:7.59 fps 二回目:7.72 fps 三回目:7.51 fps
さて問題のPortraitですが…想像以上にヒドいですね。これでUIをスクロールしようとか、カクカクもいいとこです。想像ですがこの遅さは、ビデオチップだかDACだかが本来ピボットに対応してないところを、OS側が無理やりソフトウェア側でVRAMを横にして描画してるんじゃないかと。この端末はPortraitで使っちゃいけないというのがよく分かります。
そこで、縦長の画面として使いたい場合でも、Landscapeのまま回転させて描いてみればいいじゃんってのが次なんですが…
Portrait Fake



一回目:27.20 fps 二回目:31.93 fps 三回目:30.94 fps
Portraitよりも圧倒的に速く、Landscapeと比べても回転による速度低下はほんの僅かで描画できました。一度にたくさん描画したり、もっと大きな画像を描画した場合は多少変わってくるでしょうが、それでもPortraitよりも、Landscapeで回転させた方が速くなるという状況は少なくないのが分かると思います。
Landscape Fake



一回目:6.86 fps 二回目:6.90 fps 三回目:7.19 fps
こうなってしまっては意味はありませんが一応。なまじ回転による速度低下が僅かなところがますます切なくなります。
まっとうなメーカーが作った製品ならここまでヒドいことはないとは思いますし、あるいはファームによっても違うのかもしれませんが、ここまでLandscapeとPortraitで描画速度の違いがある端末が世にあるってのは事実なワケで。たまたまePadはLandscapeがPortraitよりも圧倒的に速かったけれど、反対の製品もひょっとしたらあるかもしれないんです。現にIS03は誤差程度ですがPortraitの方が速いし。なのでアプリ側としては、初回起動時にLandscapeとPortraitで描画速度を計測して、あまりにも速度差が大きい場合はそれを考慮して速い方の向きと回転で対処させるのが親切かもしれません。面倒だけど。
尚、ePadの激遅状態を除いてフレームレートが30 fps前後に集中しているのは、ダブルバッファリングの切り替えタイミングと液晶のリフレッシュレートの関係じゃないかと思います。なので、あまり細かい数値の違いは参考にならないかもしれません。
ダウンロード
DrawBitmapOrientationTest apk(PCからのダウンロードは拡張子がzipになる場合がありますので、apkに直してください)
DrawBitmapOrientationTest ソース(Eclipseプロジェクト)

ePad導入しました
開発検証用にもう一台何か欲しいかなと思いまして。検証用だからむしろスペックは低くて安いのがいい、でもAndroid 1.6は欲しい、IS03とは方向性が違う端末がいい、などなど。
で、白羽の矢が立ったのが、何かと話題の中華タブレットePadだったのでした。送料込みで10,380円。実際はほとんど値段で決めたんだけど。
ショップによるとスペックは
Android 1.6
ファーム:1.9.1_88
CPU:600MHz
ディスク:2GB(約1GBはシステムに使用)
メモリ:256MB
ディスプレイ:7インチTFT液晶タッチパネル 解像度:800 * 480px
電池容量:3000mAh
重量:332g
とのこと。もう一台EKENのM003も候補に残ったんだけど、そっちはメモリが128MBだったので。さすがに128MBではキビしそう。
で、届いたのがコレ。

箱にはiRobotと書いてあるだけ。薄いマニュアルは入ってるけど、型番はおろかメーカー名すら書いてない。ってかePadとも書いてない。いやまあePadには違いないと思うけど、どうもOEMをショップがファーム書き換えたりちょっといじって、いわゆるショップブランドなタブレットってことみたいです。
なんとなくIS03と大きさ比較。

液晶は特にムラもなく、この手のこの価格帯の製品にしてはマトモではないかと。ただ、タッチセンサが感圧式なので、独特の一枚膜が張ったような質感です。当然マルチタッチには対応していません。ただ、感圧式は感圧式で特にスタイラスを選ばないので、便利な時もあります。ご飯食べながら箸の頭で操作するとか。少し強めに押さないと反応しないけど、それはまあ、慣れかなぁ。
まあ案の定というかなんというか、Android Marketは入っておらず。root取ってAndroid Market入れたりとかするほどでもないし(やり方調べるのもメンド臭いし)、かといってapkをSDカードに入れてセコセコアプリ入れるのも手間だし。ということで、Black Marketというアプリを使ってみた。まあ名前の通りブラック、というほどでもないけどグレーなアプリなんで、気になる人は自分で調べてください。
ということでAndroid System Infoというアプリで情報を見てみました。


うーん…ディスクが公称より気持ち少ないけど…おおむねこんなもんか。ただ、CPUのクロックが取れてませんねぇ。ってかここまで触った感じ、恐ろしく重いんですが。ホントに600MHzもあるのかなぁ。IS03の1GHzと比べると、クロックでだけだけど体感的に3~400MHzくらいに感じるんだけど。まあCPUの世代も違うし、周辺も違うし、OSのバージョンも違うし、なんともだけど。
ところで、Android買ったらまずホームアプリを入れろとか言われている理由がようやくわかりました。IS03は別に普通に便利に使えるよ?ホームアプリとか必要ないよ?と思っていたのですが、あれは想像していた以上にかなりSHARPが使いやすくカスタマイズしてたからなんですね。デフォルトのホームを使ってみて、そりゃまずはホームをどうにかしないと使う気にならんわ、というのがよく分かりました。
なので評判のいいADW Launcherというのを入れようと思ったのですが、なぜかインストールできない。調べていたところ、どうも前述のアプリは1.6版と2.0以降版があるらしく、Android Marketには2.0版しか見当たらない。廃版になっちゃったのかしら?とあちこち探して、ようやく見つけました。1.6版のver.0.6.999999.2というのを。なんとかそれをインストールしてみたら…

アイコンが初期と比べて小さくなってさびしくなっちゃった…
まあ…いいんだけど…
ところでこの端末、一応加速度センサは載ってるんだけど、なんというか、反応が非常によろしくない。画面の縦横自動切換え設定にしても、3回に1回くらい認識してくれない(個体差かもしれませんが)。例えば縦から横にして切り替わらなかった場合、横にしたまま揺すっても遅れて切り替わるとかなく、一旦縦に戻してからまた横にしないと切り替わらない。というか、加速度センサと傾きセンサってハードウェア的には同じものだと思ってたんだけど、ひょっとして違うの?こいつには加速度センサしか付いてないっぽい。かと言って縦横切り替えを手動ににすると、縦位置でアプリを立ち上げても横位置で起動される。なんでやねん。あとスタンバイに落ちるたびにSDカードが一旦切り離されるのはいかがなものか。
そしてバッテリーがヒドい。バックライト輝度抑えてもあっという間になくなる。普通に使ってると1時間くらいじゃ?かと思うと電源繋ぐとあっという間に充電される。いやいや、3000mAhのバッテリーを充電してる早さじゃないだろ、コレ。まあバッテリー残量表示の方が間違ってるという可能性もあるけど。一度電源入れっぱなしで放置してみようか。
ちなみにコイツはUSB×2+RJ45の付いた付属モジュールを取り付けると有線LANにも繋がる。逆に言えば、モジュールを取り付けないと、本体にはUSBコネクタがない。しかもこのコネクタ、付け根をぽっきりやっちゃいそうで恐い。通常は無線LANがあればUSBもそんなに使うことはないってことなんだろうけど、開発の検証端末となると必須なんだよねぇ。microUSBでもいいからせめて本体に一口はつけておいて欲しいよなぁ。
まあ正直言って、激遅です。サクサクとかモッサリとかの評価レベルの範疇ではありませんね。日本では民生機としてはあり得ない遅さです。1万円の中国製と割り切っていたとしても、割とフツーに使おうと思って買った人だと激怒するレベルです。いやホント、さすがにここまで重いとは思わなかったよ。
ところで、せっかく買うんだから開発検証以外に何か用途はないかなーと思っていたら、こんなものがありました。
Komado Android端末がWindowsマシンのサブモニタに
ノートのサブモニタにできれば便利!と思ったのですが、Windows vista/7ではクローン表示しかできないとのこと。うーん、それではあまりイミが…
一応試してはみましたよ。少し遅れますし、レートは5fpsくらい?ですが、しっかり映りました。大きなモニタのクローンだと、仮想デスクトップみたいになって、スライドでスクロールします。
追記:
ああ、なんとなく分かりました。縦長の表示よりも横長の表示の時の方が、体感できるくらい速度が速くなりますね。横位置でなら、お世辞にも速いとは言えませんが、なんとか実用になるくらいの速度にはなるのかもしれません。それでこの端末はやたらと横位置で操作させたがってたのか。
で、白羽の矢が立ったのが、何かと話題の中華タブレットePadだったのでした。送料込みで10,380円。実際はほとんど値段で決めたんだけど。
ショップによるとスペックは
Android 1.6
ファーム:1.9.1_88
CPU:600MHz
ディスク:2GB(約1GBはシステムに使用)
メモリ:256MB
ディスプレイ:7インチTFT液晶タッチパネル 解像度:800 * 480px
電池容量:3000mAh
重量:332g
とのこと。もう一台EKENのM003も候補に残ったんだけど、そっちはメモリが128MBだったので。さすがに128MBではキビしそう。
で、届いたのがコレ。

箱にはiRobotと書いてあるだけ。薄いマニュアルは入ってるけど、型番はおろかメーカー名すら書いてない。ってかePadとも書いてない。いやまあePadには違いないと思うけど、どうもOEMをショップがファーム書き換えたりちょっといじって、いわゆるショップブランドなタブレットってことみたいです。
なんとなくIS03と大きさ比較。

液晶は特にムラもなく、この手のこの価格帯の製品にしてはマトモではないかと。ただ、タッチセンサが感圧式なので、独特の一枚膜が張ったような質感です。当然マルチタッチには対応していません。ただ、感圧式は感圧式で特にスタイラスを選ばないので、便利な時もあります。ご飯食べながら箸の頭で操作するとか。少し強めに押さないと反応しないけど、それはまあ、慣れかなぁ。
まあ案の定というかなんというか、Android Marketは入っておらず。root取ってAndroid Market入れたりとかするほどでもないし(やり方調べるのもメンド臭いし)、かといってapkをSDカードに入れてセコセコアプリ入れるのも手間だし。ということで、Black Marketというアプリを使ってみた。まあ名前の通りブラック、というほどでもないけどグレーなアプリなんで、気になる人は自分で調べてください。
ということでAndroid System Infoというアプリで情報を見てみました。


うーん…ディスクが公称より気持ち少ないけど…おおむねこんなもんか。ただ、CPUのクロックが取れてませんねぇ。ってかここまで触った感じ、恐ろしく重いんですが。ホントに600MHzもあるのかなぁ。IS03の1GHzと比べると、クロックでだけだけど体感的に3~400MHzくらいに感じるんだけど。まあCPUの世代も違うし、周辺も違うし、OSのバージョンも違うし、なんともだけど。
ところで、Android買ったらまずホームアプリを入れろとか言われている理由がようやくわかりました。IS03は別に普通に便利に使えるよ?ホームアプリとか必要ないよ?と思っていたのですが、あれは想像していた以上にかなりSHARPが使いやすくカスタマイズしてたからなんですね。デフォルトのホームを使ってみて、そりゃまずはホームをどうにかしないと使う気にならんわ、というのがよく分かりました。
なので評判のいいADW Launcherというのを入れようと思ったのですが、なぜかインストールできない。調べていたところ、どうも前述のアプリは1.6版と2.0以降版があるらしく、Android Marketには2.0版しか見当たらない。廃版になっちゃったのかしら?とあちこち探して、ようやく見つけました。1.6版のver.0.6.999999.2というのを。なんとかそれをインストールしてみたら…

アイコンが初期と比べて小さくなってさびしくなっちゃった…
まあ…いいんだけど…
ところでこの端末、一応加速度センサは載ってるんだけど、なんというか、反応が非常によろしくない。画面の縦横自動切換え設定にしても、3回に1回くらい認識してくれない(個体差かもしれませんが)。例えば縦から横にして切り替わらなかった場合、横にしたまま揺すっても遅れて切り替わるとかなく、一旦縦に戻してからまた横にしないと切り替わらない。というか、加速度センサと傾きセンサってハードウェア的には同じものだと思ってたんだけど、ひょっとして違うの?こいつには加速度センサしか付いてないっぽい。かと言って縦横切り替えを手動ににすると、縦位置でアプリを立ち上げても横位置で起動される。なんでやねん。あとスタンバイに落ちるたびにSDカードが一旦切り離されるのはいかがなものか。
そしてバッテリーがヒドい。バックライト輝度抑えてもあっという間になくなる。普通に使ってると1時間くらいじゃ?かと思うと電源繋ぐとあっという間に充電される。いやいや、3000mAhのバッテリーを充電してる早さじゃないだろ、コレ。まあバッテリー残量表示の方が間違ってるという可能性もあるけど。一度電源入れっぱなしで放置してみようか。
ちなみにコイツはUSB×2+RJ45の付いた付属モジュールを取り付けると有線LANにも繋がる。逆に言えば、モジュールを取り付けないと、本体にはUSBコネクタがない。しかもこのコネクタ、付け根をぽっきりやっちゃいそうで恐い。通常は無線LANがあればUSBもそんなに使うことはないってことなんだろうけど、開発の検証端末となると必須なんだよねぇ。microUSBでもいいからせめて本体に一口はつけておいて欲しいよなぁ。
まあ正直言って、激遅です。サクサクとかモッサリとかの評価レベルの範疇ではありませんね。日本では民生機としてはあり得ない遅さです。1万円の中国製と割り切っていたとしても、割とフツーに使おうと思って買った人だと激怒するレベルです。いやホント、さすがにここまで重いとは思わなかったよ。
ところで、せっかく買うんだから開発検証以外に何か用途はないかなーと思っていたら、こんなものがありました。
Komado Android端末がWindowsマシンのサブモニタに
ノートのサブモニタにできれば便利!と思ったのですが、Windows vista/7ではクローン表示しかできないとのこと。うーん、それではあまりイミが…
一応試してはみましたよ。少し遅れますし、レートは5fpsくらい?ですが、しっかり映りました。大きなモニタのクローンだと、仮想デスクトップみたいになって、スライドでスクロールします。
追記:
ああ、なんとなく分かりました。縦長の表示よりも横長の表示の時の方が、体感できるくらい速度が速くなりますね。横位置でなら、お世辞にも速いとは言えませんが、なんとか実用になるくらいの速度にはなるのかもしれません。それでこの端末はやたらと横位置で操作させたがってたのか。

Androidアプリ開発::Orientation(画面縦横の向き)の話
何も考えずに作ったAndroidアプリは、加速度センサの載ったAndroid端末では、くるっと回すと勝手に表示が縦になったり横になったりします。あるいは加速度センサが載ってない端末なら縦横切り替えボタンとか。当然開発側としては、縦長表示(Portrait)と横長表示(Landscape)ではレイアウトをそれに合わせて変えたいとも思うわけですが、res/layoutの中のxml、デフォルトのアクティビティならmain.xmlを、それぞれres/layout-portとres/layout-landというフォルダを作ってその中に入れてやれば、OS側が勝手に端末の向きを判断して、適切なフォルダに入っている方のレイアウトを読みに行ってくれるという至れり尽くせりぶりとなっています。実際には、例えば縦表示時にlayout-portがなければデフォルトのlayoutを読みに行きますので、新たに作るフォルダはどちらか片方でいいでしょう。ちなみにAndroidの設定としては、正方形(Square)というのもあるようですが、そんな実機は存在するんでしょうかね?
ただ、これだけで安心して開発を進めてしまうと、後で困ったことになる場合があります。というのは、縦横が切り替えられた際には、標準では「何かしら端末の設定が変わった」と見なされて、アクティビティが一旦破棄されて、作り直されるからです。単一アクティビティのアプリであれば、アプリを再起動したに等しいことになり、保存されていない情報は全てイニシャライズされてしまいます。よほど単純なアプリでない限り、これでは困ってしまいます。
OS側に勝手に処理されないようにするには、マニュフェストの設定が必要となります。Eclipse上、AndroidManifest.xmlのアプリケーションタブを開くと、Application Nodesとして、そのアプリで定義されているアクティビティが一覧されます。その中から対象となるアクティビティを選ぶと、その右にAttributesが表示されますので、その中のConfig changesにorientationを設定してください(隠れていて気づきにくいかもしれませんがスクロールさせてください)。これで、縦横(Orientation)の設定が変わったら(Config changes)、OSが勝手に処理をせずにアプリケーション(正確にはアクティビティ)に知らせる、という設定になりました。
ただし、このままではOSが勝手に処理しない代わりに、アクティビティに通知するだけで今度は何もしれくれません。ので、アクティビティに、設定が変わった際に呼ばれる以下の関数を追加し、レイアウトの再設定を行います。
ところで、これならアクティビティは破棄されませんが、レイアウトは破棄されて作り直されていますので、その中のビューは結局イニシャライズされることになります。なので、ビューの中には必要な情報は保管しないか、レイアウトの読み直しの前に情報をサルベージしておくなどの工夫が必要になります。
尚、マニュフェストのConfig changesの上、Screen orientationにlandscapeかportraitを設定することで、そのアクティビティが表示中はOrientationを固定することもできます。
ちなみにエミュレータの縦横切り替えはCtrl+F12です。
ただ、これだけで安心して開発を進めてしまうと、後で困ったことになる場合があります。というのは、縦横が切り替えられた際には、標準では「何かしら端末の設定が変わった」と見なされて、アクティビティが一旦破棄されて、作り直されるからです。単一アクティビティのアプリであれば、アプリを再起動したに等しいことになり、保存されていない情報は全てイニシャライズされてしまいます。よほど単純なアプリでない限り、これでは困ってしまいます。
OS側に勝手に処理されないようにするには、マニュフェストの設定が必要となります。Eclipse上、AndroidManifest.xmlのアプリケーションタブを開くと、Application Nodesとして、そのアプリで定義されているアクティビティが一覧されます。その中から対象となるアクティビティを選ぶと、その右にAttributesが表示されますので、その中のConfig changesにorientationを設定してください(隠れていて気づきにくいかもしれませんがスクロールさせてください)。これで、縦横(Orientation)の設定が変わったら(Config changes)、OSが勝手に処理をせずにアプリケーション(正確にはアクティビティ)に知らせる、という設定になりました。
ただし、このままではOSが勝手に処理しない代わりに、アクティビティに通知するだけで今度は何もしれくれません。ので、アクティビティに、設定が変わった際に呼ばれる以下の関数を追加し、レイアウトの再設定を行います。
このように記述することで、縦横が切り替わった際には、アクティビティ自体は破棄せずに、レイアウトだけを再設定することができます。レイアウトの読み込み自体は、縦横適切なものが自動で読まれます。
public void onConfigurationChanged( Configuration newConfig ){
super.onConfigurationChanged( newConfig );
setContentView( R.layout.main );
}
ところで、これならアクティビティは破棄されませんが、レイアウトは破棄されて作り直されていますので、その中のビューは結局イニシャライズされることになります。なので、ビューの中には必要な情報は保管しないか、レイアウトの読み直しの前に情報をサルベージしておくなどの工夫が必要になります。
尚、マニュフェストのConfig changesの上、Screen orientationにlandscapeかportraitを設定することで、そのアクティビティが表示中はOrientationを固定することもできます。
ちなみにエミュレータの縦横切り替えはCtrl+F12です。

Androidアプリ開発はじめました
まだ始めて一週間ちょっとですが、気になった点をぽつらぽつら書いていこうかと。幸いJavaには昔取った杵柄でそこそこ馴染みがありますので。
環境のインストールとかは他の詳しいサイトなりにまかせます。うちの環境は以下の通り。
Eclipse Helios SR1 (Pleiades 1.3.2で日本語化済み)
JDK 1.6.0_23
Android SDK R8
実機:au IS03
環境のインストールとかは他の詳しいサイトなりにまかせます。うちの環境は以下の通り。
Eclipse Helios SR1 (Pleiades 1.3.2で日本語化済み)
JDK 1.6.0_23
Android SDK R8
実機:au IS03
- ●SDKのサンプルApiDemoが動かないよ
まあたいていの人が、環境をインストールしたらまず開いてみるサンプルだと思うんですが、間の悪いことにそのままでは動きません(ターゲットAPIレベルが4以下のもの)。Eclipseはどこに問題があるのか比較的分かりやすく示してくれるのですが、それによるとres/values/strings.xmlの中に問題があると言われると思います。ですので、このファイルを開いて、問題がある箇所のシングルクオート「'」を、\(半角の¥)でエスケープして「\'」として保存してください。これで問題はなくなるはずです。ひょっとしてEclipse側に「シングルクオートはエスケープせんでもかまへんで」オプションとかあるのかもしれませんが、エスケープしなくて怒られることはあっても、して怒られることはないので、エスケープしておきましょう。- ●ネットで探したサンプルが動かないよ
古いAndroid SDKで作られたプロジェクトは、そのままでは動かない場合があるようです。どうやら以前はAndroid Vertual Device(以下AVD)の設定がなかったようで、そのために読み込んでもどこに問題があるのか適切に示してくれません。しかも「Android SDK および AVD マネージャー」からAVDを設定しても、その設定を記憶してくれません。これはプロジェクト内にdefault.propertiesというファイルがないことが原因ですので、適当に作ったプロジェクトからそのファイルをコピーし、AVDを適切に設定し直すことで問題が解決するようです。- ●@ITの連載「Androidアプリ作成入門」の「SurfaceViewならAndroidで高速描画ゲームが作れる」のサンプルで、SurfaceViewとBitmapDrawableを使ったGame Sampleを動かすとブラックアウトする・固まる・落ちるよ
いきなり具体的になりましたが。上記の連載記事は入門としては非常に為になるので、参考にしている人も多いのではないかと思います。実際ゲームなどを作ろうと思ったらSurfaceViewは必須なのですが、この記事のキモとなる二つのサンプルが動かないというのが皮肉です。
これはSurfaceViewの構築が終わる前にスレッドが走り出してしまうのが問題です。この記事の筆者の環境では、たまたまSurfaceViewが構築されるのが速かったか、スレッドの走り出すまでが遅かったかで、問題が表面化しなかったのでしょう。
対処としては、SurfaceHolder.Callbackインターフェースを実装し、SurfaceViewが構築されたところでスレッドをスタートさせるのが安全でしょう。具体的には、MySurfaceViewの宣言
を
class MySurfaceView extends SurfaceView implements Runnable
とし、コンストラクタ内のスレッドを開始している以下の2行
class MySurfaceView extends SurfaceView implements Runnable, SurfaceHolder.Callback
をコメントアウトまたは削除します。その代わり、以下
mainLoop = new Thread(this);
mainLoop.start();
を追加して、SurfaceViewからのコールバックを取るように設定します。それらのコールバック関数をMySurfaceViewクラス内で以下のようにオーバーライドして、構築されたときにスレッドをスタート、ついでに破棄されたときにもスレッドを殺すようにしましょう(スレッドはちゃんと殺しておかないと、アクティビティが終了してもメモリに残っている限り回り続けるみたいです)。
getHolder().addCallback( this );
細かい書き方はともかく、これで動くようになるはずです。
@Override
public void surfaceCreated( SurfaceHolder holder ){
mainLoop = new Thread(this);
mainLoop.start();
}
@Override
public void surfaceDestroyed( SurfaceHolder holder ){
mainLoop.interrupt();
}
@Override
public void surfaceChanged( SurfaceHolder holder, int format, int w, int h ){
}

IS03ファームアップ
先日、とは言ってももう去年ですが、なんか設定が一部変わってるなと思ったら、ファームが上がってました。

とはいっても2.2ではなく、2.1-update1とのこと。上がったなら上がったで通知くらいしてくれればいいのに。
2.2は2月くらいでしょうかねぇ。Softbankのシャープ端末がすでに2.2のはずなので、検証中のフェーズに入っていてもおかしくないとは思いますが。

とはいっても2.2ではなく、2.1-update1とのこと。上がったなら上がったで通知くらいしてくれればいいのに。
2.2は2月くらいでしょうかねぇ。Softbankのシャープ端末がすでに2.2のはずなので、検証中のフェーズに入っていてもおかしくないとは思いますが。
