Androidのgitが復活した

この週末からAndroidのgitが復活しています。
URLはhttps://android.googlesource.com/
今回からgmailによるログイン認証が必要になりました。
Android使いの人ならgmailアカウントは絶対持っているでしょうから、良いんじゃないですかね。
この認証コードはhttps://android.googlesource.com/から取得してくるんですが
どうも端末もチェックしているようで、git接続するPCでコードを取得する必要があるようです。
試していませんが新たな認証コードを取得すると以前のは無効になるんじゃないかな。

あとはWeb上からgitの中身が覗けなくなりました。
ここが一番セキュリティホールになる所なので仕方ないことかな？
でも新しいブランチのチェックとかちょっと面倒ですね。
取り敢えずはmanifestをcloneして「git branch -a」を叩くのかな？

以下、需要あるか知らんけど新gitの設定

・repoの更新

上記の認証対応とgitのURLが埋め込まれているのでrepoを更新します。

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

置き先は適宜変えてください。

・認証コードを取得する

gmailアカウントにログインした状態でhttps://android.googlesource.com/にアクセスし
「Generate New Password」→「Allow Access」
画面下に表示された文字列をコピーして~/.netrcとして設置します。

あとは普通に

repo init -u https://android.googlesource.com/platform/manifest -b android -2.3.7_r1

とかやってやればOK。

Android 4.0

昨日、Galaxy Prime(Galaxy Nexus)と一緒にAndroid 4.0が発表されましたね。

4.0はスマートフォン用の2.3.Xとタブレット用の3.Xが統合された物ですが
UIの雰囲気は3.Xっぽいですね。
4.0のソース公開はGalaxy Prime発売の二週間後位になるそうですが
是非ともそこでgitを復活させて貰いたいものです。
また、GPL部分のみの公開だったら嫌だな。

発表にあわせてAndroid SDKのエミュに4.0が追加されています。
興味のある人は触ってみてください。
SDKもr14にバージョンアップしてAVD Manegerが分離したりUIが刷新されたりしていますが
今回からパッケージにfastbootが含まれなくなったようです。
バックアップをとっておくか、アップデートせず別ディレクトリに入れるとかした方が良いかも。

[Android] apkとodex

今日はapkとodexの関連性についてのお話です。

スマフォの/system/appや/system/frameworkを覗くとapkとodexが対になっていると思います。
また、機種によってはodexが無くてapkだけの物もあるかな？
カスタムROMに入れ換えている人も多分apkしかありませんよね。

ここでは昨日のdalvik-cacheの話が出てきます。
apkの中にはclass.dexがあってそれを最適化したものがdalvik-cacheに生成されると話しましたが
よく考えると保存されるのはどちらもnand(内蔵フラッシュメモリ)ですよね。
限りあるnand領域に同じような物がある事は非常に無駄です。
そこでdalvik-cacheに生成されるデーターを事前作成してodexとし
apkの中からclass.dexを取り除いてあるのがこの、apkとodexのセットです。
このセットは完全機種依存のプログラムになりますので
もし、引っこ抜いて他機種に入れたとしても動きません。
移植する場合にはodexをclass.dexに変換し、apkに突っ込んで再署名する作業が必要になります。
と言う事でodex化する利点は以下の様な物になります。

・nand領域の節約になる
・初回起動時間の短縮（system配下のapk分、dalvik-cache作成が必要なくなるため）
・システムアプリを他機種に移植しにくくする

ここでsystem配下にあるapkのodex化について軽く触れておきます。
OSがclass.dexからdalvik-cacheの最適化プログラムを生成するに当り
他のapk内のclass.dexを参照している構造になっている物があります。
例えば中途半端に/system/frameworkだけodex化した場合には、
この依存関係が解決出来ず起動しなくなってしまいます。
これを回避する為には/system/appと/system/frameworkを同時に
且つ、依存関係が解決できる順番でodex化していく必要があります。
この順番はdalvik-cacheをwipeし再起動直後をlogcatで監視し
installdが処理していく順にすればOKです。

[Android] dalvik-cacheって何？

今日はdalvik-cacheとは何か？と言うお話です。

