A/B パーティションとシームレスな更新が XDA でのカスタム開発に与える影響

Android Nougat がリリースされたとき、私たちは次のような話題を持ちました。 あらゆる種類の新機能. 初心者向けに新しく更新されたユーザー インターフェイスと、待望のマルチウィンドウ機能と Vulkan Graphics API のサポートが追加されました。 しかし、ほとんどのユーザーの頭の上には、内部に追加された機能が 1 つありました。 Android Nougat では、A/B パーティションをサポートするデバイスに「シームレス アップデート」が導入されました。 既存の Android デバイスの大部分 (新しい Google Pixel と Google Pixel XL を除く) には、当時 A/B パーティションがなかったため、シームレスなアップデートを利用できませんでした。 この機能の基本前提は、デバイスにシステム、ブート、ベンダー、その他の重要なパーティションの 2 番目のセットがあり、OTA を取得すると、 更新 2 番目のパーティション セットにパッチが適用されている間に更新がバックグラウンドで行われるため、更新されたソフトウェア ビルドをシームレスに再起動できます。 アップデートが失敗した場合は、正常に動作するビルドに戻されるため、企業は頭を抱えて対処する必要がなくなり、消費者はより適切に保護されます。

Project Treble とは異なり、シームレスなアップデートのサポートは、新しい Android デバイスの要件ではありません。 そのため、新しい Android デバイスの大部分はこの機能をサポートしていません。 これまでサポートされているすべてのデバイスのリストを保管してきました、そしてこの機能が広くサポートされていないことは明らかです。 A/B パーティションは通常のユーザーとパワー ユーザーの両方に同様に多くのメリットをもたらすため、これは残念です。 ただし、この機能は Android 開発とカスタム変更のフラッシュをより困難にするものと認識されているため、愛好家コミュニティでは少し悪い評判があります。 これは実際には当てはまらないため、シームレスな更新をわかりやすく説明し、A/B パーティションが XDA でのカスタム開発にどのような影響を与えるかを説明したいと思いました。

XDA シニアメンバーに感謝します ンプジョンソン、 の貢献者 リネージュOSと のメンテナー Motorola Moto Z2 Force は、この記事の事実確認に協力してくれました。

---

Android デバイス上のパーティション

パーティションとは、単にデータが保存される電話機の内部ストレージ上の個別のセクションです。 各パーティションにどのような種類のデータが保存されるかは、ハードウェア、オペレーティング システム、およびその他の多くの要因によって異なります。 ブートローダーに 1 つ、システム (Android OS) に 1 つ、ユーザー データに 1 つずつあります... などなど。 人々が「/system」と「/cache」について話しているのを見ると、それらはそれらのパーティションに指定された名前を指しています。 たとえば、OnePlus 6 には、 72 パーティション. それは大変なことのように聞こえますが、OnePlus 6 はシームレスなアップデートをサポートするデバイスの 1 つです。つまり、これらのパーティションの多くは単に相互に重複しているだけです。

OnePlus 6 のパーティションの部分出力。 一部の A/B パーティションには、デモンストレーションのために下線が引かれています。

デバイス上にはたくさんのパーティションがありますが、ユーザーとしては心配する必要はありません。 これらのパーティションの多くは、カスタム ROM、カーネル、リカバリ、または Magisk や Xused などの変更をフラッシュするときに変更されることはありません。 これらのパーティションの多くは、私たちの目的には使用されないか、何をしているのかわからない限り触れるには危険すぎるかのどちらかです (Huawei/Honor の XLOADER および OEMINFO) 大多数の Android ユーザーにとって、私たちが主に扱うパーティションは、システム、ブート、リカバリ、ユーザーデータであり、最近ではベンダーと ヴメタ。 各パーティションの目的を簡単に説明します。

• システム - Android OS、システム ライブラリ、システム アプリ、およびブートアニメーション、ストック壁紙、着信音などのその他のシステム メディアを保持します。
• ブート - カーネル、RAM ディスク、および A/B デバイス上のリカバリも保持します
• リカバリ - リカバリを保持します。TWRP は通常、A 専用デバイスでフラッシュされます (A/B デバイスには専用のリカバリ パーティションがありません)。
• userdata - アプリ、システム、内部ストレージのすべてのデータを保持します
• ベンダー - プラットフォームおよびデバイス固有の HAL、つまり Android OS が基盤となるハードウェアと通信するために必要なファイルを保持します。
• vbmeta - ブートプロセスの整合性を検証する Android Verified Boot 2.0 のパーティション

