Android用のポートTWRPをDIYする方法

ハウツー
、このような小さなツリーで作業してみることができます 最小限のマニフェストTWRP 。ただし、このマニフェストで許可されているよりも多くのリポジトリが必要になる場合があります。



コンパイル前の主な注意事項：フラグを追加または変更する場合は、再コンパイルする前にクリーンにする（またはクローバーを作成する）必要があります。そうしないと、フラグの変更が含まれません。

TWRPソースコードを入手したら、特定のデバイスのビルドフラグの一部を変更する必要があります。デバイスのBoardConfig.mkを見つけます-通常、これはにあります デバイス/メーカー/コードネーム （たとえば、devices / lge / Hammerhead / BoardConfig.mk）



ボード構成には、アーキテクチャとプラットフォーム設定を含める必要があります。これらは通常、すでに含まれています。 もし 他の誰かのデバイス構成を使用しています。ただし、独自に作成した場合は、それらを追加する必要があります。これがないと、リカバリブートがセグメンテーション違反を起こし、画面にTeamWinロゴが繰り返し点滅するためです。



フラグは、BoardConfig.mkの下部の#twrpという見出しの下に配置する必要があります



にとって すべて デバイスの場合、使用するテーマをTWRPに指示する必要があります。古いDEVICE_RESOLUTIONフラグの代わりにTW_THEMEフラグが使用されます。これは、TWRPがスケーリングを使用してテーマを拡大することを意味します。

オプションは、portrait_hdpi、portrait_mdpi、landscape_hdpi、landscape_mdpi、およびwatch_mdpiです。ポートレートモードの場合、720×1280以上のhdpiテーマが必要になる可能性がありますが、ランドスケープデバイスの場合は1280×720以上を使用します。

したがって、ビルドフラグセクション+テーマフラグは次のようになります。



#twrp

TW_THEME：= Portrait_hdpi

このセクションに含める必要のある追加のビルドフラグ（XDAフォーラムへのクレジット）：

  • RECOVERY_SDCARD_ON_DATA：= true（これにより、ストレージ用にこのフォルダがあるデバイス（Galaxy NexusなどのICSに元々付属していたほとんどのHoneycombおよびデバイス）で/ data / mediaを適切に処理できるようになります。ただし、これらのタイプのデバイスにはこのフラグは必要ありません。このフラグを定義せず、fstabに/ sdcard、/ internal_sd、/ internal_sdcard、または/ emmcへの参照を含めないでください。そうすると、デバイスがエミュレートされたストレージを使用していると自動的に想定されます。）
  • BOARD_HAS_NO_REAL_SDCARD：= true — SDカードのパーティション分割などを無効にし、TWRPが回復パターンに適合しない場合は、スペースを節約できる可能性があります
  • TW_NO_BATT_PERCENT：= true —適切にサポートされていないデバイスのバッテリーのパーセンテージの表示を無効にします
  • TW_CUSTOM_POWER_BUTTON：= 107 —ロック画面の電源ボタンをカスタムマップします
  • TW_NO_REBOOT_BOOTLOADER：= true —再起動メニューから再起動ブートローダーボタンを削除します
  • TW_NO_REBOOT_RECOVERY：= true —再起動メニューから再起動リカバリボタンを削除します
  • RECOVERY_TOUCHSCREEN_SWAP_XY：= true —X軸とY軸の間のタッチのマッピングを交換します
  • RECOVERY_TOUCHSCREEN_FLIP_Y：= true —y軸のタッチスクリーン値を反転します
  • RECOVERY_TOUCHSCREEN_FLIP_X：= true —x軸のタッチスクリーン値を反転します
  • TWRP_EVENT_LOGGING：= true —タッチイベントログを有効にして、タッチスクリーンの問題のデバッグに役立てます（リリース時にこれをオンのままにしないでください。ログファイルがすぐにいっぱいになります）
  • BOARD_HAS_FLIPPED_SCREEN：= true —逆さまにマウントされた画面の場合、画面を上下逆にします

追加のビルドフラグは、リカバリソースのAndroid.mkファイルをざっと見ることで見つけることができますが、通常は使用されないため、文書化しても意味がありません。

Recovery.Fstabの使用

TWRP 2.5以降では、新しいrecovery.fstab機能、特にTWRPのバックアップ/復元機能を拡張する機能がサポートされています。ほとんどのパーティションは自動的に処理されるため、fstabフラグを追加する必要はありません。

TWRPはバージョン3.2.0以降のv2fstabのみをサポートします–古いバージョンのTWRPでは、古い形式のfstabを使用する必要があります。 GalaxyS4のTWRPfstabの例を次に示します。

特定のビルドツリーとの互換性を最大化するために、twrp.fstabを作成し、PRODUCT_COPY_FILESを使用して> etc> twrp.fstabに配置できます。

