ツイート Share on Tumblr
  編集 最終更新のRSS

Top > ZakkiCho > AndroidPrepareOta
Table of Contents

このページは

root権限を取得した状態にあるAndroid端末にも、(たいていは)ファームウェアのオンライン・アップデート(OTA)は降ってくる *1 が、何もしないでそのまま適用するとエラーになってアップデートが行われなかったり、悪くすると端末がブートループに陥って起動しなくなったりするため、通常は、unrootedしてからOTAを適用し再度rootedにする、という作業をする必要がある。一言で言うとそれだけだが、併せてやっておいたほうが良いこともいろいろあるので、それらを自分への覚え書きとしてこのページにまとめることにする。

注意事項

「端末の暗号化」とrooting

Android 6.0以降で、出荷時設定で「端末の暗号化」(userdataパーティションの暗号化)がされている端末の一部(SuperSUがsystemlessモードで適用される機種)にSuperSUを適用すると、SuperSUがカーネルを改変を加えるため、userdataパーティションを暗号化していない状態で運用することが可能になる((通常のカーネルでは「端末の暗号化」は解除できない。すなわち、リカバリ等でuserdataパーティションを暗号化していない状態に初期化しても、最初のカーネルの起動時に自動的にuserdataパーティションを暗号化変換する処理が実行される。SuperSUによる改変カーネルではこの動作が抑止されている))。 このような端末でOTA適用のためにbootパーティション(カーネル)をstockに戻した場合、その状態でリブートするとデータパーティションは自動的に暗号化変換されてしまうので注意。

OTA適用前

ROM全体のNANDROIDバックアップ

  • カスタムリカバリのバックアップ機能を使ってバックアップをとる。
  • これをとっておけばOTA適用後に後悔したときは元の環境に戻すことができる(たぶん)。
  • CWMにはバックアップの互換性に問題があるので、どのバージョンのリカバリでバックアップしたか記録しておく方がよい。
  • バックアップ直後にリストアテストをするといいかも (カスタムリカバリ(特に昔のCWM)によるNANDバックアップはリストアできないことがよくある(経験則))。
  • ROM全体といっても、カスタムリカバリによるバックアップは本当に全部のパーティションをバックアップするわけではない (本当に全部取りたければddコマンドを使って全パーティションをコピーする方法がある)。
  • バックアップには結構時間がかかるので、私は毎回はとらずに、「大規模」なアップデートの場合だけフルバックアップを取るようにしている。OTAファイルを保存しておけば、いくつか前のファームウェアからでも通常は復元は可能なのでこのようにしている。

「端末情報」画面のスクリーンショット

いま端末にどのバージョンのファームウェアがインストールされているかを記録するために撮っておく。普通はそんなこと覚えていると思うかもしれないが、特に、何らかのトラブルが起きたときなど、前のバージョンが何だったかを正確に確認することが端末の生死を制することがわりとある(本当)。

「システムアップデートがあります」画面のスクリーンショット

または「システムアップデートをダウンロードしました」画面。 これも記録のためにとっておく。

OTAファイルのバックアップ

OTA告知が来ていてOTAがダウンロードされていれば、次のいずれかの場所にOTAの内容を収めたファイル(普通はupdate.zip形式の.zipファイル)があるはずなので、それを安全なストレージにバックアップする。

  • 一般には /cache (rootとっていないとここは見れない)
  • HTCでは /storage/emulated/0/downloads
  • Nexus 6とNexus 9以降のNexusでは /data/data/com.google.android.gms/app_download (rootとっていないとここは見れない)
  • Pixelと、7.0.0以降のNexus 5xと6pでは /data/ota_package (rootとっていないとここは見れない)
  • OnePlus One Cyanogen OS 版では /sdcard/Android/data/com.cyngn.fota/cache
  • Yotaphone 2では /data/data/com.symphonyteleca.update/files/update (rootとっていないとここは見れない)
  • Asusの初期のOTAでは /data/dlpkgfile というファイルがzipファイルである(rootとっていないとこれは見れない)。

リカバリからOTAを適用したのでなければ、適用後にOTAファイルは消えてしまう。OTAファイルがないと、それを再度入手するには再配信されるのを待つことになるが、それには通常、数時間から数日の時間が掛かるし、端末の状態によっては二度と降ってこないこともあるので、OTAファイルをバックアップしておくのは常識である。