よくROMを入れ換えたらdalvik-cacheをwipeしてうんたらと話が出ますが
dalvik-cacheにはjavaの実行部分が入っています。
ちょっと言語よりの話になりますが、javaのプログラムをコンパイルするとclassファイルが出来ます。
これにあたる物がapk内にclass.dexとして入っています。
class.dexの中身はどのAndroidでも動くように汎用的な内容になっていますので
端末依存処理を埋め込んだものがアプリインスト時にdalvik-cacheに生成されます。

system配下のファイルを弄った後の再起動は異様に時間がかかる場合がありませんか？
これはシステムに変更がかかったと関知したOSがdalvik-cacheの一括再作成を行うためです。
要するにアプリを大量にインストしていればそれだけ時間がかかるわけですね。

ROMを入れ換えてdalvik-cacheをwipeしなかったとして
ゴミが残ることはあっても動作上問題になることはありません。
ユーザーデータ起因の再起動地獄は/data/dataにあるデータとシステムアプリ間で整合性が取れていない事が原因です。

[Android] インストしたアプリは何処へ？

今日はインストしたアプリは何処へ行くのかと言うお話です。

マーケットや野良apkからインストしたアプリは/data/appに保存されます。
この時のファイル名はアプリID+枝番.apkとなります。
以前、アプリIDは一意で被ることはないとお話しましたが何故枝番が振られているのでしょうか？
これはアップデート用で、もしXX-1.apkがインスト済みの場合は
アップデート版をXX-2.apkとしてインストしXX-1.apkを削除。
XX-2.apkがインスト済みの場合はアップデート版をXX-1.apkとして…
といった具合です。
ここに保存されているapkは引っこ抜いて他の端末に入れることも出来ます。

本当は実動作上の仕掛けを書こうかと思っていましたが、非常に複雑になってしまったのでさらっとにしておきます。
javaの実働部分は/data/dalvik-cache、アプリのネイティブライブラリや設定データは/data/dataの物が使われます。

[Android] Android SDKのツール達 その3

今日はAndroud SDKに含まれるDalvik Debug Monitorのお話です。

こいつはAndroid端末のシステムログや立ち上がっているプロセス情報等をGUI上で表示するものです。
Androud SDKのtoolsディレクトリにあるddms.batから起動します。



こんな感じですが、こいつで良く使う機能と言えばDeviceメニューにあるScreen caputureでしょう。
ddmsの説明はこんな物しかないので、このキャプチャを取得する仕掛けを書いておきますね。

Androidでは二つのフレームバッファを交互に切り替える事によって画面描画を行っています。
/dev/graphics/fb0と/dev/graphics/fb1からこのバッファの内容を取得する事が出来ます。
では実験。adbで

adb pull /dev/graphics/fb0

でfb0の内容をPCに落としてきます。
これはRGBの生データ、RAW画像フォーマットですがフリーの画像編集ソフトGIMPを使えば開けます。
このままでは単なるバイト列なので開く時に縦横の解像度をしてやる必要があります。
例えばHTC Sensationの場合は544x960ね。

これで大体わかったんじゃないですか？
ddmsはadbd経由で端末の/dev/graphics/fb0を取得し
png変換をして保存をする非常に簡単な仕掛けなんですよね。
世に出回っている画面キャプチャアプリもこれと同じ処理を行っています。

[Android] Android SDKのツール達 その2

今日はAndroid SDKに含まれるfastbootのお話です。

fastbootはbootloaderを通して端末を操作できます。
普段私達はadbで端末を操作していますが、adb接続する為には端末側でadbdが立ち上がっている必要があります。
bootloaderはkernelが立ち上がる前、PCで言えば異常終了させた時に出るシステム修復やセーフモードの切り替えにあたる部分です。
当然、adbdは立ち上がっていないのでfastbootを使用する事になります。
少し話が横道にそれますがadbdの様に常時立ち上がって外部からのトリガーを待ち受けるプロセスの事をデーモンと呼びます。
windowsではサービスと呼ばれているものですね。
httpd,ftpd,ntpd等の最後のdはこのデーモンの略です。

以下、fastbootの解説です。
端末とPCをUSBケーブルで接続し、bootloaderをfastbootモードに切り替えて使用します。

