![[PukiWiki Plus!]](https://for2ando.net/wiki/image/pukiwiki.plus_logo.png "[PukiWiki Plus!]"){kind=logo}
PageTree Top
CodeOrgan of this page |
このページはroot権限を取得した状態にあるAndroid端末にも、(たいていは)ファームウェアのオンライン・アップデート(OTA)は降ってくる *1 が、何もしないでそのまま適用するとエラーになってアップデートが行われなかったり、悪くすると端末がブートループに陥って起動しなくなったりするため、通常は、unrootedしてからOTAを適用し再度rootedにする、という作業をする必要がある。一言で言うとそれだけだが、併せてやっておいたほうが良いこともいろいろあるので、それらを自分への覚え書きとしてこのページにまとめることにする。 注意事項「端末の暗号化」とrootingAndroid 6.0以降で、出荷時設定で「端末の暗号化」(userdataパーティションの暗号化)がされている端末の一部(SuperSUがsystemlessモードで適用される機種)にSuperSUを適用すると、SuperSUがカーネルを改変を加えるため、userdataパーティションを暗号化していない状態で運用することが可能になる（（通常のカーネルでは「端末の暗号化」は解除できない。すなわち、リカバリ等でuserdataパーティションを暗号化していない状態に初期化しても、最初のカーネルの起動時に自動的にuserdataパーティションを暗号化変換する処理が実行される。SuperSUによる改変カーネルではこの動作が抑止されている））。 このような端末でOTA適用のためにbootパーティション(カーネル)をstockに戻した場合、その状態でリブートするとデータパーティションは自動的に暗号化変換されてしまうので注意。 OTA適用前ROM全体のNANDROIDバックアップ
「端末情報」画面のスクリーンショットいま端末にどのバージョンのファームウェアがインストールされているかを記録するために撮っておく。普通はそんなこと覚えていると思うかもしれないが、特に、何らかのトラブルが起きたときなど、前のバージョンが何だったかを正確に確認することが端末の生死を制することがわりとある(本当)。 「システムアップデートがあります」画面のスクリーンショットまたは「システムアップデートをダウンロードしました」画面。 これも記録のためにとっておく。 OTAファイルのバックアップOTA告知が来ていてOTAがダウンロードされていれば、次のいずれかの場所にOTAの内容を収めたファイル(普通はupdate.zip形式の.zipファイル)があるはずなので、それを安全なストレージにバックアップする。
リカバリからOTAを適用したのでなければ、適用後にOTAファイルは消えてしまう。OTAファイルがないと、それを再度入手するには再配信されるのを待つことになるが、それには通常、数時間から数日の時間が掛かるし、端末の状態によっては二度と降ってこないこともあるので、OTAファイルをバックアップしておくのは常識である。 OTAの適用が始まってから途中で失敗 (これはrootをとって/system下をいじっている場合にはよくある) した場合に、OTAファイルのバックアップがあれば、 手動でstockリカバリからOTAを再適用することができる。 (自分用)/system下の特定ファイルのバックアップを確認次のファイルが母艦PC側にコピーされているかどうかを確認。なければとっておく。以下のリストは私の好みによっているので適宜加除されたい。
各パーティションの変更を元に戻す(Android 7以降で…の場合)(now working...) 各パーティションの変更を元に戻す(Android 6以降でSuperSUのsystem無改変モードの場合)ファクトリイメージ(ただしそれが提供されている場合)またはrooting前のNANDバックアップから
各パーティションの変更を元に戻す(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するのが良い。 ここまでで復元されない変更を元に戻す
OTAが失敗した場合これまでの手順による復元ではOTAが失敗する場合、次のいくつかの方法を適宜試みる。
元に戻すファイルのチェックリスト(自分用)
リカバリをstockリカバリに戻すOTAにはstockリカバリが必須。次の2つの方法がある。
OTAの適用2つ方法がある。
※後者の方法でないと、userdataパーティションが再暗号化されてしまう端末がある。それは以下の端末である。
OTA適用後(この節書き換え中につき矛盾があるかもしれないので注意。2015-05-10) (準備)カスタムリカバリの起動(要ブートローダアンロック)stockリカバリのメニューから端末をfastbootモードに (その項目がリカバリメニューにない場合には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リカバリイメージのバックアップ次のいずれかの方法がある。
リカバリ生成用ファイル群のバックアップAndroidのリカバリイメージは、通常、bootパーティションのイメージにパッチをあてて生成できる。バイナリパッチや生成のためのコマンドは下記のファイル群に含まれているのでバックアップしておくと便利。 次のファイルを母艦PCにコピーする。
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。
/system/etc/install-recovery.shによるリカバリの復元をオフにする。多くの場合はファイル先頭に exit 0 を追加するだけでOK。 SuperSUをインストールしたときはinstall-recovery.shを上書きしてくれるので上の操作は不要。 install-recovery.shを消すときはバックアップをとっておくように(次回OTAで使う)。 要rootアプリのSuperuser権限取得再許可unrootした場合などは消えていることがあるので再取得。 ROM全体のNANDROIDバックアップ
(2012-07-28) (2015-05-10) (2015-09-27) 細部の解説各パーティションのバックアップ次のいずれかの方法がある。
[準備]カスタムリカバリの起動方法は大別して2つある。
Tag: Android OTA アップデート リカバリ nandroid install-recovery.sh ROM |
| Founded by for2ando |  | |
| Powered by PukiWiki Plus! 1.4.7plus-u2-i18n. HTML convert time to 0.048 sec. |