OTAの適用が始まってから途中で失敗 (これはrootをとって/system下をいじっている場合にはよくある) した場合に、OTAファイルのバックアップがあれば、 手動でstockリカバリからOTAを再適用することができる。

(自分用)/system下の特定ファイルのバックアップを確認

次のファイルが母艦PC側にコピーされているかどうかを確認。なければとっておく。以下のリストは私の好みによっているので適宜加除されたい。

  • /system/build.prop
  • /system/recovery-from-boot.p
  • /system/etc/recovery-resource.dat
  • /system/bin/install-recovery.sh
    • KitKat以前又はMotorola機では上記の代わりに /system/etc/install-recovery.sh
    • Motorola機では上記に加えて /system/etc/install-recovery.cfg

各パーティションの変更を元に戻す(Android 7以降で…の場合)

(now working...)

各パーティションの変更を元に戻す(Android 6以降でSuperSUのsystem無改変モードの場合)

ファクトリイメージ(ただしそれが提供されている場合)またはrooting前のNANDバックアップから

  • boot
  • system
  • vendor (存在する場合) の各パーティションを書き込む。

各パーティションの変更を元に戻す(Android 6以前か、またはSuperSUのsystem改変モードの場合)

/system下のファイルのいずれかに変更を加えている場合、 OTAのupdate.zipが/system下のファイルのハッシュコードのチェック等を行なっていると OTAが失敗するので、前回OTA実行直後の状態に戻す必要がある(特に /system/{bin,etc}/install-recovery.sh とか)。

rootingしているとかXposedを導入しているとかの場合、 それを司るユーティリティプログラム(SuperSUとかXposed Installer(だっけ?))で、システムへの変更を元に戻す操作を行なうのが (手動でそれぞれのファイルを戻すよりも)早道である。

例として、SuperSUで「ルート権限を放棄(アンルート)」操作をすると、/system下のいくつかの変更を原状回復してくれる。ただし全てではない。原状回復されないファイルとしては、/system/bin/install-recovery.sh などがある(これはとっておいたバックアップから復元する)。

Xposedを解除する

私はまだあまりXposedを多用していないので略。

BusyBoxを削除する

StericsonのBusyBoxアプリの場合は、Uninstallを実行する。

unrootする

※system無改変(boot改変)モードの場合は、unrootせずにいきなりbootパーティションをファクトリイメージで上書きする方法のほうが、OTA後の再rootingの時にSuperSUの設定がそのまま残っているので便利。

SuperSUの場合は、

  • 「スーパーユーザーを有効化」のチェックをオフ
  • ルート権限を放棄(アンルート)

のいずれか。最近のOTAではチェックが厳しいので後者でないとOTAは失敗することが多い。

後者の場合、

/system/bin/install-recovery_original.sh

として保存されているバックアップが何故かリストアされずに消されるので、 どこかへコピーしておく等により保全を図ってからunrootするのが良い。

ここまでで復元されない変更を元に戻す

  • SuperSUをアンルートした場合、
    /system/bin/install-recovery.sh
    がリストアされないので、保存してあるファイルバックアップ又は前節で保全したファイルから復元する。

OTAが失敗した場合

これまでの手順による復元ではOTAが失敗する場合、次のいくつかの方法を適宜試みる。

  • 変更されるファイル(後掲のチェックリストも参考に)のバックアップをあらかじめとってあれば、それを上書きする。
  • 前回OTA直後のNANDROIDバックアップからsystemパーティションをリストアする。
  • ファクトリイメージが提供されていれば、systemパーティションをフラッシュする。

元に戻すファイルのチェックリスト(自分用)

