kuma

画面サイズとアプリ

実家に帰っている間、ごにょごにょとSupporting Multiple Screensを読んでいた。
ネット環境がないと仕事がはかどりませんなぁ。
幸い、英和辞典があったので助かった。
やはり、紙の媒体も置いておかないと、いざというときに不安だ。

最初に言っておくが、これは私が読んだものなので、正確さには欠けていると思う。
自分で読んでほしい。

---

用語

• スクリーンサイズ(Screen size)
• アスペクト比(Aspect ratio)
• 解像度(Resolution)
• 密度(Density)
• DIP(Density Independent Pixel)

スクリーンサイズは、画面の対角線の物理的な長さ。
これは、large、normal、smallに分類する。
largeは5インチくらい、normalは3～4インチくらい、smallは2.5～3インチくらい。

アスペクト比は、longとnot long。
これは長方形か正方形か、という意味か？

解像度は、width x heightのピクセル値。
しかし、Androidアプリは解像度では動かない・・・という訳でいいのか。
　　appli do not work directly with resolution。

密度は、ピクセル密度などと書いた方がわかりよいのかな。
以下densityと書きます。
同じ面積でも、densityが低ければピクセル数は少なくなるし、高ければ多くなる。
UI部品の大きさをピクセルで指定すると、densityによって見栄えが変わってくる。
これは、high(hdpi)、medium(mdpi)、low(ldpi)に分類する。
highは240dpi、mediumは160dpi、lowは120dpi。

Android1.5までは、スクリーンサイズ3.2インチ、解像度HVGA(320x480)、をベースとしている。
分類で言えば、normal-mdpi。

---

単位として、dipというものがある。
上に書いている、Density Independent Pixel、つまり密度非依存ピクセル。
ピクセル値を直接指定すると、端末によって見栄えが変わってしまう。
それをDIPで指定することで、システム側にうまくやってもらおうということだ。

dipの基準は、normal-mdpi。
もし320dpiの環境で動かしたら、2x2=4倍のピクセル数が必要になる。
ということだろう。

---

で、だ。

結局のところ1.5で作ったアプリをどうしたらいいんだろう？
それは、最初に書いたURLの「Strategies for Legacy Applications」に書いてある。
読んでないけど。

今のところは、その手前まで何となく把握しているつもり。
マルチ対応とリソースの関係について。

---

訳に自信がないので、そのつもりで。

まず、端末のdensityを元にしてアプリのリソースを自動的に選択し、スケーリングせずに画面表示させようとする。
スケーリングする、というのは、拡大縮小のことだろう。
当てはまるリソースがないならば、デフォルトのリソースを読み込んで、現在の画面の汎用的なdensityでスケーリングしようとする。
デフォルトのリソースは、densityがmediumとして考える。

これが「1. Pre-scaling of resources(such as image asserts)」の部分。
続いて「2. Auto-scaling of pixel dimensions and coordinates」があり、最後に「3. Compatibility-mode display on larger screen-sizes」となる。

pixel dimensions、は何だろう。
次元、と訳すと変なので、寸法、なのか。
densityによる計算をしたらピクセルの大きさが出てくるので、そのことだろうか。

例が書いてあるので、いつか訳したいところだ。

---

アプリが複数サイズの画面に対応するかどうかは、AndroidのバージョンとManifestファイルによって決まるようだ(リソースもあるけど)。

Manifestファイルに<supports-screens>を置き、そこに「android:smallScreens="true"」などと書いていくことで、対応するかしないかが決まる。

「android:xxxxScreens」は、small、normal、largeの3つ。
デフォルト値は、Android1.5までは全部false。それ以降は全部true。
あ、全部falseと書いたが、normalはtrue。
このパラメータがtrueだとその画面サイズをサポートする、つまり表示させようとすることになる。
Android 1.5以前では、デフォルトでnormalのみtrueとなるので、大きい画面要アプリだと表示されないことがあるのだろうか。
でも、SmartQ5は4.3インチでWVGAなので、large-hdpiに相当しそうな気がする。4.3なので、ぎりぎりnormal-hdpiかもしれんが。