デバイス OEM は、パーティション スキームを変更して、必要なレイアウトを使用できます。 たとえば、Huawei はブート パーティションを ramdisk_recovery とカーネルに分割します。 また、cust、product、oem などの他のシステム アプリを含む可能性のある追加のパーティションも多数あります。 これらは安全に変更できますが、在庫に戻すのを容易にしたい場合には、一般的にお勧めできません。 では、A/B パーティションはどこで役割を果たすのでしょうか?

---

A/B パーティション スキーム

シームレスなアップデートを使用したデバイスでのアップデートの仕組み

以下に作成した非常に単純な画像は、A/B パーティションをサポートするデバイスで更新がどのように処理されるかを示しています。 図示されているパーティションはシステム パーティションですが、ブートやベンダーなどの他のパーティションも OEM からの特定の OTA アップデートで更新される可能性があります。 この更新プロセスは、Android のメジャー バージョンの更新だけでなく、セキュリティ パッチの更新でも発生します。

1. まず、同じバージョンの Android 上にある 2 つのシステム パーティション system_a と system_b から始めます。
2. system_a がアクティブであると仮定すると、OTA アップデートは、バックグラウンドで非アクティブなパーティションである system_b にパッチを適用します。
3. system_a は非アクティブに設定され、ユーザーが再起動すると system_b がアクティブになります。
4. 現在非アクティブなパーティション system_a は、次回の OTA アップデートがロールアウトされるときに更新されます。

この更新プロセスの利点は何ですか?

1. アップデートが失敗した場合、デバイスは他のスロットの動作中のビルドにロールバックします。
2. データを格納するパーティション (ユーザーデータ) は 1 つだけであるため、更新が中止された場合でも、データは完全にそのままの状態で保たれます。
3. アップデートのストリーミング: データ パーティションがいっぱいの場合、アップデートをダウンロードして、非アクティブなスロットにストリーミングできます。 これは非常に優れた機能であり、更新に一時ストレージを無駄にする必要がありません。 A/B デバイスは不要になったため、キャッシュ パーティションが存在しないのはこのためです。

A/B パーティショニング スキームはデバイスのストレージにどのような影響を与えますか?

シームレスな更新により多数の重複パーティションが作成されるということは、大量のストレージ容量が失われることを意味するのでしょうか? 全くない. Google によれば、シームレスなアップデートをサポートするデバイスでは、/cache パーティションと /recovery パーティションを削除したおかげで、ダウンするのは数百メガバイト程度にとどまるとのことです。 両方のパーティションを削除すると、2 番目のパーティション セットを追加するコストのバランスが取れます。 Google によると、Pixel の A/B システム イメージは、A のみのシステム イメージの半分のサイズです。 追加のストレージ使用量のほとんどは、実際には 2 番目のベンダー パーティションの追加によって発生します。 ベンダー パーティションには OEM が使用する独自のバイナリ (Project Treble の一部) がすべて格納されているため、かなりのスペースを占有することが予想されるため、これは当然のことです。 Google は、4 GB のストレージを搭載したデバイスでは A/B パーティショニングを推奨しませんが (利用可能な総ストレージのほぼ 10% に相当するため)、8 GB 以上のデバイスでは A/B パーティショニングを推奨しています。

A/B パーティションがある場合とない場合の Google Pixel で使用されるストレージ容量の内訳は次のとおりです。

回復パーティションはどうなったのでしょうか?

Android デバイスの基盤となる Linux カーネルにより、Android はスマートフォン上でハードウェアを適切に認識し、使用できるようになります。 A-only Android デバイスでは、通常、カーネルの 2 つのバージョンがあります。1 つはリカバリ パーティション内にパックされ、もう 1 つはブート パーティション内にあります。 シームレスな更新をサポートする A/B デバイスでは、リカバリはカーネルとともにブート イメージ内に含まれるようになりました。 リカバリの主な機能はアップデートをインストールすることでしたが、それはシステム自体によって処理されるため (アップデートエンジン) Android が起動している間は、専用の回復パーティションは必要ありません。

