Tech:android:hack:backup

出典: Tariki

目次 1 androidのバックアップ 1.1 部分バックアップが必要ないもの 1.1.1 アプリケーションそのもののバックアップ 1.1.2 電話帳・カレンダーのバックアップ 1.1.3 SDカード上のデータ 1.2 a2sdパーティションの丸ごとバックアップ 1.3 部分バックアップするものとその仕方 1.3.1 backup for root users (BackupRoot) はあてになるか 1.3.2 何をバックアップしなければならないか 1.3.3 アプリケーションのお行儀 1.3.4 UNIX shellからのデータ書き戻し 1.4 コマンドラインからのnandroidとsplash screen (起動表示)

androidのバックアップ

特にROM遊びをしていると必要なのはバックアップだ。

もちろん別項で書いたように、本体フラッシュメモリ上パーティション全部はSD card上に.imgファイルとして丸ごとバックアップを取ってくれるのがnandroidだ。これはROM遊びでは必須である。

その他、ROMのバージョンアップ (ROMの初期状態(工場? 出荷時) に初期化しデータだけ書き戻す)、万一の端末破損・紛失などにも備えて必要なのが、部分バックアップである。初期状態から『使っている』状態に戻すには

• アプリ: Astroなどのアプリバックアップで書き戻す。Market(サーバ側)でも覚えているようである
• クラウド系データ: Googleサーバが持っていて自動的に同期してくれる
• もともとSDカード上に取られる・置いているデータ(音楽・写真など): ROMの初期化に関係なし

ということで、主にデータ系のバックアップ→リストアが必要になる。

なお、同一ROM内でのバージョンアップであれば、そもそもwipe (工場出荷時? に消去) が必要ないこともある。その際でもバックアップを取るのは重要だが、nandroidさえあればまず無消去バックアップを試してみる価値はある。そのへんはROM遊びの項にまとめておいた。

部分バックアップが必要ないもの

アプリケーションそのもののバックアップ

これにはツールがあまたある。私がいちばん気に入っているもので、なおかつ世間でも評判が高いのが、ファイルマネージャであるAstroのTools内のApprication Managerである。Backupタブでは現在のインストール状況とバックアップ状況を比較して、バックアップがないか、バックアップが最新か古いか (private appなのでバックアップされないか)を表示してくれる。

デフォルトでSD内の /sdcard/backups/ に.apkファイルのバックアップが作られる。したがってROM再インストール後などは、まずAstroだけMarketからオンラインで書き戻して、それからSDから戻していた。

実はAstroは『どんなアプリをインストールしていたか』の目安になるだけで、一個一個操作しなければならないわ、SDから書き戻すと野良アプリ扱い(Marketでアップデートが表示されない - というよりインストールしていないことになる)になるわで面倒だったのだが、最近のバージョンのAstroではまとめて書き戻せるようになった(ただし承認は一個一個必要)し、さらにMarketでUpdateが表示されるようになった。

と思ったら、Marketの方でも改良があったらしく、そもそもAstroがなくても、『ダウンロードした』記録がサーバ側に残っていて、リストを表示してくれるようになったようである(? よくわからない)。これは有料アプリの二度払い防止のためであると思うが、正しく動けば『インストールしたアプリまでクラウド』ということになって便利である。いままで気づいた限りでは、ベースOSバージョンが違うとリストが一部かけていたりするようである (まあOSバージョンなど違えば動かなかったりMarket掲載のリストが違ってくるので当たり前であるが)。

電話帳・カレンダーのバックアップ

これは特に必要ない。クラウド文房具の項で述べたように、データを書き換えてからオンライン(Google)で同期が取れていれば、いつでも別の端末でも複数の端末でもデータの同期が取られる。似たようなものに、Google My Mapsがある。これはどちらかというとサーバ上にデータがあるため(ローカルで使えない)バックアップが不要というのが真相だ。

ただし万一のこと (まあGoogleサーバが事故、というのは考えにくいけど)、例えば同期が狂って空の状態に同期(つまり全削除)されたり、ということがあると困るので、自己責任で手元にデータのダンプを取っておくのは必須である。これは電話帳とカレンダーに限って言えば、android端末で行なうより、PC上のwebからCSV形式などで取るほうが楽である。

