A month with Gravity Smart / a2sd

Gravity Smart を手に入れてから一ヶ月と少し経ったけれど、今のところ一番のお気に入りかもしれない。Android の slide QWERTY handset としては、Motorola CLIQ/CLIQ 2 そして Samsung Sidekick 4G を使ってきたけれど、Samsung Gravity Smart はそれらと比べてもなかなか使いやすい。

Spec で見れば、ARM11 800MHz と、CLIQ よりは良いけれど、CLIQ 2、Sidekick 4G と spec だけの比較をすれば圧倒的に見劣りしているのは間違いない。

ただ 130g という軽い本体重量と compact なサイズは texting/social 用と考えればかなり良い感じだ。Battery は結構な頻度で texting あるいは SNS service の利用をしても充分丸一日はもつし、音声通話も比較的良い。

CLIQ/CLIQ 2 はどちらも compact ではあるけれどとても重い。また Sidekick 4G は特に keyboard が素晴らしい仕上がりなんだけど大きい… ということで、keyboard はちょっと独特の癖があるけれど、軽くて小さい Gravity Smart は結構活躍してくれている。

その Gravity Smart の大きな欠点が internal storage が 159MB しか無いことだろう。

Application だけではなくて、application の data も /data partition に保存されるので、すぐに storage full の警告が出てしまう。

というわけで、32GB の MicroSDHC card を partitioning して 1GB の ext2 partition を作ってみることにした。

基本的に Android OS は external storage (MicroSDHC) の先頭にある partition を /mnt/sdcard に mount するので最初の partition はかならず fat32 で partition を作らなければならない。そして 2番目に ext2 (or ext3/ext4) そして 3番目に必要なら swap partition というのが通常の構成となる。

というわけで、ext2 partition に 1024MB、swap partition に 64MB を割り当てることにして partitioning のやり直し。File system を作成してから Gravity Smart 本体に挿して認識できることを確認。

後は boot 時に mount する必要があるけれど、こちらは stock kernel のままだと init.d は使えないので、init.rc から呼び出される install-recovery.sh から init-sd2.sh という script を call して処理することにする。

install-recovery.sh は通常存在していない場合もあるけれど、/system/etc に存在すれば init.rc から呼び出されるので、stock kernel のままでも、ここで各種の tweaks を実行させることが出来る。

ということで、install-recovery.sh 経由で init-sd2.sh を call して、10秒 wait した後に ext2 partition を mount することに。Mount point は /system/sd として、その下に、data, app, app-private の 3 つの directories を作成して /data に symlinks を作成。この時、owner は system.system である必要があるので、su で root になってから、su system で system user となって、directories と symlinks を作成するといいだろう。(chown で owner を変えても良い)

まず、最初に mount が無事に出来るかどうかを確認というわけで、symlinks を作成する前に一度 boot。そして、無事に boot time mount が成功することを確認。

それから symlinks を作成して、既存の applications などを copy して再度 boot。こちらは、size や空き容量などを確認するには shell から df command を使うか titanium backup を起動するかだ。

Titanium backup を起動すると、無事に /system/sd (sd card 上の ext2 patition) が application 領域として使われていることが分かる。

この作業中に何か失敗して /data/data が存在しない状況になると boot 時に起動する各種 services が /data/data に書き込みが出来ず起動失敗し、延々と bootloop することになる。

この場合は、rageagainstthecage や psneuter を /data/local に push して exploit を実行して shell 上で権限昇格を行ってから復旧すればいいだろう。

とりあえず swap を有効にした kernel も build はしてみたけれど、今はまだどの block device に kernel があるのかまで調べていないのでそのうち。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中