したがって、A/B デバイスにカスタム リカバリをインストールするには、ブート パーティションを変更し、ストック リカバリを独自のものに置き換える必要があります。 TWRP をインストールするには、最初に fastboot コマンドを使用してカスタム ブート イメージを起動する必要があるのはこのためです。 それから fastboot はパーティションにパッチを適用できないため、TWRP インストール スクリプトをフラッシュします。パーティション全体をフラッシュするだけです。 技術的には、TWRP を使用して既存のブート イメージに事前にパッチを適用し、それを fastboot 経由でフラッシュすることもできますが、それは価値があるというよりも面倒です。 TWRP インストーラー スクリプトは、boot_a パーティションと boot_b パーティションの両方にパッチを適用して、TWRP をインストールします。

興味深い事実: シームレスなアップデートを処理する Android update_engine は、基本的に Chrome OS から直接取り込まれたものです。 最近になってからしか logcat をたまたまチェックする人の混乱を避けるために、「Chrome OS」を含む文字列が update_engine のログから削除されました。

私の Android スマートフォンは、シームレスなアップデートのための A/B パーティションをサポートしていますか?

我々が・・・ながら すべてのデバイスのリストを保持する それをサポートするのは、 自分自身でも簡単にチェックできます.

---

シームレスなアップデートはカスタム開発にどのような影響を与えますか?

A/B パーティションに対するユーザーの認識

多くのユーザーはカスタム ソフトウェア開発の妨げになると考えていますが、シームレスなアップデートは実際には開発者にとって恩恵です。 A/B デバイスの開発サポートが不十分であると認識されている理由は、最初の A/B デバイスの価格にあります。 結局のところ、Google Pixel デバイスはシームレスなアップデートをサポートした最初のデバイスの一部であり、往年の Nexus スマートフォンと比較すると比較的高価でした。 さらに、Google が Android OS に対して行ってきた無数の改良のおかげで、カスタム ROM や Google デバイスでは改造があまり人気がなかったため、Google Pixel スマートフォンは Nexus ほどフォーラムで普及しませんでした。 スマートフォン。 外部要因の組み合わせにより、Google Pixel スマートフォンでのカスタム開発は減少しましたが、ほとんどのユーザーは代わりに A/B パーティションのサポートを非難することを選択しました。 Google Pixel などのデバイスでのカスタム開発の可用性を Xiaomi Mi A1 などのデバイスと比較します。 私たちのフォーラムで.

さらに、ユーザーがカスタム ROM、カーネル、リカバリ、変更をインストールする必要がある方法が A/B パーティションによってどのように変更されたのかが理解されていなかったため、A/B パーティションのサポートは不人気になりました。 リカバリがブート イメージ内に存在するようになったため、Magisk や Xused などの間違った順序で変更をフラッシュすると競合が発生し、ブートループが発生する可能性があります。 これらの MOD をフラッシュする順序は重要ですが、カスタム ROM の場合はどのスロットにフラッシュするかを気にする必要はありません。 一般的な考えに反して、ほとんどのカスタム ROM のインストール スクリプトは両方のスロットにフラッシュされません。 スロットを手動で交換する必要はないため、ほとんどの場合、そのことについて心配する必要はありません。

開発者が A/B パーティションを表示する方法

ROM をビルドするとき、開発者は両方のパーティションを利用して別々のビルドをテストできます。 どれかが動作しない場合は、動作中のパーティションに戻って ROM を再構築するだけです。 開発者は、データを消去することなく、アップデートをインストールし、アクティブなパーティションを切り替え、2 つを比較するだけで回帰をテストすることもできます。 LineageOS チームは A/B パーティションのサポートについて次のように考えています。

「Android コミュニティの多くの人は、A/B を『サポートが難しい』、『開発者に優しくない』として非難していますが、実際には適切に実装されています。 サポートしやすくなる そして開発者にとっても同様にフレンドリーです。」 - jrizzoli, LineageOS 変更履歴 19

開発者にとって A/B サポートに関する最初の困難は、これらのデバイスをサポートするために既存のツールを変更することから生じました。 Magisk の開発者である topjohnwu は、Google Pixel の公式サポートをその 1 年後に追加しました。 リリースしたのは、難しかったからではなく、実際にデバイスを入手するのに1年かかったからだ。 取り組む。 TWRPのサポート かなり早く来ました 主任開発者の Dees_Troy がそれに取り組んだ後、A/B デバイスで使用されました。 リネージュOS 15.1 サポートするようになりました ボランティアが時間を見つけて addon.d スクリプトを修正した後の A/B デバイス。

