私は最近、Allview P5用にこのROMをダウンロードしました（Allview P5はGionee GN700W / FLY IQ441 / QMobile Noir A8と同等です）。Primonex ROMと呼ばれ、Gioneeバージョンの電話用に作られています。
boot.imgファイルに問題がある可能性があり、それを抽出または編集する方法がわかりません...誰かがそれを行う方法を教えてもらえますか？
回答:
ここで紹介する方法は、CyanogenModのAndroidソースコードに依存しています。
GoogleのAOSP はファイルをビルドするツールのみを提供しboot.imgますが、CyanogenModはunpackbootimgツールを追加して解凍することもできます。このツールは、CyanogenMod用に特別に設計されたものではないため、ほとんどの場合、他のROMでも機能する可能性があります。
ただし、boot.imgファイルを解凍するための代替手段は比較的多数あり、それらはすべてほぼ同じように機能します。
基本的に、このようなアンパックツールはboot.imgファイルのコンテンツを抽出し、元の設定mkbootimgと一致する構成（主にカーネルパラメーターとメモリアドレス）を持つファイルを作成するためにGoogleのツールに渡す必要がある一連のパラメーターを表示します。
ここにいくつかの例を示しますが、私はそれらを個人的にテストしなかったため、推奨することはできません。参照目的でのみ提示します。
いくつかは、オープンソースまたはスクリプトベースです。
いくつかは無料のクローズドソースのプロプライエタリバイナリです：
unmkbootimgはヘルプフォーラムに頻繁に登場し、奇妙なケースの処理に役立ち、mkbootimgソースコードに何らかの変更が必要な場合に「人間が読める」英語の推奨を出力し、イメージを再構築するために使用する正確なコマンドラインを表示します。mkbootimg_toolsも非常に頻繁に言及されているようboot.imgで、デバイスツリーファイルを展開および再パックできますdt.img。それはGitHubの上でホストされているという事実によってだまされてはいけない：それはあるクローズドソース独自のバイナリのみコンパイル済みのバイナリが自分のリポジトリで利用可能です（実際に私も店へのソースコードリポジトリを使用しての正確な関心について思ったんだけどバイナリblob、しかし異なる人々、異なる心...）。これらのツール（および他の検索エンジンで見つかるツール）はすべて同じように機能しますが、一部のツールは、自分のデバイスで直面する可能性のある特定のエッジケースの処理において他のツールよりも優れている場合があります。ただし、少なくともオープンソースの分野では、それらのほとんどは定期的に保守されているようには見えないため、作業、保守、および文書化されたツールを使用するための最善の策は、CyanogenModのツールを使用することです。
製造元によっては、AOSP標準から多少離れたROM（異常なアドレス、ヘッダー、ファイル形式など）を製造しています。以下の標準手順が機能しない場合は、これらの代替ソフトウェアのいずれかがトリックを行う可能性があります。それ以外の場合は、デバイスに固有の問題を確認する必要があります。特定の手順や特定のツールが必要なようです（たとえば、MediaTekデバイスに関連するこの質問を参照してください）。
CyanogenModツールセットをboot.imgパックおよびアンパックするためにコンパイルするのは非常に簡単です。
system/core/mkbootimg/（ディレクトリリマインダーとして、GoogleのAOSPのソースコードのみをビルドするためのツールを提供しboot.imgたファイルを、彼らはありませんではありません開梱ツールを提供）、他の目的でこれを必要としない場合は、CyanogenModのandroid_system_coreリポジトリのみを複製するのが簡単で迅速な解決策です。
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
適切なディレクトリに移動したら、コンパイルしてインストールします。
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
GoogleはC mkbootimgをPythonバージョンに置き換えているため、将来のバージョンでは、このコマンドのコンパイルは不要になることに注意してください。
また、Androidツールをコンピューターにインストールして、スマートフォンと通信できるようにする必要があります。あなたは必要になりますadb（アンドロイドデバッグブリッジ、Androidのデバッグサブシステムと通信できるようにするシェルユーティリティ）、 adbd（関連デーモン）とfastboot（お使いの携帯電話のブートローダーシステムと通信できるようにするシェルユーティリティ）。
お気に入りのLinuxディストリビューションでは、それらを単一または個別のパッケージで提供できますが、通常は常に「android-tools」と呼ばれます。
sudo apt-get install android-tools-{adb,adbd,fastboot}sudo yum install android-toolssudo zypper install android-toolsboot.imgファイルを取得するROM .zipファイルから、またはデバイスから直接boot.imgを抽出します。
boot.img。IMO、これらの問題は、貧弱なUSBケーブルまたはUSBハブの使用に関連している可能性が高く、電話機をコンピュータに直接接続する良質のケーブルを使用することで簡単に回避できます。また、ADBをルートモードで実行する機能も必要です（使用するROMに応じて、これは簡単な場合とそうでない場合があります）。最初の方法は非常に明白です。ZIPソフトウェアで.zipファイルを抽出します。ファイルboot.imgはアーカイブのルートにあるはずです。
2番目の方法では、boot.imgコンテンツを取得できるストレージデバイスへの（悲しいことにデバイス固有の）パスを最初に決定する必要があります。これには2つの方法があります。
ls /dev/block/platform/*/by-name/（*さらに別のデバイス固有のフォルダー名をカバーしている可能性がありますが、それは以下の唯一のディレクトリですplatform/）、検索する正確な名前もプラットフォームに依存しますが、通常の意味があります（例：boot、LNX（「Linux」の頭字語））。このディレクトリ内のファイルは実際にはシンボリックリンクであり、手動でターゲットに移動する人もいますが、より長い間エラーが発生しにくいまま、より高いレベルの名前ベースのパスを使用することをお勧めします。そのため、次のようなパスになり/dev/block/platform/sdhci-tegra.3/by-name/LNXます。cat /proc/mtd。ラベルにmtd2関連付けられているデバイスが表示されている場合"boot"は、パスを使用します/dev/mtd2。今：
これがまだ行われていない場合は、コンピューター側でADBサーバーを手動で起動することをお勧めします。これにより、次のADBコマンドの動作に影響を与えることなく、デバイス側でRSAキーを直接検証できます。
adb start-server
次に、ADBをルートモードで切り替えます。
adb root
最後に、boot.imgこのようなコマンドを使用してデバイスからファイルを直接抽出できるはずです（ソースと宛先のパスと名前は例として与えられ、ニーズと好みに合わせて調整します）：
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
このコマンドは、使用済み領域と空き領域の両方のパーティション全体をコピーするため、結果のboot.imgファイルがboot.imgストックROM .zipファイルに付属する元のファイルより大きくなることは驚くことではありません。コンテンツ自体は同じままです。
転送が完了したら、電話を切断し、開発者メニューからデバッグとルートアクセスの両方を無効にすることを忘れないでください。
boot.imgファイルを解凍しますboot.img前にコンパイルしたコマンドを使用して、ファイル自体を解凍します。
unpackbootimg -i ./boot.img
これboot.imgにより、ストックに関して正しい構造で新しいものを再構築できるようにするために不可欠ないくつかの情報が出力されますboot.img。ただし、CyanogenMod upackbootimgは後で使用する複数のファイルに同じ情報を保存するため、メモ帳を急いで使用しないでください。
このコマンドは、入力ファイルの名前に特定のサフィックスが追加されたいくつかのファイルを生成します。
*-second：これは第2段階のブートローダーであり、オプションであり、エンドユーザーの電話ではほとんど使用されません。このファイルが空の場合（最も一般的なケース）、電話のブートローダーはLinuxカーネルを直接呼び出します。*-zImage：これはLinuxカーネルです。*-ramdisk.gzまたは*-ramdisk.lz4：デバイスのルートディレクトリを作成するために使用されるRAMディスク。拡張子は、使用する圧縮アルゴリズムによって異なります。*-dt：デバイスツリー/dev。unpackbootimg出力に表示される値の1つを格納する小さなファイルです。これらの値は、Linuxカーネルに渡すコマンドラインパラメーターと、ブートローダーがブート時に各オブジェクトをロードする必要があるアドレスを定義します。ほとんどの場合、boot.img電話のルートディレクトリのコンテンツを編集できるように、パッケージを展開します。上記のように、このコンテンツは*-ramdisk.gzor *-ramdisk.lz4ファイルに保存され、以下のコマンドを使用して抽出できます。
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
LZ4圧縮RAMディスクの場合、最後の手順をに置き換えlz4 -d ../boot.img-ramdisk.lz4 | cpio -imdます。
続行する前に、必要な変更を自由に行うことができます。ただし、ツールを期待どおりに動作させるために、何も変更せずに完全なアンパック-再パック-ブート手順を1回実行するだけの価値がある場合があります。そうしないと、問題が発生した場合、その原因が変更または何らかの非互換性であるかどうかがわかりません（非標準の手順またはツールを必要とする一部のメーカーについての冒頭のコメントを参照してください）。
new-boot.imgファイルを取得しますCyanogenMod ROM構築プロセスは、内部ツールに依存しmkbootfsてboot.imgファイルを生成します（これはbuild / tools / releasetools / common.pyで発生します）。ただし、このツールを作成する手順は役に立たないように思えますが、システムが提供するシステムを使用してもcpio同じように機能するようです。mkbootfsソースコードの（非常に）クイックチェックの後の私の理解によると、2つの間の主な違いは、後者は点線のファイルと/rootディレクトリを結果のアーカイブに含めないことによっていくつかの健全性対策を適用cpioするようです選択したディレクトリツリー全体を盲目的にアーカイブに配置します。
結論：コンパイルするのに不必要に複雑なことはほとんどありませんので、システムが提供するツールに固執しましょう！
ramdisk上記で作成したディレクトリから、新しいRAMディスクを作成することから始めます。
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
または、LZ4アーカイブを生成する必要がある場合：
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
ここでの目標は、元のファイルに可能な限り近いプロパティを持つ新しいRAMディスクファイルを作成することです（たとえば、フォーラムやブログで共有されている手順では所有者の設定が欠落しているように見えますが、これは私のデバイスでは必須です）。
親ディレクトリに移動して、new-boot.imgファイル自体を生成します。
cd ..
上記のように、CyanogenModのunpackbootimgコマンドは、によって期待される各パラメーターに一致するファイルを生成しますmkbootimg。したがって、すべてのmkbootimg -hパラメーターのリストを取得するためにを発行してから、一致するファイルを使用して各パラメーターを適切な値に設定するだけです。一部のパラメーターはファイルパスを期待し、他のパラメーターはファイルのコンテンツを値として受け取ることを期待することに注意してください。以下の結果のコマンドの例を参照してください。
mkbootimg --kernel ./boot.img-zImage \
--ramdisk ./new-boot.img-ramdisk.gz \
--second ./boot.img-second \
--cmdline "$(cat ./boot.img-cmdline)" \
--base "$(cat ./boot.img-base)" \
--pagesize "$(cat ./boot.img-pagesize)" \
--dt ./boot.img-dt \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)"
--second_offset "$(cat ./boot.img-second_offset)" \
--tags_offset "$(cat ./boot.img-tags_offset)" \
--output ./new-boot.img
ここでは2つのパラメーターのみが設定されていません。
--board：私の理解では、これは結果の画像にモデル名を挿入できる単なる情報フィールドです。--id：これは値を期待していません。イメージが構築された後（タイムスタンプとチェックサムを組み合わせて）一意の識別子を出力するだけです。new-boot.imgファイルをデバイスにフラッシュしますデバイスが正しく検出されていることを確認します。
sudo fastboot devices
新しいROMを使用して起動してみてください（まだフラッシュせずに、問題が発生した場合は、電話を再起動してトレイルに戻す必要があり./new-boot.imgます。ファイル名を自分のものに置き換えてください）。
sudo fastboot boot ./new-boot.img
電話機が新しいブートイメージで正常に動作する場合、fastbootモードに戻って永久にフラッシュします。
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
この手順は最初は困難に思えるかもしれませんが、一度取得すれば、実際にはそうではないことがわかります。
「困難な」側面は、単一の「Androidシステム」がないという事実に由来します。多くのメーカーとROMプロバイダーは、微妙なパスの違いから完全に非標準の環境に至るまで変更を加えることができます。
あなたがしなければならないことは、あなたの特定のデバイスの姿勢を決定し、それからあなたのケースに適切ないくつかのコマンドは何ですか。それらを取得したら、それらに固執し、頻繁に必要な場合は簡単にスクリプトを作成できます。
問題のトラブルシューティングがより簡単になるため、私は自発的に比較的低レベルの詳細に取り組みました。「より簡単な」不透明ユーティリティを使用して新しいboot.imgファイルを作成してフラッシュし、デバイスがそれで起動できないことを確認した場合、どのステップが失敗したかを判断するのは難しくなります。ここでは、各ステップで、操作しているデータを元のboot.imgファイルからのデータまたは電話で見られるデータと比較したり、元のファイルまたはboot.img新しく生成されたファイルでファイルを再構築したりできます。 RAMディスクファイルを使用して、違いが生じるかどうかを確認します（これにより、問題がboot.imgRAMディスクファイル生成手順またはRAMディスクファイル生成手順に由来するかどうかを特定できます）。
Androidキッチンを使用します。そこにboot.imgを展開/再パックするオプションがありますAdvanced options。