TWRPが起動してRAMディスクでtwrp.fstabを見つけると、名前が> etc> recovery.fstab.bakに変更されます。基本的にはデバイスのfstabがTWRPfstabに置き換えられ、互換性が拡張されます。

コード例：

PRODUCT_COPY_FILES + = device / lge / Hammerhead / twrp.fstab：recovery> root> etc> twrp.fstab

TWRPのfstabには、fstabにリストされている各パーティションの「フラグ」を含めることができます。

これらのフラグが追加されます 最後まで fstab内のパーティションリストの空白/スペース/タブで区切られています。フラグはそのパーティションにのみ影響し、他のパーティションには影響しません。フラグはセミコロンで区切られます。コードの例を次に示します。

それでは、これを少しずつ調べてみましょう。ここの旗は「マイクロSDカード」の表示名を与えます。ワイピングuiフラグは、このパーティションを[詳細ワイプ]メニューでワイプできるようにします。リムーバブルフラグは、このパーティションが常に存在するとは限らないことを示します。これにより、マウントエラーが表示されなくなります。

フラグの完全なリスト （TeamWinのクレジット） ：

  • 取り外し可能 —パーティションが存在せず、起動中にマウントエラーが表示されない可能性があることを示します
  • ストレージ —パーティションをストレージとして使用できることを示します。これにより、パーティションをバックアップ、復元、zipインストールなどのストレージとして使用できるようになります。
  • settingsstorage —設定ストレージとして設定する必要があるパーティションは1つだけです。このパーティションは、TWRPの設定ファイルを保存する場所として使用されます。
  • 拭き取ることができます —パーティションはバックエンドシステムでワイプできるが、ユーザーがワイプするためにGUIにリストされていない可能性があることを示します
  • userrmrf —通常の形式のワイピングを上書きし、rm-rfコマンドを使用してのみパーティションをワイプできるようにします。
  • backup = —等号が続く必要があるため、backup = 1またはbackup = 0、1は、パーティションをバックアップ/復元リストにリストできることを示し、0は、このパーティションがバックアップリストに表示されないことを示します。
  • ワイピングイ —パーティションをGUIに表示して、ユーザーが高度なワイプメニューでワイプするようにパーティションを選択できるようにします
  • 工場リセット中にワイプ —出荷時設定へのリセット中にパーティションがワイプされます
  • ignoreblkid — blkidは、TWRPで使用されているファイルシステムを判別するために使用されます。このフラグにより​​、TWRPはblkidの結果をスキップ/無視し、fstabでのみ指定されたファイルシステムを使用します。
  • 保持レイアウトバージョン —TWRPが/ data / mediaを使用しているが別の/ sdcardパーティションを持っているSonyXperiaSなどのデバイス上の/ dataに.layoutversionファイルを保持するようにします
  • シンボリックリンク = —パーティションをマウントするときに、TWRPが追加のマウントコマンドを実行します。これは通常、/ data / mediaで/ sdcardを作成するために使用されます
  • 表示 = —GUIに一覧表示するパーティションの表示名を設定します
  • storagename = —GUIストレージリストにリストするパーティションのストレージ名を設定します
  • バックアップ名 = —GUIバックアップ/復元リストにリストするパーティションのバックアップ名を設定します
    length = —通常、Androidの完全なデバイス暗号化が存在する場合に、復号化キーを保存するために/ dataパーティションの最後に空のスペースを予約するために使用されます。これを設定しないと、デバイスを暗号化できなくなる可能性があります
  • canencryptbackup = —有効/無効の場合は1または0。ユーザーが暗号化を選択した場合、TWRPはこのパーティションのバックアップを暗号化します（画像ではなくtarバックアップにのみ適用されます）
  • userdataencryptbackup = —有効/無効の場合は1または0、TWRPはこのパーティションのユーザーデータ部分のみを暗号化します。/data/appなどの特定のサブフルは時間を節約するために暗号化されません
  • サブパーティションの = —等号とそれがサブパーティションであるパー​​ティションのパスが続く必要があります。サブパーティションはメインパーティションの「一部」として扱われるため、たとえば、TWRPは自動的に/ datadataを/ dataのサブパーティションにします。つまり、/ datadataはGUIリストに表示されませんが、/ dataに対してこれらの操作が実行されるたびに、/ datadataはワイプ、バックアップ、復元、マウント、およびアンマウントされます。

サブパーティションの使用の良い例は、LG OptimusGの3xefsパーティションです。

これにより、3つのパーティションすべてがTWRP GUIの単一の「EFS」エントリにまとめられ、3つすべてを1つのエントリで一緒にバックアップおよび復元できるようになります。