・fastboot reboot

リブートします。
「fastboot reboot-bootloader」でbootloaderを再起動できます。

・fastboot flash

端末のnand領域にイメージを書き込みます。
「fastboot flash system system.img」みたいに使います。
端末がbootloader以外起動しなくなったとしても、この機能を使えば復旧できます。
元ネタのimgにはClockworkMod Recoveryで取ったバックアップが使えるのですが
バージョン5.XのClockworkModはtarでバックアップするように仕様が変わっているので使えません。
非常用にバージョン4.X以下を使用したバックアップをPCに保存しておくことをおすすめします。
又「fastboot flash hboot」を使うとbootloader自身の書き換えも出来るのですが
失敗すると端末が起動不能になりますので注意が必要です。

・fastboot boot

PC上にあるboot.imgを使って端末を起動する機能で 「fastboot boot boot.img」の様に使います。
自分で細工したboot.imgはこれをつかって正常起動するか確かめてからflashすれば安全です。
この機能で立ち上げた端末は再起動すれば元に戻ります。

・fastboot oem

メーカーが組み込んだ独自機能を使用します。
「fastboot oem h」で使用可能なコマンド一覧が出力されます。

[Android] 通常起動時とRecovery起動時のmountについて

今日はrecovery時のadbの使い方に載せようと思って書いていたけれど、余りに長くなるので別出しにした内容です。

secureなboot.imgの通常起動時にsystemをリマウントするにはこんな感じの長ったらしいコマンドが必要でした。

mount -o rw,remount /dev/block/mmcblk0p22 /system

リカバリー時にsystemをマウントするにはこんな感じのコマンドでした。

mount /system

ここで同じmountなのにrecovery時は何故こんなに簡単なのかと疑問を持った方はいませんか？
そもそもデバイス名の記載がいらないのは何故でしょうか？
では実験してみましょう。
「adb reboot recovery」でrecoveryに入り、
「adb shell」上で「mount a」と入力してみましょう。

mount a
mount: can't find a in /etc/fstab

当然ですが怒られました。が、謎は解けましたね。
/etc/fstabに記載されている情報を元にmountを行っているんです。
でも通常起動時には/etc/fstabが無いんですよね。これを引っこ抜いて通常側にも入れてみましょうか。

以下はHTC Sensationでの例です。shellに入っている人は「exit」で抜けてくださいね。

adb pull /etc/fstab
adb reboot

ここで再起動がかかります。

adb shell mount -o rw,remount /dev/block/mmcblk0p22 /system
adb push fstab /etc/
adb shell chmod 644 /etc/fstab
adb reboot

はい、これでOKです。
本当はパーミッション変更する必要も無いですが、気持ち悪いので一応ね。
/etcが存在しない機種の人は残念ですが今回は見送りです。
もしboot.imgのramdiskをいじれる人だったら、/system/etcをシンボリックリンクすれば出来ますよ。
これで出来るようになったのでしょうか？「adb shell」に入りますよ。

umount cache

成功しましたね。「mount」の一覧にcacheもないし、「ls cache」としても何もありません。
アンマウントしっぱなしじゃ不味いのでマウントしますよ。

mount cache

怒られました。
busyboxの所でも書いた事ですが、toolboxの/system/bin/mountとbusyboxの/system/xbin/mountがあるんです。
上記のコマンドだとtoolbox側が呼ばれているんですが、こいつには/etc/fstabをみる仕掛けがありません。
この状態でbusybox側を呼び出すにはこうします。

busybox mount cache

成功しました。
でも、ここでわざわざcacheパーティーションを選んだのには理由があります。
試しに「umount /system」と入力してみても失敗するはずです。
これはumountしようとするパーティーション内のファイルが使用中なので実行出来ないんです。
いきなりファイルが消えたらシステムが異常終了してしまいますので当然と言えば当然です。
systemの場合はリマウントですね。

busybox mount -o rw,remount /system

ちょっとは楽になったでしょうか？デバイス名を覚える必要が無くなっただけましかな？