表を見る感じでは、これからはnormalでmdpiとhdpiに対応するといいんではなかろうか。
ターゲットが決まっているのなら、そのリソースだけ用意すればいいと思う。
デフォルトのリソースさえ用意しておけば、少なくとも表示されないことはないだろう。

---

サンプルを見ている感じからすると、

• layoutはport(縦長)とland(横長)
• drawableはmdpiとhdpi

としておけばいいんでないかしら。
共通で使えるものは、デフォルトリソースへ。

仕事でソースを見ると

今日も何もしてない。

今週から仕事でソースファイルを見ることになった。
今までは別作業だったので、全然そんなのをしてなかったのだ。

そうするとだな、家に帰ってソースを見る意欲が下がることがわかった。
意欲というか、家に帰ってまで見なくとも、というか。
目が疲れているだけかも・・・。

週末は実家に帰るので、ドキュメントを読むことにしようかね。
本を読みたいところだが、読んでおきたい英文があるのだ。
というと格好がいいのだが、Androidの画面サイズに関しての文章が英文だったので仕方なく。
月に１回はプリンタを使うようにしているので、わざわざ印刷したのだ。
実家ではネットにつながらないのよねぇ。

早く、全国に高速ネットワーク回線が使えるようになるとありがたい。
WiMAXでもいいんだけど、まだ来ないんだよなぁ・・・。

[Q5]アプリ画面が小さい

あまりSmartQ5とは関係ないのだが、SmartQ5で動作させたときのことなのでそうしておこう。

似たようなアプリを２つ公開している私。
怖さなどをアピールしたアプリは数多くあるが、威嚇をアピールしたアプリは世界初ではないか？
威嚇が地球を救うかもしれない。
かといって、威嚇と恫喝を一緒にしてはいけない。
真の威嚇とは、相手に危害を与えることなく、自分に危害を与えさせないようにすることである。
そして、自分が強いならば威嚇はしない。それは恫喝だ。
このアプリを見て「威嚇とはどうあるべきか」を考えてほしい。

・・・すまん、適当なことを書いた。

---

とにかく、そのアプリをeclairを移植したSmartQ5で動かした。
SDKは1.5だ。
rotatorに対応していないのでSmartQ5は横画面しか出せないのだが、アプリ画面が小さい。
QVGAくらいになってそうなのだ。

画像が回転するため、画像の中心座標なんかは相対的に指定することはあるが、画面全体のサイズなど考慮していなかった。
していないというよりは、QVGA以上なら収まるだろう、というくらいにつくっていたのだ。
背景色を白のみにしているのも、そんな理由(だったと思う)。

しかし、SmartQ5で動かすと、アプリ画面以外の部分が黒いのだ。
もちろん、黒い部分には何も表示されない。
うーむ。

FILLにしているので画面全体を使ってくれると思っていたのだが、何かしないといかんのか？
AndroidのSampleにあるHomeも同じになったし。
待受アプリを作ってみようとしているからには、それくらい何とかしなくては。

ここ は読んでおかねばなるまい。

[Q5]libを置き換えてもだめ

安直な解を求めたい場合もあるが、それを意図したわけでもないと言うことがある。

何かというと、昨日copybitが動かなかったので、Covia版の/system/libをまるまる私がビルドしたものに上書きしたという話。
それで動けばいいや、とも思うし、置き換えて動くのならばライブラリの問題だけということもいえる。

後者かどうかを見極めたかったのだが、安直と言えば安直。

---

そしてまあ、だめだったのだけどね。

E/AndroidRuntime( 694): Unable to register all android natives
I/ServiceManager( 625): service 'media.audio_flinger' died
I/ServiceManager( 625): service 'media.player' died
I/ServiceManager( 625): service 'media.camera' died
I/ServiceManager( 625): service 'media.audio_policy' died
I/ ( 695): ServiceManager: 0xad08

Audio関係がだめになった。
ここは、AndroidRuntimeが起動してすぐだ。
自分でビルドしたものだと、こんな感じ。