V2Fstabを使用するTWRP3.2.0以降では、 ビルドフラグを追加する必要はありません 。 V2Fstabのサポートは自動です。 V2 Fstabは、複数のパーティションを持つUSBOTGおよびmicro-SDカードに役立つワイルドカード（*記号）もサポートしています。 V1 Fstab形式を引き続き使用することもでき、同じFstabでV1タイプとV2タイプの両方を使用することは完全に可能です。

たとえば、USBOTG用のワイルドカードを使用したV1Fstab行は次のとおりです。

これは、同じ結果を達成する同じデバイスのV2Fstabラインです。

さらに、V1 Fstab形式を使用するtwrp.flagsなどを含めることができます。これらを使用して、V2 FstabにTWRPフラグ、V2 Fstabに含まれていない追加のパーティション、またはV2Fstabの設定を上書きすることができます。

たとえば、Huaweiデバイスのetcrecovery.fstabに次のV2fstabがある場合があります。

また、次のフラグが含まれている場合もあります。

したがって、ここでは、TWRP.Flagsの最初の2行で、ブートパーティションとリカバリパーティションが追加されます。 存在しなかった V2Fstabで。次に、TWRP.flagsの/ cust行は、エンドユーザーが（cust）パーティションをバックアップできるようにTWRPに指示し、それに表示名を付けます。

/ miscパーティションはtwrp.flagsに存在し、/ oeminfoパーティションはTWRPに、バックアップと表示名の付与も許可するように指示します。

多くのHuaweiデバイスは暗号化されているため、/ data行が必要ですが、特別なHuaweiバイナリを使用します。したがって、Huaweiバイナリを使用して、リカバリモードでデバイスを自動的に復号化します。したがって、ここで/ data行は、TWRPに/ dev / block / dm -0を使用するように指示しますが、通常「適切な」マウントに使用される/ dev / block / bootdevice / by-name / userdataは使用しません。

最後に/ system_imageがあるため、TWRPには[バックアップ]メニューと[復元]メニューにシステムイメージを作成するオプションが含まれます。

公式のTeamWingithubには、公式のTWRPポートを持つデバイスの最新のサンプルデバイスツリーも含まれている必要があります。 TeamWingithubが見つかります ここに 。

OmniまたはCMが同期され、TWRPフラグを設定したら、ソース./build/envsetup.shをビルドする必要があります。

そして、デバイスを「ランチ」したいので、「lunchomni_hammerhead.eng」のようなことをすることができます。

昼食が成功した後、ほとんどのデバイスは次のコマンドを使用します。

–j＃の＃をコアカウント+1に置き換える必要があります。したがって、デュアルコアの場合は–j3、クアッドコアは–j5などになります。＃をコア数+1に置き換えると、デュアルコアの場合は-j3になり、クアッドコアは-j5などになります。

また、一般的なSamsungデバイスにはこれが必要です。

これは、ほとんどのSamsungデバイスにリカバリが含まれているためです ブートの追加のRAMディスクとして、 （他のほとんどのデバイスが使用する）個別のリカバリパーティションではなく。

これで、デバイス用にTWRPがコンパイルされ、エミュレーター環境で機能することが期待されます。常に最初にエミュレータ環境でTWRPポートをテストする必要があります。そうすれば、デバイスを壊すリスクがなくなります。
このデバイス構成ファイルのセットをダウンロードします。

これらのデバイスファイルを使用してリカバリイメージをコンパイルします。 Android SDKで、[ツール]-> [AVDの管理]をクリックします。 [新規]をクリックします。次のように設定します。

次に、[OK]をクリックします。

AVDとリカバリイメージを取得したら、android-sdk / toolsフォルダを参照して次のコマンドを実行することにより、エミュレータでTWRPを起動できます。

ADBはすぐには機能しないことに注意してください。 TWRPの起動が終了してから約10〜15秒後に、ADBがオンラインになります。 init.rcを介してADBを起動するため、何らかのコードエラーが原因でTWRPが起動に失敗した場合でも、ADBは機能するはずです。楽しい！

TWRPおよびA / Bデバイス （TeamWinのクレジット）：

TWRPの観点からは、A / Bデバイスは通常のデバイスとそれほど違いはありませんが、開発者はこれらのデバイスでの作業に恥ずかしがり屋のようです。このテーマに光を当てようと思います。これがTWRPをA / Bデバイスに移植するためのガイドとして役立つことを願っています。