これをやって「 fstab入れたんだぜ！ 」と他人に言っても何の事やら分からないおかしな奴としか思われないので、完全な自己満足ですね。
Androidのカスタマイズと言うとカスタムROMを入れたりパフォーマンス上げたり派手な事ばかりが目に付きますが
こんな地味な世界もあります。

[Android] 日本語Fontを入れてみよう

今日は日本語Fontを入れてみましょう。

そもそも何で日本語Fontを入れる必要があるのか？って所を話しておきますが、
輸入物の端末や中華パッドとかは日本語Fontが入っていない場合があります。
この状態でも日本語表示は出来るのですが中国繁体字を流用しているので、たまに変な字体が混じります。
これを回避するために入れると言うのがひとつ。
後は単純に表示が気に食わないので、自分が見やすいのに変更する場合ですね。

先ずは入れるFontを用意しましょう。
俺はいつもAndroid gitにある標準日本語Fontを使っています。
Windowsで使っているFontを使う場合は、ファイル名をDroidSansJapanese.ttfに変更して入れます。

adb remount　又は　mount -o rw,remount /dev/block/xxx /system

でsystem以下を書き込み可能にします。
そして

adb push DroidSansJapanese.ttf /system/fonts/
adb shell chmod 644 /system/fonts/DroidSansJapanese.ttf
adb reboot

これで終わりです。簡単でしたね。

ここではパーミッションの変更をしていますが、行わなくても不具合が出ることは無いと思います。
ただ、他のファイルと合わせておかないと気持ち悪いので慣例的に行うものですね。
Linuxの場合でシステム上にあるファイルを上書く場合、元のファイルパーミッションが引き継がれますが
Androidは常に新規ファイルと同じ状態にパーミッションが変更されてしまいます。

既に何回か物を突っ込んだ事がある人は、入れたファイルは常に同じパーミッションになっている事に気付くと思いますが
これはumaskの値で決まっています。
shell上で「umask」と入力してみましょう。
これの下3桁が通常使っているパーミッションに当たります。
4桁表記の説明は省きますので興味がある人は調べて見てください。

マスクなので0777からこの値を差し引いたものが、ディフォルトのファイルパーミッションになります。

0000 の場合は 0777 に
0133 の場合は 0644 になります。

Androidのumask値はinitの中で設定されていて、メーカー側が独自設定していない限り0000です。

shell上で「umask 0133」のように入力すると変更できます。
再起動するまで有効です。

[Android] adbの使い方 その3

今回はリカバリー状態の端末にリソースを突っ込む方法です。
ClockworkMod Recoveryが入っている事が前提です。
それでは「adb reboot recovery」でリカバリーに入りましょう。

基本的には通常起動時と余り変りませんが以下の違いがあります。

・unsecure状態なのでログイン時からrootである。
・主要なパーティーションはmountされていない。

それでは「adb shell」で端末に入りましょう。
「mount」と入力してみます。通常起動時と比べるとスカスカですね。
「ls /data」と入力して/dataの中身を見てみます。何もありません。
これは見えないのではなくて本当に何もないのです。
この状態では/dataは単なる空のディレクトリです。
「mount /data」と入力してdataパーティションをマウントします。
「ls /data」で中身が見えるようになりました。
「umount /data」と入力してdataパーティションをアンマウントします。
「ls /data」とすると又中身が無くなりました。

前回mount,umountの話が出てきましたが、よく意味が分からない方が多かったのではないかと思います。
しかし、実際にやってみると分かると思いますがmountは端末上のディレクトリとデバイスを結びつけ
umountは切り離す動作をします。

リカバリー時にリソースを入れる場合も「adb push」を使いますが
上記の様に目的のパーティションをmountする必要があります。
もしmountしていない状態で突っ込んだ時に偶々ディレクトリが存在した場合は
正常に書き込まれたように見えて再起動したら入っていない事になります。

後はリカバリーからupdate.zipとかを入れる場合ですが
これのscript上ではデバイスをmountし、物を突っ込み、umountする構成になっています。
事前にmountしていてもzipを当てた直後はumountされていますので注意して下さい。

mountにさえ注意すればリカバリー状態の方が作業しやすいかもしれませんね。

次回は日本語Fontを入れましょうか。