SDカード上のデータ

これは本体ROMの初期化と関係ないが、他項で述べたように一ROM一SDで使っていると、各SDで共通化を図りたい音楽データ・ドキュメント類をどう同期を取るかの方が問題である。

これは母艦に雛形を持っておいて、そちらと同期を取るのがよいだろう。つまり母艦で『各ROM共通に持つデータ』なるディレクトリを作って、データはPC→SDの一方通行でしかコピーしないか、あるいはrsyncみたいなツールを使って定期的に同期を取っておくのがよいようである。なおadb syncという機能があるようであるが、私はこれを使って同期を取ったことがないので、それについてのコメントは差し控える。

a2sdパーティションの丸ごとバックアップ

a2sdは本体フラッシュ内にある/system/app/、/system/data/ディレクトリをSDに追い出してくれるものである。便利なのだが、nandroidで本体丸ごとのバックアップを取り母艦で保存したとしても、これらSDにあるデータがバックアップされない。まあアプリケーションは後からインストールできるしデータのバックアップは後述するような別の手段があるのだが、不具合でnandroidで書き戻したりしたときにこれらのファイルがないと、完全に瞬間に元に戻すというわけにいかない。

• なお本項のバックアップは、nandroidと同じ……というよりnandroidでバックアップされない部分を補う、一種の丸ごとバックアップであり(通常はnandroid backupの直後に行なう)、このページでテーマとしている、ROMバージョンアップ時のデータ書き戻しなどを目的とした部分バックアップではない。SD上にあろうが本体フラッシュ上にあろうがこれはあくまでもアプリが作るデータなので、後述するような部分バックアップ手段(BackuRootでもよい)が正常に働いているならば、データの部分書き戻しのためには必要ない(部分書き戻しには使えない……こともないが。tar ballの部分展開をするならば)。

これらはadb shellからUNIXでSDのext2(3)領域のtar ballをFAT領域上に作り、さらに母艦に転送すればよい。動いている最中だとスナップショットにならないので、HOME+PWR再起動後、nandroidで丸ごとダンプを取った直後に行なう。

(以下recovery flashのadb shellで)
# mount /system/sd/
# mount /sdcard/
# cd /system/sd/
# tar cvzf /sdcard/FILENAME.tar.gz *

あとはtar ballをadb pullする。またはUSBマスストレージ接続でtar ballをPCに転送する。書き戻しは、nandroidでrecoverした後、上記の逆(つまり/system/sd/で tar xvzf /sdcard/FILENAME.tar.gz)を行なう。

部分バックアップするものとその仕方

データベース・アプリ設定その他のバックアップは、nandroid・前節の方法といった丸ごとダンプでは『元の状態に瞬間に戻す』には便利であるが、ROMバージョンアップなどで初期状態から復元する場合には使えない。

backup for root users (BackupRoot) はあてになるか

後述するようなアプリのデータの部分バックアップ操作 (加えてapp、電話帳も) を選択的にGUIからできるアプリがbackup for root usersである。

これはROMバージョンによってはうまく動いていて、プレイリストやブックマークが書き戻ったのを確認したりしたが、場合によってはうまく動かない(そもそもバックアップがすぐに終了してしまう)。suをうまく取れていないか、書き戻したDBが別の場所にあったりするのが原因かもしれない。うまく使えるならdonationもやぶさかではないな、と思ったが、結局tarを使った手段に落ち着いてしまった。

(追記) SDカードにできているBackupRootのディレクトリを確認した結果、バックアップそのものはうまく取れていることがわかった。したがって書き戻しに問題があるといえる。

ブラウザのブックマークやプレイリストといったファイルは、.db3ファイルがこのディレクトリ直下に置かれているが、『data』のバックアップを選択した場合のその他のアプリケーションが使っているデータ (/data/data/アプリ名/)は、dataNoSys/アプリ名/ というサブディレクトリにコピーが取られている。ただしa2sdに対応してからは、SD上のext2(3)パーティションの data/data/アプリ名/ は sd/dataNoSys/アプリ名/ というディレクトリに対応している。