E/ALSALib ( 640): external/alsa-lib/src/control/control.c:909:(snd_ctl_open_noupdate) Invalid CTL AndroidOut
W/AudioHardwareALSA( 640): Unable to attach mixer to device AndroidOut: No such file or directory
E/AudioHardwareALSA( 640): Unable to attach mixer to device default: No such file or directory
E/ALSALib ( 640): external/alsa-lib/src/control/control.c:909:(snd_ctl_open_noupdate) Invalid CTL AndroidIn
W/AudioHardwareALSA( 640): Unable to attach mixer to device AndroidIn: No such file or directory
E/AudioHardwareALSA( 640): Unable to attach mixer to device default: No such file or directory

ALSAが動いてなかったので、そのままエラーで進んでいったというところ。
グラフィックがSurfaceFlingerならば、音はAudioFlingerなのだな。

flingerって何だろうかと思ったら「蹴る癖のある馬」らしい。
ピッチャーとか投げる人という意味もあるようだが。
いや・・・普通に考えれば、後者か。
ハードに向けて指示を投げる人、とかか？

今のところ、自分でビルドした環境ではFlinger系はうまく動いていないな。
そこがやはり、企業と本気さが違うということか・・・。

[Q5]Covia版Eclair

Coviaさんのところから、SmartQ5のEclair試作版が出ていた。
試作版を出せるところがいいですな。

試してみたが・・・やはりできがいい。
私のとは比較にならん。
当たり前といえば当たり前なのだろうが、なんかショックだ。

一番の違いは、グラフィックだろう。
まだWVGAには対応していないのだが、軽い。
その次は、ネットワーク。
ちゃんと無線LANがつながりそうだ(接続までは試してないけど)。
悔しいなぁ。

---

あまり深く考えていなかったのだが、EclairはAndroid2.0らしい。
今のSDKで出ている最新版は、2.1。
android.git.kernel.orgを見てみよう。
ここでは、tagsとheadsという単語が出てくる。
-bオプションで使っている名前は、headsにある。
だから、headsがブランチのことなのだろう。

frameworks.gitを見てみると、commitコメントに「android-2.1_r1 snapshot」と書かれている。
ということは、最新のeclairブランチは、Android2.1R1なのかしら。
コメントの横に「eclair」って緑色の枠が出ているは、「これが最新のeclairでとってこれるものですよ」という意味なのか。

---

さて、私も悔しがっているだけではだめだ。
活用できるところをもらわねば。

まずは、copybit。
構造体が変わったせいか、Cupcake版のものが使えないのだ。
昨日までがんばってみたが、どうにもだめ。
もちろん私は、Covia版のcopybitをいただいたってわけさ。
いくつかまつわるlibも一緒にコピー。

動いた！
と思ったが、もっさり。
なんでだろうと思ったら、egl.cfgがないせいか、stretchに失敗。
ならばとegl.cfgをコピー。
中を見るとfimgなんてことが書いてあった。
同じ場所に、fimgなんとかってライブラリもある。
えーい、まるごとコピーしてしまえ！

・・・動かなくなった・・・・・・・。
egl.cfgを置くことでfimgを使うようになったのだが、fimgがChunkAllocというのを使っているみたいなのだ。
これも同じディレクトリに置いているのだが、なぜか見つからないといわれる。
アクセス権もフルにしたし、そんな問題ではないのか・・・。

E/libEGL ( 650): load_driver(/system/lib/egl/libEGL_fimg.so): Cannot load library: link_image[1721]: 628 could not load needed library 'libChunkAlloc.so' for 'libEGL_fimg.so' (load_library[1051]: Library 'libChunkAlloc.so' not found)

kernelを置き換えてみるといいのだろうが、そうすると前回のchrootみたいなことをしなくてはならん。
つまり、/systemと/dataをまとめた1つのパーティションを作らねば。
ああ、昨日のまま放置しておけばあっさり試せたのに・・・。

などと繰り言は言うまい。
明日だな、明日。

[Q5]chrootと/dev

