ステータス7に苦労しています。OTA更新メカニズムの仕組みと失敗の理由

多くの場合、ファームウェアのルート化、さまざまな種類のシステムソフトウェアのインストール、カーネルの変更とファームウェアのモックアップに慣れているユーザーは、OTA更新プログラムをインストールすることは不可能であることに気付きます。 立ち上がらず、変更されたシステムファイル、誤ったデジタルキーなどを宣誓します。 この記事では、更新の仕組み、問題の原因、およびそれらを解決する方法について説明します。

仕組み

従来の最初の新しいAndroidバージョンは、Nexusデバイスから最新版を取得していました。 一般向けに新しいファームウェアバージョンが準備できたら、完全なイメージをdeveloper.google.com/android/nexus/imagesで入手できます。 その後まもなく、無線によるファームウェアの配布が開始されます。 Google Dan Morrill（Dan Morrill）の開発者の1人によると 、最初のOTAはデバイスの1％に送信されます。 これは、電話やタブレットの購入地域や場所に関係なく、ランダムに発生します。 この時点でバグが検出され、多数のユーザーにとって重大なエラーが発生している場合に更新を一時停止できます。



その後、数週間、更新プログラムは25、50、100％のユーザーに配布されます。 つまり、最初の段階では、100台のデバイスのうち1台が更新を受信する可能性があります。 更新が受信されない場合、デバイスはリストから削除され、「更新の確認」ボタンを繰り返しクリックすると、デバイスがリストの最後に自動的に転送されます。 新しいメーリングステージが開始されたら、ボタンをクリックすると、25％の更新を受け取る次の機会が与えられます。 デバイス自体が1日に1回（または再起動時に）アップデートをチェックするため、ボタンを押すと、それ自体が発生するよりも早く「撮影」できます。 しかし、再び、チェックは一度だけです。 さらにクリックしても効果はありません。 これは、「最初にクリックした人が最初にクリックした人」という状況ではありません。 いずれにせよ、数週間以内に空輸による更新が全員に届きます。 最もせっかちな人は、アップデートを手動でフラッシュすることができます（詳細は以下を参照）。





更新通知

強制更新

更新の受信を高速化するには2つの方法があります。 1つ目は、Google Services Frameworkデータをクリアしてから、デバイスを再起動することです。 Googleのエンジニアでさえ非難する 、非常に推奨されない方法です。 この方法は多くの悪影響を引き起こしますが、その主なものはGCM（Google Cloud Messenger）の識別子の変更です。 この識別子は、すべてのGoogleプログラムおよびプッシュ通知機能を使用する他の多くのアプリケーションで必要です。 また、一部のプログラムで効果を克服するのが比較的簡単な場合、他の多くの場合、結果はより悲しくなります。 すべてのアプリケーションは、新しい識別子を受信するまでGCMベースのプッシュ通知の受け入れを停止します。 一部のアプリケーションは頻繁にチェックしますが、まれにチェックします。 一部については、アプリケーションデータのクリーンアップが役立ちます。 また、GCM IDをサーバーの識別子として使用するアプリケーションには、さらに深刻な問題が発生する可能性があります。





在庫回復



2つ目は、回復コンソールから手動で更新プログラムをインストールすることです。 OTAの起動直後に、ハッシュタイプのファイルsigned-hammerhead-LRX21O-from-KTU84P.c1a33561.zipがw3bsit3-dns.comおよびXDAリソースのデバイスのプロファイルトピックに表示されます。名前にはファイルのハッシュ、デバイスブランド、および更新用のファームウェアバージョンが含まれますどれ、どれで）。 コンピューターには、ADBおよびfastbootユーティリティを含むフォルダーが必要です。 Android SDKの最新バージョンを使用しています。 同じフォルダーに、ダウンロードしたアーカイブをOTAアップデートとともに配置する必要があります。 また、デバイス用のドライバーを正しくインストールする必要があります。これは、他のデバイス用に以前にインストールしたドライバーと競合する可能性があります。



デバイス自体を回復モードにする必要があります。 これを行うには、電源を切ったデバイスで、<Power + VolDown>ボタンを同時に押したままブートローダーに入り、音量ボタンで回復モードを選択し、電源ボタンで入力します。 リカンベントAndroidに感嘆符が表示されます。 これは間違いではなく、怖がらないでください。 この画面で<Power + VolUp>を短く押す必要があります。その後、ストックリカバリがロードされます。 その中で、音量ボタンでADBアイテムから更新を適用を選択し、電源ボタンで確認する必要があります。 次に、携帯電話/タブレットをコンピューターに接続する必要があります。 コンソールを起動し、ADBと更新アーカイブのあるフォルダーに移動して、次のコマンドを入力します（上記のファイルに対して）：