/system/{bin,etc}/install-recovery.sh
ブート時に自動実行されるファイル。SuperSUが書き換える。 SuperSUのunroot操作はなぜかこのファイルを元に戻さないし改変前のファイルも残さない。
/system/recovery-from-boot.p
ブートイメージからstockリカバリイメージを生成するためのバイナリパッチ。 ひょっとするとTWRPリカバリが「reboot system」時にサフィックスを.bakへと変更する。 SuperSUはこれを変更しないのでunroot操作では元に戻らない。 TWRPリカバリはreboot systemの際にサフィックスを.bakへと変更してしまうらしい。 TWRPリカバリからのリブートにadb rebootを使えばこの変更は発生しない。
/system/bin/app_process
SuperSUがこのファイルを改変するが、SuperSUはunroot操作でこれを元に戻す。 デフォルトではapp_process32へのシンボリックリンクだと思われる。
/system/bin/app_process32
SuperSUとXposedフレームワークの両方がこのファイルを改変するが、SuperSUはunroot操作でこれを元に戻す。Xposedフレームワークはapp_process32_originalのファイル名で改変前のファイルを残す(たぶん)。
/system/etc/resolv.conf
なんらかの要rootプログラムがこれを作成する(もともとは存在しないので消して良い)。
/system/xbin/busybox及びそれへシンボリックリンクされた各コマンド
Stericson's Busyboxがこれを作成する(もともとは存在しないので消して良い)。 unrootする前にStericson's Busyboxアプリから消すのが簡単。
/system/etc/permissions/platform.xml
KitKat以上で、外部SDカードへのアクセスを与えるためのユーティリティがその目的のために改変するファイル。
/system/bin/{dex2oat,oatdump,patchoat}
(たぶん)Xposedフレームワークが改変するファイル。改変前のファイルが.origのサフィックスで残されている。
/system/lib/lib{art{-compiler,-disassembler,},sigchain}.so
(たぶん)Xposedフレームワークが改変するファイル。改変前のファイルが.origのサフィックスで残されている。

リカバリをstockリカバリに戻す

OTAにはstockリカバリが必須。次の2つの方法がある。

  • /system/{bin,etc}/install-recovery.shにリカバリ復元コードがあるならそれをオリジナルに戻してリブートする。
  • stockリカバリイメージファイルを保存してあるならそれを適切な方法(fastboot flash recoveryとかddとか)で書き込む。

OTAの適用

2つ方法がある。

(通常)
GUIから普通にOTA適用を開始する方法。 リカバリが起動されてupdater-scriptが実行されるので適用される変更内容は次項と同じ。 ただし、放置しておくと、適用が終わったあとに自動的にリブートしてしまうので、 適用中(ドロイド君表示中)にpower + volup キー(機種によって異なる場合あり)を押してリカバリメニューを表示させておく (これにより、リブート前に次節「OTA適用後」の処置を行うことが可能となる)。
stockリカバリから適用
OTAファイルを保存してある場合に行える。sideloadまたは指定の端末ストレージから供給される.zipファイルが適用される。 .zipファイルの適用は、.zipファイル中のupdate-binaryが実行され、 そのupdate-binaryが(通常だと).zipファイル中のupdater-scriptを実行することで行われる。

※後者の方法でないと、userdataパーティションが再暗号化されてしまう端末がある。それは以下の端末である。

  • Pixel C
  • Android 7以降のNexus 9
  • Nextbit Robin これらの端末はデフォルトでuserdataパーティションが暗号化されておりユーザは通常非暗号化を偉うことはできないが、SuperSUが行なうbootパーティションの改変にその機能が含まれているため、SuperSUを導入すると非暗号化が可能になる。しかし、GUIからOTAを適用するためにbootパーティションをファクトリイメージに戻して再起動すると、そのカーネルは非暗号化に対応していないため、再起動時に自動的にuserdataパーティションが再暗号化されてしまう。これを避けるには、bootパーティションにファクトリイメージを書き込んだ後、再起動せずにリカバリからOTAを適用し、さらにそのまま再起動せずに再rootingを行なう必要がある。

OTA適用後

(この節書き換え中につき矛盾があるかもしれないので注意。2015-05-10)

(準備)カスタムリカバリの起動(要ブートローダアンロック)

stockリカバリのメニューから端末をfastbootモードに (その項目がリカバリメニューにない場合にはfastbootモードを起動するキーコンビネーションとともにリブート)した後、

  1. fastboot boot カスタムリカバリイメージファイル

又は

  1. fastboot flash recovery カスタムリカバリイメージファイル
  2. fastbootメニューからリカバリを起動。。