こんなことを考えていた。

今のSmartQ5では、rootfsはinitramfsにあり、そこにinitで/devなどを作り、init.rcで/systemや/dataをmountするなどしている。
それを、init.rcの適当なところでchrootさせることでパーティションを減らせるのではないかと。

やっているのだが、うまくいかない。

socketの作成がうまくいかないのだ。
initの中で、device_init→init.rcのinitセクション実行→start_property_service、の順で行われているため、/devがinitセクション実行中のchrootで消されているからだろう。

ならば、とinitセクション実行後にdevice_initをもう一度呼ぶようにしたけど、だめ。
よくよく見ると、それよりずっと前、一番最初に/devのmkdirなどがあった。
ああ、そうですか。。。

---

そんなことを考えると、initのしょっぱなでmountとchrootさせてしまえばいいっちゃなかろうか。
そげんあれこれ考えたくないけんね。

だが、mount()が動かない・・・。
考えてみれば当たり前なのだが、/devがないのにmountも何もあったもんじゃない。
/devはどうやっているかというと、rootfsにmkdirしたあと、tmpfsをmountさせているのだ。
かといって、/devを作ってあれこれしたあとにchrootしても、その設定はchroot先の/devには引き継がれないのではないか？
シンボリックリンクさせようかと思ったけど、ネットで見る限りchrootはchroot外へのシンボリックリンクができないようだし。

なんだ、あれこれやって結論は「できない」なのか？？

---

chrootはそういう目的ではなく、緊急リカバリー用に使おうとしているのかなぁ。

とにかくまあ、あんまり簡単にはできなさそうなことがわかったのでいいとしよう。
きれいにやるなら、u-bootのところからSDカードをマウントすることだろうけど、インストーラを何とかしないと手を出せなさそうだから、やめておこう。
さすがに起動しなくなるのは困る。

[Q5]eclairとmasterの違い(init)

eclairになって、initにchdirとchrootが加わったのでパーティションをまとめよう、なんて考えていたけど、eclairのinitは昔と変わってなかった。
むむ、なんでだ？
夢で見たのか、そんな内容を？？

自分に自信を失いかけた頃、ものがみつかった。
masterの方だった。

masterでは、chdirとchrootが追加されたみたい(中で関数呼んでるだけだが)。
ついでに、importというのも使えるようになったみたい。何か知らん。

起動時に作る/devに、sndも加わるようになったみたいだ。
これがないと、たぶんALSA関係のがうまくいかんのよねぇ。

---

ALSAといえば、eclairにALSAをlocal_manifest.xmlで追加するとコンパイルに失敗する。

これは、frameworks\base\include\media\AudioSystem.hが今のALSAと差分があるためのようだ。
local_manifest.xmlのは、うまくさばいてくれないのか？
あるいは私の使い方が悪いのか・・・。

gitの使い方がよくわからないままなので、後者である気もする。
さっきも、今までSmartQ5用にしていたものにブランチを切ろうとrepo startしたら、ソースが変更前に戻されていて全部やり直したし・・・。

何をすれば、gitがわかるのかなぁ。。。

[Q5]電源OFFダイアログ

自分でビルドしてから、どうしても困ることがあった。
電源OFFだ。

SmartQ5にはボタンが4つ(リセット以外)があり、その1つが電源ボタンだ。
電源をOFFにするときには長押しすると、サイレントモードにしたり、電源OFFにしたりの選択肢が出てくる。
今のビルドでは電話系のものを組み込んでないため、電源OFFしか出てこない。
そこで電源OFFを選択すると、本当にいいのか聞いてくる。
そのダイアログでYESにすると、シャットダウンが始まって、電源OFFになる。

自分でビルドした場合、長押しするとダイアログが出てくるのだが、それと同時にバックライトも消えてしまうのだ。
他のボタンを押すと点灯するので、また長押しして、消える。
何度かやっているとうまくダイアログが表示されるのだが、そこで電源OFFを選んでも、今度は次の確認ダイアログで同じようなことが起こる。
そうやって嫌になり、リセットボタンを押してしまうのだ。