まず、A / Bデバイスとは何かとその違いを理解しましょう。 A / Bデバイスには、デバイス上の多くのパーティションの重複があります。 A / Bデバイスには、2xシステムパーティション、2xブートパーティション、2xベンダーパーティション、2xモデム/ファームウェアパーティションなどがあります。一度に使用できるスロットは1つだけです。初期起動時に、ブートローダーの最初の段階で、BCBまたはブートローダー制御ブロックと呼ばれる少量のデータを読み取り、AパーティションとBパーティションのどちらを起動するかを決定します。 OTAアップデートが利用可能になると、アクティブスロットのデータが非アクティブスロットからコピーされ、パッチが適用/更新されます。たとえば、現在スロットAを使用している場合、デバイスはアップデートをダウンロードし、既存のシステムパーティションをスロットAからコピーし、新しいアップデートでスロットBにパッチ/アップデートします。コピーとアップデートが完了すると、BCBが更新され、デバイスはスロットBを使用して再起動します。次に更新が利用可能になると、スロットBのシステムパーティションがスロットAにコピーされて更新され、BCBが更新され、スロットAで再起動します。デバイスでパーティションを表示すると、次のようなものが表示されます。

asusラップトップカメラを逆さまにします

上記のリストのデュアルブート、システム、ベンダーパーティションに注意してください。ただし、ユーザーデータパーティションは1つだけです。

私が知っている要件は技術的にはありませんが、これまでに出荷されたすべてのA / Bデバイスには個別のリカバリパーティションがありません。代わりに、ブートイメージのRAMディスクにリカバリが含まれています。重要なことは、ブートイメージにもリカバリが含まれていることを知っていることです。完全を期すために、システムパーティションは完全なルートファイルシステムです。起動中に、カーネルが起動して回復するように指示された場合、カーネルは起動パーティションにRAMディスクを抽出します。カーネルがブートローダーから回復のために起動するように指示されていない場合、システムパーティションは完全なルートファイルシステムであるため、カーネルは適切なシステムパーティション（AまたはB）をマウントします。つまり、これらのデバイスのシステムパーティションは/ systemではなく/にマウントされ、システムパーティションには、通常はブートイメージRAMディスクと/ systemサブフォルダーにあるすべてのファイルが含まれます。

TWRPの観点から、A / Bデバイスに対して行う必要がある3つのことがあります。まず、設定する必要があります

コード：

最後に、TWRPに入ると、bootctlhal-infoがエラーなしで正しく応答することを確認する必要があります。通常、bootctlバイナリが正しく機能するには、独自のライブラリまたはいくつかのサービスが必要です。 bootctlが正しく機能しない場合は、TWRP内のスロットも正しく切り替えることができません。

設定に加えて

コード：

AB_OTA_UPDATER：= true

また、以下を設定することもできます。

コード：

BOARD_USES_RECOVERY_AS_BOOT：= true

BOARD_BUILD_SYSTEM_ROOT_IMAGE：= true

設定した場合

コード：

BOARD_USES_RECOVERY_AS_BOOT：= true

その後、make recoveryimageは機能しなくなり、代わりにbootimageを作成する必要があります。 TWRPのみのビルドツリーにこれらのフラグのいずれかを設定することはお勧めしません。これらのフラグは、A / Bデバイス用の完全なROMを構築する開発者におそらく必要になります。

A / BデバイスへのTWRPのインストール/フラッシュ：

既知のすべてのA / Bデバイスには個別のリカバリパーティションがないため、最終的にはTWRPをブートパーティションにフラッシュする必要があります。 Pixel 1とPixel2では、fastboot bootを使用して、TWRPをフラッシュせずにTWRPを一時的に起動します。次に、ユーザーがTWRPを両方のスロットにフラッシュできるようにzipを提供します。これらのzipのいずれかをウェブサイトからダウンロードし、デバイスをサポートするために必要に応じてzipを更新できます。最終的には、TWRPにツールを追加して、ユーザーがzipを使用せずにこれらのデバイスでリカバリをフラッシュできるようにします。

最近、RazerPhoneに取り組みました。残念ながら、RazerPhoneはfastbootブートをサポートしていません。代わりに、ユーザーはを使用して現在アクティブなブートスロットを決定する必要があります

コード：

TWRPに入る。 TWRPに入ると、再起動ページに移動して元のアクティブスロットに戻り、バックアップを作成してからTWRPをインストールできます。非アクティブなスロットを使用すると、ユーザーはTWRPをインストールする前に、デバイスの適切な変更されていないバックアップを取得できます。

その他の注意事項：

TWRPを取得したい場合 お使いのデバイスで公式にサポートされています TWRPアプリで自動的にインストールできるようにし、同じデバイスの他の所有者が公式のTWRPサポートを享受できるようにするために、これを実行する必要があります。次の情報をに送信する必要があります。 TeamWin：

  1. ソースからTWRPをコンパイルするためのデバイス構成ファイル お使いのデバイス用 - 手作業でrecovery.imgを再梱包しないでください 、ソースからコンパイルする必要があります。
  2. TeamWinがTWRPのコピーを作成すると、検証のために送信されます。検証が完了すると、TeamWinはデバイスの作業イメージを作成し、公式のTWRPアプリに追加します。
読んだ13分