で、カスタムリカバリを起動。後者だと後で述べる「stockリカバリイメージの保全」はできないので、前者が可能ならそれを推奨。

カスタムリカバリとしては、CWM系よりも一般に機能の豊富なTWRP系を推奨。

system,vendor,bootパーティションのバックアップ

当該機種のファクトリイメージが提供されている場合はこれらは必要ない。

カスタムリカバリのバックアップ機能を使って表題の各パーティションをバックアップする。ただしvendorパーティションはもともと存在しない機種もある。

Android6以降でSuperSUがsystem無改変モードを用いる機種の場合は、systemのバックアップではなくてsystem imageのバックアップ、vendorのバックアップでなくてvendor imageのバックアップ(ともにTWRPの場合の表示)をしないと次回OTAでエラーになる。

bootパーティションのバックアップは、Android6以降でSuperSUがsystem無改変モードを用いる機種の場合(及びカスタムROMやカスタムカーネルを導入する場合)だけに必要である。

stockリカバリの保全

カスタムリカバリだとOTAの適用は普通は失敗するので、次のOTAを適用したければ下記のいずれか又は両方の方法でstockリカバリを保全する必要がある*2

stockリカバリイメージのバックアップ

次のいずれかの方法がある。

  • カスタムリカバリのバックアップ機能を使う(リカバリパーティションをバックアップ可能な場合)。
  • カスタムリカバリを起動した状態でadbからddを使う。
  • 次節の「リカバリ生成用ファイル群のバックアップ」をもってstockリカバリのバックアップとする。

リカバリ生成用ファイル群のバックアップ

Androidのリカバリイメージは、通常、bootパーティションのイメージにパッチをあてて生成できる。バイナリパッチや生成のためのコマンドは下記のファイル群に含まれているのでバックアップしておくと便利。

次のファイルを母艦PCにコピーする。

  • /system/build.prop
  • /system/recovery-from-boot.p
  • /system/bin/install-recovery.sh又は/system/etc/install-recovery.sh
    • モトローラ機の場合は/system/etc/install-recovery.cfg
  • /system/etc/recovery-resource.dat

install-recovery.shコマンドから抜き出したコマンドを実行するとstockリカバリイメージを作ることができる。その際にはstockなbootパーティションと/system/recovery-from-boot.p、及び/system/etc/recovery-resource.datが必要である。

初回ブート

TWRPがuserdataパーティションの暗号化に対応していない機種(Nextbit Robin等)では、ここで初回ブートを行なってはいけない。なぜなら、stockなブートイメージ(カーネル)には、起動時にuserdataパーティションが暗号化されていないと自動的に暗号化変換をしてしまう機能が含まれているからである。SuperSUによるsystem無改変モードのrootingによってブートイメージは改変され、自動的に暗号化変換をする機能はオフになるので、rooting後にブートするのならば問題はない。

TWRPからリブートするときはTWRPのメニューからでなく、かならず母艦PCからの adb reboot を用いる (/system/etc/recovert-from-boot.pの拡張子が.bakにリネームされることを防止するため) *3

「端末情報」画面のスクリーンショット

記録のため。

再rooting

最新バージョンのSuperSUの.zipファイルをカスタムリカバリからインストールする。

以下はobsoleted

必須w。

  1. /systemをrwマウント(リカバリから行なうのが簡単)。
  2. /system/app/Superuser.apkの存在を確認。
  3. /system/binに移動して次を実行。
    chown root:root su
    chmod 6755 su

/system/etc/install-recovery.shによるリカバリの復元をオフにする。

多くの場合はファイル先頭に exit 0 を追加するだけでOK。

SuperSUをインストールしたときはinstall-recovery.shを上書きしてくれるので上の操作は不要。

install-recovery.shを消すときはバックアップをとっておくように(次回OTAで使う)。

要rootアプリのSuperuser権限取得再許可

unrootした場合などは消えていることがあるので再取得。

ROM全体のNANDROIDバックアップ

  • もしもの時のために。
  • バックアップ直後にリストアテストをすること (カスタムリカバリによるNANDバックアップはリストアできないことがよくある(経験則))。

(2012-07-28) (2015-05-10) (2015-09-27)

細部の解説

各パーティションのバックアップ