カスタム リカバリ、カーネル、またはその他の MOD を備えた A/B デバイスを更新する方法

カスタムROM

カスタム ROM を搭載したデバイスでアップデートをフラッシュするということは、どのスロットにフラッシュするかにも注意する必要があるということですよね? 完全ではありません。 TWRP は実際にはその多くを処理し、デフォルトではカスタム ROM をフラッシュするための非アクティブなスロットに設定されます。 アクティブなスロットが A でカスタム ROM をフラッシュする場合、実際にはスロット B にフラッシュします。 再起動すると、アクティブなスロットは B になります。 開発者はインストール スクリプトを変更して両方のスロットにフラッシュすることで、エンド ユーザーが作業しやすくすることができますが、現在、ほとんどのカスタム ROM インストール スクリプトは 1 つのスロットにのみフラッシュされます。 最後に、カスタム ROM は ROM に A/B アップデータを実装できるため、ユーザーは何もいじる必要さえありません。 アップデートを手動でフラッシュする - 最新の LineageOS 15.1 には Lineage Updater ツールと XDA シニア メンバーが含まれています アメリカ-レッドドラゴン を作りました 汎用 A/B アップデーター 他の開発者が使用できるようになります。

ストックROM

しかし、デバイスがさまざまな変更を加えたストック ROM を実行していて、これらの MOD をすべて失わずにアップデートをインストールしたい場合は問題がありませんか? 更新プログラムをインストールするための正しい手順がわからない場合は、この問題が発生する可能性があります。 たとえば、OnePlus 6 では、インクリメンタル OTA が変更されたブート イメージにパッチを適用しようとするため、変更されたデバイスにインクリメンタル OTA をフラッシュすることはできません。 したがって、ブートループが発生する可能性が高く、完全な ROM アップデートをフラッシュして、変更したブート イメージを完全に上書きする必要があるのはそのためです。 TWRP、Magisk、およびオプションのカスタム カーネルを保持したまま、OnePlus 6 に OxygenOS アップデートをインストールするために実行する必要がある一般的な手順は次のとおりです。

1. 最新のものをダウンロードしました フルROM ジップ
2. リカバリ時に完全な ROM zip をフラッシュします
3. (オプション) Flash カスタム カーネル
4. フラッシュTWRPインストーラー
5. すぐに再起動してリカバリーに戻ります
6. フラッシュマジスク

Google Pixel デバイスでは、次のことができます。 データを消去せずに工場出荷時のイメージをフラッシュします、次に TWRP を起動し、インストール スクリプトを介して TWRP をインストールしてから、Magisk をインストールします。

個々のパーティション イメージをフラッシュするためのアップデートを抽出する

多くの A/B デバイスの更新ファイルは、A 専用デバイスと比べて少し異なります。 これらは、多くの画像 (Google と Razer の工場出荷時の画像を除く) を含む単なる zip ファイルではなく、payload.bin ファイルの形式になっています。 このファイルを抽出して各パーツを手動でフラッシュすることもできますが、それには特別なツールが必要です。 OnePlus 6、Xiaomi Mi A1、その他多くの A/B デバイスでその方法を学習することに興味がある場合は、読み続けてください。

payload.binを抽出するための設定

1. Python 3.6 があることを確認してください インストールされています.
2. payload_dumper.py と update_metadata_pb2.py をダウンロードします ここ.
3. OTA zip を解凍し、payload.bin をこれらのファイルと同じフォルダーに配置します。
4. OS に応じて、PowerShell、コマンド プロンプト、またはターミナルを開きます。
5. 次のコマンドを入力します。 python -m pip install protobuf
6. それが完了したら、次のコマンドを入力します。 python payload_dumper.py payload.bin
7. これにより、payload.bin ファイル内の画像が現在のフォルダーに抽出されます。

必要に応じて、fastboot 経由でこれらのイメージを個別にフラッシュできます。 次のセクションでは、その方法を説明します。

fastboot を使用して、シームレスな更新をサポートするデバイス上でイメージをフラッシュする