$ adb sideload .signed-hammerhead-LRX21O-from-KTU84P.c1a33561.zip
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、OTAが電話にインストールされ、再起動します。

サイドバー：セルラーネットワーク経由でアップデートをダウンロードする方法

デバイスがWi-Fiに接続されていない場合、OTA可用性通知が届くことがあります。 ファイルが特定の日付（約1週間）までWi-Fi経由でダウンロードできることを示すメモが表示され、[ダウンロード]ボタン自体は無効になります。 これは、ユーザーのお金を節約するために行われます。 近い将来にWi-Fi接続が予定されていない場合は、通知で指定された日付より後の電話の日付を単純に進め、デバイスを再起動することにより、3G / 4Gを介して電話をだまして更新をダウンロードできます。

情報

在庫（在庫-ストアから）ファームウェアは、工場のコアの存在、回復、ルートの使用を含む取得された変更の不在を理解しています。

変更されたファームウェア

ブートローダーのロックが解除されている場合、カスタムリカバリがあり、ルートが取得され、さまざまなプログラムでアクティブに使用され、さまざまな変更が適用されます。99％の確率で更新プログラムはインストールされません。 在庫回復が返された場合でも、ADB経由のファームウェア中にステータス7エラーが生成され、カスタム回復はエラーを書き込み、変更されたファイルを宣誓します。 この問題は、スマートフォンを工場出荷時のファームウェアに戻すことで解決できますが、これは私たちの方法ではありません。 更新ファイルをクラッキングし、インストールがつまずいた場所を見つけ、問題を修正することで対処します。 最大のNexus 5アップデートの例-バージョン4.4.4（KTU84P）から5.0（LRX21O）へ。

OTAの仕組み

そのため、4.4.4から5.0へのアップグレードは、アーカイブウェイトが491 MBで、近年最大になりました。 DalvikからARTへの変更に関連して、ほとんどすべてのコードが変更されました。 では、アーカイブには何が含まれていますか？ スクリーンショット「5.0にアップグレードしたアーカイブのファイル」でわかるように、アーカイブ内にはブートローダーイメージ（さまざまなセクション）、META-INF、パッチ、およびシステムディレクトリがあります。





5.0にアップグレードしたアーカイブのファイル



トラフィックの量を最小限に抑え、サーバーの負荷を軽減し、エンドユーザーのコストを削減するために、更新構造は、多数の変更があるファイルまたは最初から書き込まれたファイルがシステムディレクトリに配置され、完全に変更されるように設計されています。 また、Googleの標準によって小さな変更が加えられたファイルは置き換えられず、パッチが適用されます。つまり、ファイル内のコードの一部が変更されます。 これらのファイルはパッチディレクトリ内にあり、拡張子は.pです。 これは、/ system / binおよび/ patch / system / bin内のファイルを比較した場合に明らかに見られます。 同時に、よく知られているunixoid bsdiffを使用してパッチを作成します。これにより、2つのバイナリ（ファイル間の差分を持つファイル）からデルタを取得できます。