次のいずれかの方法がある。

  • カスタムリカバリのバックアップ機能を使う。
  • adbの使えるカスタムリカバリを起動した状態でadbからddを使う。
  • adbの使えるカスタムリカバリを起動した状態でadb pullする:-P

[準備]カスタムリカバリの起動

方法は大別して2つある。

fastboot bootコマンド
次のコマンドで起動する。
fastboot boot <リカバリイメージファイル名>
これはリカバリパーティションを書き換えないでカスタムリカバリを起動するもの。
ブートローダアンロックしてない場合はこのコマンドは使えない場合が多い。ブートローダアンロックしていてもNexus以外の端末ではやはり使えないことがある。またカスタムリカバリが起動しても機能に制約がある場合もある(adbが使えないなど)。
リカバリパーティション書き換え
次のコマンドによりリカバリパーティションを書き換える。
fastboot flash recovery <リカバリイメージファイル名>
これにより、リカバリパーティションにあるstockリカバリイメージは上書きされる。 このため、この方法でリカバリを起動した場合は、実機からstockリカバリイメージを採取することはできない。 stockリカバリイメージは次のOTAを適用するときに必要になる。
リカバリイメージを含むファクトリイメージが別にある場合や、OTAファイルのなかにリカバリイメージがたまたま含まれていた場合には、そちらを使えばいいので、リカバリパーティションを上書きしても支障はない。
また、OTA適用の際には、少し前のバージョンのstockリカバリでも支障なく適用できることが多いので、それが得られている場合には、同じくこの方法を使っても良いかもしれない(未来のOTAについて古いstockリカバリが機能するかどうかは保証できないので、これは賭けである)。

Tag: Android OTA アップデート リカバリ nandroid install-recovery.sh ROM





*1 中には、rootedであるとOTAが降ってこない端末もある
*2 *なお、OTAの適用に必要なstockリカバリのバージョンはそれほど厳密ではなく、古いバージョンのstockリカバリでもOTAの適用はできてしまう場合が多い。*
*3 最近のTWRPではこれは必要なくなっている
 

4G 6909HFJ 7 Pro Amazon Android Apple Apple ID Basic認証 C6833 CID Crespo Docomo Dream Droid 3 Droid 4 Droid Bionic Elini Eng hboot Engineering hboot Evo 3D Exynos Flashtool G Flex G1 Galaxy Galaxy Nexus Galaxy Note Galaxy Note 3 Galaxy S Galaxy S II Wimax Galaxy S2 Galaxy S3 Galaxy S4 Galaxy Tab GingerBread Gold Google HT03A HTC HTC J HTC J Butterfly HTC J butterfly HTC J one HTL21 HTL22 HTL23 Herring ICS ISW11M ISW11SC ISW12HT ISW13HT IceCreamSandwich IdeaPad J Butterfly JerryBean JerryBeans Jolla KB2387149 KB2813347 KB947821 KDDI Kindle Fire KitKat LG LGE LGL23 LTE Lenovo Lollipop MID MZ604 Magic Maguro Mahimahi Mango Microsoft ModelID MotoFail Motorola N1 Nexus One Nexus S Nodo Nokia OTA Optimus Chat PHP Passion Photon PukiWiki ROM RSD RUU Razr Razr Maxx SC01C SC03E SC05D SCL22 SIMロック解除 SO01F SO02F SO03C SOFF SOL23 Sailfish Samsung Sapphire Shooter_K Soju Sony Sony Mobile SonyEricsson Sunfire SuperCID Superuser.apk System Updates TMobile TWRP Tango Trout Tuna U150 Verizon WP7.0 WP7.8 Windows Windows Phone 7 Windows Server 2008 R2 Windows Update XT862 XT894 Xperia Xperia Z Ultra Xperia Z1 Xperia Z1f Xperia ray Yakju about adb au blaze bootloader fastboot forzando ftf iOS iTunes iTunes Store installrecovery.sh logwrapper m7_wlj nandroid odin qwerty recovery recovery.bin rooting xoom xrea アップデート エラー キーアサイン グレーアウト スクリーンショット フラッシュ ブート ブートローダアンロック プロフィール リカバリ 不具合 内部ストレージ 分解 見えない