---

そもそも、電源OFFダイアログはどこで制御されているのか？

意外ッ！　それはphone_policyッ！！

PhoneWindowManager.javaにあった。
正確には電源OFFダイアログではなく、キーの長押しだ。
interceptKeyTq()という関数で受け取っている。
Tqは、Queue Threadのことらしい。

そこでスリープしそうなところをコメントアウトしたら、直った。

---

ついでに書いておこう。

電源OFFを聞いてくるダイアログは、PowerDialog。
これは、phone_policy。

その次のシャットダウンを確認するダイアログは、ShutdownThread。
これは、frameworks。

同じように見えて実現している箇所が違うので、探すとき忘れないようにしよう。

[Q5]Launcher2にlibを足してもだめ

あー、もう今日は体きつい・・・。
風邪と口内炎。
こまったもんだ。

---

やる気があまりでないが、Launcher2がlibをコピーするだけでいけるならば試しておきたいところだ。
libRS.soとlibrs_jni.so。
out以下のobj/libにあるのに、なぜコピーされないのだろう？
コピーするものとされないものの区別を見分ける方法がわかっていない。
ビルドはされているのだがなぁ。

さて、コピーしてみたのだが、やはり動かない。

V/RenderScript( 744): RS Launching thread
W/ResourceType( 744): Failure getting entry for 0x7f02001e (t=1 e=30) in package 0: 0xffffffb5
D/AndroidRuntime( 744): Shutting down VM
W/dalvikvm( 744): threadid=3: thread exiting with uncaught exception (group=0x4001b168)
E/AndroidRuntime( 744): Uncaught handler: thread main exiting due to uncaught exception
E/AndroidRuntime( 744): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.launcher2/com.android.launcher2.Launcher}: android.view.InflateException: Binary XML file line #54: Error inflating class android.widget.ImageView

そういえば、Launcher2ってどんなアプリだろう？
Binary XMLという文字が見えるところから、XMLを使ってるのだろう。
勘だけど、XMLにスクリプトを書いて待受画面を作ることができる、みたいなものか？

ああ、力尽きてきたので、もう寝ます。

あ、init.rcでchrootとchdirがサポートされるようになったようだ、eclairから。
と自分で書いて気付いたのだが、chrootできるんだ！
SDカードにパーティション作ってAndroidのデータ一式を置いているのだけど、SmartQ5は4つパーティションを使っているのだ。
だから、空きがないのだな。
Covia版のSDカードと自分版のSDカードを用意しているのだが、BeagleBoardがやってきたので1枚空けたいところ。
買えばいいんだけど・・・お金がかかるし・・・。

今の私の使い方だと、そんな何十GBもいらんようだ。
余っているので、有効に利用したい。
initramfsを使っているとそこがrootになってしまい、それゆえ/systemと/dataを別パーティションにしている。
それとswap。vfatは必要なので、あわせて4つ。
これでおしまいだ。

もしchrootできれば、/systemと/dataをまとめた/rootを作ってしまうことができる。
/devとかsqlite関係らしきディレクトリも、あらかじめ作っておけば、initであれこれやらなくても済み、起動が速くなるのでは？

まあ、期待はいろいろあるけど、とにかく寝よう。
明日も会社に行かねば・・・。

[Q5]待受画面アプリ

さて、voldの件が片付いた(解決ではないが)ので、当面の残件がなくなった。
あまり乗り気ではないが、待受画面のアプリを見てみよう。

なぜ乗り気でないかというと、アプリは苦手だからだ。

---

オリジナルの待受アプリは何かなー、と思ったが、名前からするとLauncherみたいだ。
そのディレクトリの下に、Launcher2というものがあった。
むむ、これは試して見ねば・・・

だめだ。
起動できなかった。
/system/lib/librs_jni.soがないからのような気がするが、そこまでログを見てない。
見ないとかなぁ。

とにかく今日は、気分が悪くなってきたので寝よう。
喉と鼻の奥に違和感があるので、風邪かなぁ。