名前が示すように、これでバックアップが取られるのは、アプリ名が com.android.* と com.google.android.* 以外のアプリケーションのようである。開発元が総本山であるアプリは、そのまま /data/data/ 以下のデータを書き戻すと何か不具合が知られているのだろうか。総本山アプリであっても、たとえばGoogle Sky Mapなどはふつーのアプリとなんら変わりがない。総本山アプリはクラウドでサーバにバックアップが取られるもの以外は(上記プレイリスト等を除き)あまり個人の設定を保存しておく意義は感じられないが。

それからこのBackupRootは、SDのFAT領域にそのままコピーを取る、というのがちょっと不安である。/data/data/ 以下にはシンボリックリンクなどは作られず、ディレクトリ・ファイルのパーミッションは決まっているのかもしれないが(ちょっとのぞいてみるとディレクトリが1755、ファイルは0600か0660のようだ)、UNIXのファイルシステムにありFATにない情報が失われるおそれがある。そういう意味では、ファイル1個といえどもtarでアーカイブしFATパーティションにコピーを取るのが安全だと思われる。

何をバックアップしなければならないか

PDAとしての2大重要アイテム、電話帳とスケジュールがクラウドでバックアップされるのであれば、後は何をバックアップしなければならないか。おおむね下記のような分類ができると思う(backup for rootの分類を参考に)。

• アラーム

  →私は2種類くらいしかアラームを設定していないので、いちいち入力してもあまり問題はない。

• アプリケーション固有の設定
• ブラウザのブックマーク(できればパスワード自動入力のDBも)
• homeアプリケーションのショートカット
• 音楽プレーヤのプレイリスト
• アプリケーション固有のデータ

  →メモ帳・付箋紙系は(androidの『いつでも落としてよい』プロセス管理のためであろう)、ファイルにデータを作るよりDB (sqlite) に作っておくほうを好むようである。まあsqliteもファイルなんですけど。SDに可換な形式(例えばテキストファイル)で、ではないということだ。

• SMS

  →日本のプロバイダはSMSを使えないので、これは問題にならない。ってかSMSメッセージって残す価値あるのか?(笑) 恋人とらぶらぶ中のひととかなら保存しておきたいかも。

• IMの学習辞書

  →日本語IM (フリックWnn)を使っている限り、これもあまり気にならない。英語キーボードはスペルコレクション(自動学習する) に未登録単語があるとうっとうしいので、かえって英語のほうが必要なのかもしれない。

• マーケットDB

  →なぜか最近サーバ側で覚えててくれるのは上記のとおり。

• APNリスト

  →私はプロバイダを1(2)社しかつかっていないので、いちいち入力するのもたいした手間ではない。まあパスワードとか忘れそうなものはテキストファイルでSDにメモってある。

アプリケーションのお行儀

このうちアプリケーションデータについては、若干コメントしておく。

例えばWindowsでは