A/B パーティション システム デバイス専用のコマンドが多数あります。 アクティブなスロットとフラッシュを特定のスロットに変更できます。 Project Trebleをお持ちの場合は、互換性のあるデバイス そしてその方法を学びたい フラッシュ汎用システムイメージ, これらのコマンドについてはよく知っているはずです。 下の表を見てください。

(注: A/B デバイスでは、フラッシュ先の特定のスロット内のパーティションを指定するか、スロットのサフィックスを省略すると、現在アクティブなスロットにフラッシュされます。 たとえば、flash コマンドの「partition」を「system」、「system_a」、または「system_b」に置き換えることができます。）

---

Project Treble とシームレスなアップデートについての一言

よくある誤解は、Project Treble のサポートと A/B パーティションのサポートが相互に関連しているというものですが、実際にはそうではありません。 一方を持っていても、もう一方が存在することを意味するものではありません。 Motorola Moto Z2 Force は A/B パーティショニング スキームを使用しますが、Treble をサポートしていません。 一方、Honor 9 Lite は Project Treble をサポートしていますが、A 専用デバイスです。

---

よくある質問/概要

• A/B パーティショニングの利点は何ですか?
  • A/B パーティショニングを使用すると、Android スマートフォンを使用中に更新でき、新しいバージョンで起動する準備ができたら再起動するだけです。 これはブリックに対する保護としても機能します。更新が失敗した場合は、動作中のインストールに戻ります。
• A/B パーティショニングがあると開発が妨げられますか?
  • 開発者が適応するのに少し時間がかかりましたが、答えはほぼノーです。 実際、古いバージョンと新しいテスト バージョンでカスタム ROM をデュアル ブートして回帰をチェックできるため、開発者にとっては役立ちます。
• A/B パーティションはカスタム カーネル、Magisk、Xused などの MOD にどのような影響を与えますか?
  • インストールには注意が必要ですが、今のところ問題はありません。 Magisk は、シームレスなアップデートを備えたデバイスを公式にサポートしているため、正しい順序でフラッシュする限り、問題は発生しません。 他の MOD をフラッシュする前に必ずカスタム カーネルをフラッシュしてください。これで準備完了です。
• 各パーティションに 2 つの異なる ROM をフラッシュしてデュアルブートできますか?
  • 理論的にはそうです。 ただし、共有データ パーティションにより問題が発生するため、お勧めできません。
• A/B パーティション スキームを使用すると、ストレージが削減されることになりますか?
  • いいえ！ Googleによれば、シームレスアップデートをサポートするデバイスは、それをサポートするために数百メガバイトのストレージを犠牲にするだけだという。 メリットはそのコストを上回ります。
• 私のデバイスは A/B パーティションをサポートしていますが、それは Project Treble Generic System Image を使用できることを意味しますか?
  • 必ずしも。 Project Treble と A/B サポートは無関係です。 Motorola Moto Z2 Force は Project Treble をサポートしていませんが、A/B パーティション スキームをサポートしています。
• 私のデバイスは Project Treble をサポートしていますが、それは A/B パーティション スキームを持っていることを意味しますか?
  • これは常に当てはまるわけではありません。 Honor 9 Lite は、Project Treble をサポートしていますが、A/B パーティション スキームを備えていないため、その代表的な例です。
• 最初に fastboot で TWRP を起動してからフラッシュする必要があるのはなぜですか?
  • これは、fastboot の動作方法と、回復パーティションが存在しないためです。 リカバリはブート パーティション内に配置されるため、boot_a と boot_b の両方を変更する必要があります。 fastboot ではパーティションにパッチを適用することはできません。フラッシュオーバーするだけです。 理論的には、パッチが適用されたブート イメージを作成し、代わりにそれをフラッシュすることができます。
• A/B パーティションには危険性はありますか? ロールバック保護はどのような影響を及ぼしますか?
  • Google はこれを問題にしないように全力を尽くしてきましたが、Motorola Moto Z2 の場合は 強制的に、Android にアップグレードした後にデバイスが古いスロットを再アクティブ化する既知のケースがありました。 オレオ。 これは、ロールバック保護が作動し、デバイス所有者は EDL リカバリによってのみスマートフォンを救出できることを意味しました。 ただし、Google によると、ロールバック保護は最初の起動後にのみ機能するため、ダウングレードできなくなる前に、更新後にスロットが完全に機能する必要があります。