魔法自体は、/ META-INF / com / google / androidにあるupdater-scriptの意志によって発生します。 詳細に検討します。 ファイル自体の重さは463 Kbで、OTA更新の適用プロセスを担当するコード行が含まれています（実際、それはスクリプト言語Edifyであり、そのインタープリターは同じディレクトリにあり、update-binaryと呼ばれます。-Ed。）。 これが私たちのケースに含まれるものです。 最初に、/システムパーティションがマウントされます（/ etc / fstabにあるものに似たLinuxのかなり標準的なマウントライン）：

 mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", "max_batch_time=0,commit=1,data=ordered,barrier=1,errors=panic,nodelalloc");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、スクリプトはシステム変数ro.build.fingerprintを読み取ってデバイスモデルとファームウェアバージョンをチェックします（/system/build.propファイルからは取得しませんが、リカバリ自体を要求するため、更新はカスタムコンソールを使用して配信できません）回復、ただし5.0以前では可能だった）。 以下、省略記号は略語です：

 getprop("ro.build.fingerprint") == "google/hammerhead/hammerhead:4.4.4/KTU84P/1227136:user/release-keys" || getprop("ro.build.fingerprint") == "google/hammerhead/hammerhead:5.0/LRX21O/1570415:user/release-keys" || abort("Package expects build fingerprint of google/hammerhead/hammerhead:4.4.4 ..."); getprop("ro.product.device") == "hammerhead" || abort("This package is for \"hammerhead\" devices ...");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記からわかるように、更新は「非ネイティブ」デバイスには適用されませんが、バージョン5.0に再ロールできます。 スクリプトは、ファームウェアが公式のGoogleキー（リリースキー）で署名されているかどうかもチェックします。 このため、多くのユーザーに問題があります。 次のステップは、SHA-1ハッシュを調整することにより、個々のファイルの存在と整合性を検証することです。 これには2つの関数が使用されます。sha1_check（）はファイル名とハッシュを引数として受け取り、apply_patch_check（）は3つの引数を受け取ります：ファイル名と2つのハッシュです。 1つ目は単にファイルの整合性をチェックするために使用され、2つ目はファイルに既にパッチが適用されているかどうかをチェックします。 簡単にするために、以下のコードの長いハッシュは楕円に置き換えられます。

 sha1_check(read_file ("system/app/Drive/Drive.apk"), ...) || apply_patch_check("/system/app/Drive.apk", ...) || abort("\"/system/app/Drive.apk\" has unexpected contents."); sha1_check(read_file("system/app/Drive/lib/arm/libdocsimageutils.so"), ...) || apply_patch_check("/system/lib/libdocsimageutils.so", ...) || abort ("\"/system/lib/libdocsimageutils.so\" has unexpected contents.");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、2つのチェックのみが表示されます。 実際、パッチによる置換または変更の対象となるすべてのファイルがチェックされます。 このコードは、たとえば/system/app/Drive.apkファイルが変更または削除された場合、更新によりエラーが発生することを示しています。 チェックブロックの最後に、スクリプトはカーネル、/システムの空き領域、およびラジオをチェックします。

 apply_patch_check("EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8908800:...") || abort("..."); apply_patch_space(23999236) || abort("Not enough free space on /system to apply patches."); apply_patch_check("EMMC:/dev/block/platform/msm_sdcc.1/by-name/modem:46499328:...") || abort("...");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、カスタムカーネルまたは無線の変更がある場合、この更新プログラムは起動しません。 次のステップは、デバイスから古いファイルを削除してから新しいファイルと交換し、新しいファームウェアで不要なファイルを削除することです。

 delete("/system/app/BasicDreams/", "/system/app/BasicDreams/arm/", ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、必要なすべてのファイルに、SHA-1ハッシュの予備チェックでパッチが適用されます。 パッチの適用はapply_patch（）関数を使用して実行されます。この関数は、パッチのファイル名といくつかのハッシュ（元のハッシュ、パッチのハッシュ、結果のハッシュ）を受け入れます。 最後の引数は、パッチファイルの名前です。 前と同様に、以下のコードのすべてのハッシュは省略記号に短縮されます。

 sha1_check(read_file("system/app/Drive/Drive.apk"), ...) || apply_patch("/system/app/Drive.apk", "-", ..., package_extract_file("patch/system/app/Drive.apk.p"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カーネルとRAMディスクには最後にパッチが適用されます。

 apply_patch("EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:..., package_extract_file("patch/boot.img.p"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のブロックは、パッチに該当しないデバイスにファイルを転送するため、完全に置き換える必要があります。 それらのいくつかはその後移動されます：

 package_extract_dir("system", "/system"); rename("system/app/KoreanIME.apk", "system/app/KoreanIME/KoreanIME.apk"); rename("system/framework/wm.odex", "system/framework/arm/wm.odex"); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

不要なファイルが削除され、シンボリックリンク、アクセス権、およびフラグが配置されます（ここでは、アクセス権とフラグが楕円に置き換えられます）。

 delete("/system/etc/firmware/wcd9320/wcd9320_mbhc.bin", ...); symlink("/data/misc/audio/mbhc.bin", "/system/etc/firmware/wcd9320/wcd9320_mbhc.bin"); symlink("/data/misc/audio/wcd9320_anc.bin", "/system/etc/firmware/wcd9320/wcd9320_anc.bin"); ... set_metadata_recursive("/system/bin", ...); set_metadata("/system/bin/app_process32", ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブートローダーと関連セクションがフラッシュされます：

 package_extract_file("bootloader-flag.txt", "/dev/block/platform/msm_sdcc.1/by-name/misc"); package_extract_file("bootloader.aboot.img", "/dev/block/platform/msm_sdcc.1/by-name/aboot"); package_extract_file("bootloader.rpm.img", "/dev/block/platform/msm_sdcc.1/by-name/rpm"); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

無線/モデムにパッチを当てる：

 apply_patch("EMMC:/dev/block/platform/msm_sdcc.1/by-name/modem:..., package_extract_file("radio.img.p"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の変更はbuild.propで、そこに新しいファームウェアバージョンが書き込まれます。 これは、最後の段階でエラーが発生した場合、ほぼすべてのファイルがすでに転送されているときに更新を中断し、現在のファームウェアバージョン番号をデバイス上のファイルに保存するために行われます。 その後、[更新の確認]ボタンをクリックすると、再度開始できます。

 apply_patch("/system/build.prop", "-", ..., package_extract_file("patch/system/build.prop.p")); set_metadata("/system/build.prop", ...);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトの最後で、/システムパーティションがアンマウントされ、更新プログラムの適用の検証が開始され、新しいファイルのSHA-1ハッシュがチェックされ、/システムがアンマウントされます。

 unmount("/system"); mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system", ""); assert(sha1_check(read_file("/system/app/CalendarGooglePrebuilt/CalendarGooglePrebuilt.apk"), ...)); assert(sha1_check(read_file("/system/app/CaptivePortalLogin/CaptivePortalLogin.apk"), ...)); ... unmount("/system");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、デバイスが新しいシステムにリロードされます。





アップデータースクリプトそのまま

カスタム回復

最近まで、OTA更新アーカイブは、ファイルをデバイスにアップロードし、インストールzipを選択するだけで、カスタムリカバリからほとんどの場合（それを置き換えるリカバリチェックがない場合）更新できました。 ただし、アップデート5.0のスクリプトからは、スクリプトが変更されています。 以前のバージョンは/system/build.propファイルをチェックしました：

 file_getprop("/system/build.prop", "ro.build.fingerprint")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在のスクリプトはファイルをチェックしませんが、システム変数の値を直接チェックして、回復を要求します：

 getprop("ro.build.fingerprint")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、カスタムリカバリ（たとえば、TWRPバージョン2.8.0.0）を解析すると、次の行が表示されます。

 ro.build.description=omni_hammerhead-eng 4.4.4 KTU84P eng.dees_troy.20140910.125240 test-keys ro.build.fingerprint=Android/omni_hammerhead/hammerhead:4.4.4/KTU84P/eng.dees_troy.20140910.125240:eng/test-keys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TWRPバージョン2.8.6.1のコードには次の行があります（2行目のomniという言葉に注意してください。ニックネームDees TroyのTWRP開発者もアクティブなOmniROM開発者の1人です）。

 ro.build.id=LRX22G ro.build.display.id=omni_hammerhead-eng 5.0.2 LRX22G eng.dees_troy.20150403.145211 test-keys ro.build.version.incremental=eng.dees_troy.20150403.145211
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、CWM TouchとPhilzの最新バージョンは次のように署名されています。

 ro.build.description=hammerhead-user 4.4 KRT16M 893803 release-keys ro.build.fingerprint=google/hammerhead/hammerhead:4.4/KRT16M/893803:user/release-keys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの値は、チェック時にスクリプトが返し、最初に更新を中断し、デバイス上のAndroidのバージョンの不一致に関するエラーを返します。





カスタムリカバリからNexus 7にアップデート5.0.2をインストールしようとすると得られる答えは次のとおりです。

更新4.4.3–4.4.4

比較のために、KTU84MバージョンからKTU84Pへの以前の更新を引用できます。 更新は小さく、重量はわずか2.5 MBです。 主にセキュリティの改善に関連しています。 アーカイブを開くと、少数のシステムファイルとラジオのみがそれぞれパッチされていることがわかり、スクリプトはそれらをチェックするだけです。 この更新は通常、ルート、カスタムカーネル、および動作するXposed Frameworkとともにインストールされます。これは、すべての変更がチェックされていないためです。

Nexus 6およびNexus 9のアップデート

Googleの最近のデバイスは、スクリプト構造がまったく異なります。 これらのデバイスおよび（明らかに）後続のデバイスについて、Nexus GoogleはOTA更新を構成するアセンブリスクリプトにブロック更新を生成する機能を追加しました。 このような更新では、個々のファイルの検証と更新は行われませんが、/システムファイルシステムでブロックされます。 さらに、例「66、...、524256」には、ブロックアドレスの長いリストがあります。

 if range_sha1("/dev/block/platform/msm_sdcc.1/by-name/system", "66,...,524256") == "..." then block_image_update("/dev/block/platform/msm_sdcc.1/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、Googleのエンジニアは、エンドデバイスでのOTA更新の使用を大幅に簡素化および高速化することができ、アップデータスクリプト自体はわずか5 KBになりました。 しかし、それは上級ユーザーにとって頭痛の種になりました。 実際、システムパーティションを変更するとエラーが発生します。 余分なファイルの存在を含みます。 システムをR / Wとしてマウントするという事実でさえ、FSスーパーブロックのハッシュの変更につながります。

おわりに

記事を要約すると、次の結論を導き出すことができます。

1. スーパーユーザーの権利だけでは、更新プログラムの正常な適用には影響しません。 これらの権限を持っているユーザーとプログラムがシステムに加える変更が影響します。 多くの場合、これらの変更を追跡して返すことはできません。
2. ルートとシステムへの変更が更新の成功に影響するかどうかは、更新中のシステムの変更とスクリプトがチェックするファイルによって異なります。 システムが変更された場合、不必要なシステムアプリケーションがTitanium Backupを介してフリーズ/切断され、カーネルが変更され、カスタムリカバリ、Xposed Framework、Lucky Patcher、freedom、franco.Kernelアップデータ、ダイヤラー用のmod、およびあらゆる種類のサウンド拡張、その他の起動、システムフォントなどがインストールされましたさらに。 このすべてがアップデートに影響を与える可能性があります。
3. システムを変更するとき、OTAを使用して更新する場合は、常に元のファイルをバックアップ用に残してください。 クラウドにコピーし、好きな名前に変更します。 / systemセクションのNandroidバックアップを作成できます（前号のNandroidについて読んでください）。
4. システムの変更点を覚えていれば、ほぼいつでもロールバックできます。 リカバリは常にエラーを書き込みますが、これは更新プログラムが誓います。 エラーのファイル名をググリングすると、どのプログラムがそれを変更するかを見つけることができます。 たとえば、/ system / bin / thermal-engine-hhおよび/system/lib/power.msm8974.soはfranco.Kernelアップデーターを置き換え、ストックカーネルがフラッシュされてアプリケーションが破壊された場合でもそれを返しません。
5. OTAを正常に使用するには、元のファイルをシステムに戻す必要があります。 最も確実な方法は、更新をインストールする前に、system.img、ストックカーネル、およびリカバリをフラッシュすることです（データとアプリケーションは失われません）。
6. さて、主な結論。 ルートと多くの変更がある場合-心配する必要はありませんが、データを保存するためにflash-all.batの-wスイッチを削除して、新しいファームウェアの完全なイメージをすぐに送信します。 バージョン5.0へのアップグレード以降、スクリプトをだます可能性はほとんどありません。 はい。次のアップデートには「ブロック」構造が含まれている場合があります。これは、使用するフルフローのみが存在することを意味します。

エディターからの一言

最近まで、カスタムファームウェア（CyanogenMod、Paranoid）のOTA更新は、常にフルバージョンのファームウェアを含むzip形式で提供され、それ以前にシステムに加えられた変更はまったく重要ではありませんでした。 ファームウェアは常に再インストールされています（もちろん、ユーザーとギャップスのデータを保存します）。ただし、インクリメンタル更新の機能はCyanogenMod 11に登場しましたが、Googleが使用するものに比べてはるかに簡単です。 この更新プログラムは、ファームウェアの整合性を確認し、パッチを適用せずに、以前のバージョン（通常は夜間ビルド）から変更されたファイルを置き換えるだけです。 さらに、更新プログラムの1つを逃した場合、旧式の方法での次の更新プログラムは完全な更新の形式で提供されます。 シンプルで便利。



OmniROMではさらに興味深い方法が使用されます。 更新にはバイナリパッチを使用しますが、Googleのようにはまったく使用しません。 最初のOTA更新は常に完全にダウンロードされ、その後メモリカードに保存され、フラッシュされますが、カードからは削除されません。 次のOTAアップデートは、すでに単一のバイナリパッチの形で提供されます。その後、メモリカードに最後に保存されたアップデートにパッチがスーパーインポーズされ、すでにアップデートされています。 この方法のハイライトは、パッチがシステムに適用されるのではなく、最後に更新されたファイルに適用され、スマートフォンが毎回ゼロからフラッシュされることです（ただし、データと設定は保存されます）。 ほぼ理想的な方法は、トラフィックを節約することであり、変更されたシステムとの競合を心配する必要はありません。





CyanogenMod 12のインストール画面を更新する

Hacker Magazine＃196で最初に発行されました。

作成者：Dmitry "BRADA" Podkopaev



ハッカーを購読する

• サイト資料
• 紙版
• iOS / iPadのハッカー
• Androidのハッカー