• 原則なんでも(アプリのセッティングなどまで)レジストリ→移転のときすげー困る
• お行儀のちょっと良いソフトは、\Program Files\ などに(当然アプリケーションごとになる)ファイルを作る→所在さえ知っていればバックアップ可能
• もっとお行儀の良いソフトは、\Documents and Settings\ 以下などにデータを作る→所在さえ(略
• もっともっとお行儀の良いソフトはデータ・セッティングを保存する場所をユーザに選ばせる

ということで、マシン間の移転や同期ですごく困ることがある。

UNIXは歴史的に

• 原則なんでもファイル。もちろんアプリケーション別。もちろんユーザのホームディレクトリ以下に個人別設定
• システム全般にわたる設定(あまり考えられないが)は /var/ 以下に(同上)

という哲学がある。

androidはUNIXだが個人使用で、しかもユーザがrootひとり(?)しかいない。だから

• (Googleが設計した枠組みでは) /data/data/アプリケーション名/databases/ 以下にsqlite3ファイル (アプリ別・DB別でファイルになる)を作る

ということにしたかったようだが、これでは困ることがある。

ひとつがシステムワイドにわたるデータの共有だ(あまりないけど)。例えば音楽プレーヤのプレイリストは、nsw playerなどもGoogle作成のとプレイリストを共有してくれるみたいで、まあGoogle作成のにサードパーティ(?)製が合わせているなら元祖のほうのディレクトリ以下のDBを使っているんだろうな、と分かるが、そうでなければDBがどこにあるのか皆目検討が付かないということになる。ちなみに私は音楽プレーヤのプレイリストがどこにあるか探せていない(爆)。

もうひとつは、/data/ パーティションはなくなってもよいという設計になっていることだ。これはフラッシュメモリが吹っ飛んだときなど初期化しましょうね、という思想からだろう。原則アプリケーションはここに過去DB(その他セッティングのディレクトリ)がなければ作る。

私が使った中でいくつかは、『お行儀がよい』アプリケーションがあった。これらはSDカードにディレクトリを掘って (/sdcard/アプリケーション名/) DBその他のファイルを格納する。まあ理由は、データの書き込みが頻繁だったりすると本体フラッシュを傷めるとか、違う端末に簡単にデータが移せるとかPCでデータを利用したいときささっとPCにマウントしてコピーできるとか、そういうことなんだろうけど、本当にバックアップは楽である。というか、本体のROMを入れ替えたときにそのままデータが残っているので楽である。

• カメラ・カムコーダは(伝統的にそうだから)/sdcard/DCIM/android/ 以下に画像・動画を残す
• wardriveなど。こいつは /sdcard/ 直下にDB (.db3)ファイルを作りやがるのでわかりやすいが(あまり多数のアプリにやられるとごちゃごちゃになって困る)、KML/GPXでふつーにPCで使うファイルをエクスポートするときもSD直下に作る
• そのほかDBに一次的に記録していても、例えばKML・CSVなどに書き出す選択をすると、/sdcard/アプリ名/ 以下に書いてくれるものが多い

ただ難点は、PCにマウントしているときにこれらが利用できなくなってアプリがクラッシュしては困るので、アプリを確実に止めてからマウントしなければならない (これらがバックグラウンドで動き続けていない(データを書いていない)保証が必要である)。

UNIX shellからのデータ書き戻し

というわけなので、最近は/data/ 以下をtar ballでまとめてSD上にバックアップを取ることが多くなった。

(adb shell上で)
# cd /data
# tar cvzf /sdcard/FILENAME.tar.gz *

もしバージョンアップしたROMで全部元に戻したければ、tar ballを展開するだけでよい。ただしアプリの再インストール時に/data/data/アプリ名/ ディレクトリを書き潰す可能性があるので、インストールが終わった後・アプリが動いていない状態で(早い話がnandroid bootなどしてそこから)書き戻すと良いと思う。

アプリを選択してデータを書き戻すこともできる。これはROMバージョンアップしていない時でも、データ・設定が壊れたらあり得るはなしだ。ただしアプリがバージョンアップしたからデータが初期化され破壊された、などというときには、単にデータを書き戻しても、DB・設定ファイルと互換性がないかもしれないから要注意(エクスポートとインポートができる奇特なアプリなら、それ経由でデータを移すのが良いだろう)。

以下はアプリケーションごとのDB・設定の場所の覚書き。

• Gmail アカウント: /data/data/com.google.android.googleapps/databases/accounts.db

  →再設定してもたいした手間ではないし、ROM入れ替え後しょっぱなに行なうのでいかがか

• ブラウザのブックマーク: /data/data/com.android.browser/databases/browser.db

  →他の設定もあるので、/data/data/com.android.browser/ 以下は戻したほうが良いと

• アラーム (これはHTC依存だった): /data/data/com.htc.worldclock/databases/alarms.db
• システム関係 (APNとかプレイリスト、複数の工場出荷時付属アプリで共通にいじる設定とか): /data/data/com.android.providers.media/databases/以下のDB
  • settingsアプリで設定されるようなもの: settings.db
  • 音関係: internal.db (本体フラッシュ内)、externalXXX.db (SDカード内)(※ アプリからはURLでアクセスされるのだが、これと実ファイルのパスとの結びつきはTrojanFinalの音DBの不調の記事参照)。

コマンドラインからのnandroidとsplash screen (起動表示)

ちょっと話が分散してしまうが、nandroidをコマンドラインから使うはなしである。

いわゆるGUIメニューのnandroidと同じものは、recovery boot時にadb shellからコマンドラインで使うことができる。一度GUIのnandroidでリカバリに失敗したとき(mountしちゃっていたのが原因だった) 「コマンドラインのnandroid-mobile.shを試してみてね」と表示されたので知ることになったのだが。

これはシェルスクリプトであり、yaffsというコマンドでパーティション丸々を.imgファイルに、unyaffsで逆の展開を行なっているだけである。したがってGUI版も同じような実装である。

# cd /sbin
# sh nandroid-mobile.sh -[b/r]

オプションは (--helpでいろいろ表示されるが) -bでバックアップ、-rでリカバリである。-rでのリカバリはどのバックアップから書き戻すか選択ができる。いまとなっては(RA recovery flash1.3.2あたり)GUI版でもバージョン選択はできるようになったが。

ところで最近 (2009.12) このshell scriptの中身をまたみる・動かしてみることとなったのは、splash screenのバックアップを取りたいと思ったからである。別項に書いたが私が購入したHTC/Chunghwa版は、起動直後に『Hami』なるロゴが出る。これを特別気に入っているわけではないが、SPLを書き換えるときに失われてしまう、というのをみて、将来修理に出すことになったらロゴが書き換わっていたらまずいだろう、だからバックアップを取ろう、と考えた (ちなみにいままでSPLは純正のままで書き換えていない。Droid 2.0 ROMを試すときに『念のためSPLは Danger SPLに換えとけ』とあったからだ)。

ROMをさんざいじってもこのsplashが書き換わらないのは、本体フラッシュのパーティション構成にあった。これはnandroid-mobile.shのコメントにあったものだ↓

# Reference data:

# dev:    size   erasesize  name
#mtd0: 00040000 00020000 "misc"
#mtd1: 00500000 00020000 "recovery"
#mtd2: 00280000 00020000 "boot"
#mtd3: 04380000 00020000 "system"
#mtd4: 04380000 00020000 "cache"
#mtd5: 04ac0000 00020000 "userdata"
#mtd6 is everything, dump splash1 with: dd if=/dev/mtd/mtd6 ro of=/sdcard/splash.img skip=19072 bs=2048 count=150

ご丁寧にsplashのダンプの仕方が書いてある。いってみればディスクのパーティションを切っていない部分にこの画像データがあるので、ディスク全体のイメージ(BSD UNIXでいったらcパーティション)から部分的に抜き出せ、ということらしい。

そのまえにぐぐってみたら、GUI版のnandroidでもsplash[12].imgという2つの.imgファイルができる(かつてはできた)らしい。最近のrecovery flashからは落ちたのかなあ、こんな画像毎回バックアップとってもしょうがないもんな、と思って、コマンドライン版でバックアップを取ってみた。しかしGUI版と同じものしかできない。

どうやら歴史的経緯を調べてみると、xda-developersで誰かが「新しい版(※ 2009年7月ころ?)では/dev/mtd/mtd6がいないよ」と文句を垂れていて、Cyanogen君が「ごめん忘れてた。そのうち直すわ」と答えているようだった。つまりflash recoveryのOSもCyanogen君の手によるものなので、重要度が低くそれ以来せっつくひともいないようなので、そのままになっているらしい (GUI版もコマンドライン版も、mtd6がmountできないので単に無視しているらしい)。修理のことを考えてバックアップしたい、という需要は皆にあると思うんだけどなあ。

ちなみに私のHTC版のHamiロゴはどうしたかというと、これ同じようなもの(ただしアニメになっている)がboot後、Linuxが動き始めた後にもう一度出るんですねえ。それを狙ってddmsでスクリーンダンプしたものがあるので、いざとなったらそっちから戻そうかと(笑)。

• まだやってませんがsplashの差し替え方。私は『拾ったら教えてね』(兼盗難防止)ロゴに変えてしまおうと思っている。

  http://www.gotontheinter.net/logo.rle